AirDash sends files peer to peer and keeps Firebase out of the transfer path

Firebase handles signaling and pairing while the bytes travel directly

The interesting architectural decision in AirDash is which parts of the transfer go through a server and which do not. The key technologies list names WebRTC for file and data transfers, Firebase Firestore for WebRTC signaling and config storage, and Firebase Functions for device pairing and config automation. The files themselves are encrypted and transferred directly between devices, and the feature list adds that a transfer can start anywhere, with no need to be on the same network or nearby, and that the app automatically uses the best and fastest connection available. That is the classic peer to peer shape: a rendezvous service tells two devices how to talk, and the data path never touches the backend. The privacy claim in the README follows from that split, and it holds only as long as the transfer really is direct. When it is not, the relay path has to be paid for and operated by someone.

Users already have the app on every platform they might pick up

For an end user, the interesting part of this repository is the distribution list rather than the code. AirDash is on the Apple App Store for iOS and macOS, on Google Play for Android, in the Microsoft Store for Windows, in the Snap Store for Linux, and there is a Homebrew cask for macOS. The feature list claims support for all major platforms and app stores, and that sending any number of files of any size is free forever. Startup is meant to be quick and native: the app uses the native mobile share sheet on phones and drag and drop on the desktop. For a reviewer deciding whether to use AirDash, the practical points are that no account appears to be required to send a file, that the destination does not need the same network, and that the connection is picked automatically between wifi, mobile data and ethernet. The project also publishes its own analytics dashboard, a Mixpanel link, which tells you the maintainer tracks usage inside the app.

Running your own instance starts with a Firebase project and a generated env file

The run instructions are short and concrete. You create a Firebase project, enable Firestore and anonymous authentication, copy the .env.sample file to a .env file, and replace the project id and web API key with your own values, which the README says you find in the Firebase console under project settings. The two required entries in the sample file look like this.

__APP__FIREBASE_PROJECT_ID=firebase-project-id
__APP__FIREBASE_API_KEY=33381a2c33381a2c33381a2c33381a2c33381a2

Keys with the __APP__ prefix are compiled into the app, so after changing them the README asks you to regenerate the env file and to deploy the pairing function.

dart tools/scripts.dart app_env
cd functions && npm i && npx firebase deploy --only pairing
flutter run

That is the whole setup: a Dart script generates a Dart file from your .env, a Node install plus a Firebase deploy publishes the pairing backend, and flutter run starts the app. The repository layout supports the story, with a functions directory, a tools directory holding the script, firestore rules, firestore indexes and a storage rules file, and an .env.sample at the top level. Anyone deploying this will also have to translate those rules and indexes into their own Firebase project, and the README does not spell out how strict they are.

A Google STUN server handles the common case and Twilio covers the rest

By default the app uses a Google STUN server to connect peers, which is enough when both devices can be reached directly. The README says the simplest way to also enable TURN servers is to use Twilio, and the mechanism is a second environment file for the functions directory, modelled on the functions/.env-sample file, followed by deploying a backend function named updateTwilioToken. The naming makes the credential handling obvious: TURN credentials are short lived, so a function issues them on demand rather than shipping a static secret in the binary. This is also the part of the design that carries a running cost. Direct connections are free, relayed connections are not, and the README does not say what happens to a transfer that cannot be relayed. A user on a restrictive corporate network, or behind carrier grade NAT in a way that breaks symmetric NAT traversal, is the failure case where a file that should have moved in seconds does not move at all.

The publish guide covers five store targets and one virtual machine each

The release process in the README is written for a maintainer with a Mac, a Windows machine and an Ubuntu machine, all in VMware, plus store credentials. Preparation means updating libraries, running flutter pub get, and running pod update in the ios and macos directories, then bumping the version in changelog.md, pubspec.yaml and snapcraft.yaml before committing and tagging. The macOS path builds the app and packages a disk image with npx appdmg before uploading through Transporter. iOS builds an ipa for the same tool. Android builds an app bundle and copies the output to a known name. Windows and Linux each start from a virtual machine, pull the repository, and build locally. The Windows build produces an msix through dart run msix:create, and the Linux build uses snapcraft with LXD, which the guide marks as required, then uploads to the stable channel. A final step attaches the apk, dmg, msix and snap to a GitHub release. Automating five targets, each with its own virtual machine and its own store API, is the operational weight behind this app.

The sample env file also exposes what automated releases demand

The .env.sample file is a map of the credentials the project needs, and it is worth reading closely. Beyond the two required Firebase values, there are optional analytics entries for Mixpanel and Sentry, and a block of keys needed only for automated releases: Snapcraft login credentials, App Store Connect issuer id, API key, key path, app id and team id, a Google Play service account key path, and the Windows API client id, client secret, tenant id and app id. It also carries paths and credentials for the two virtual machines used by the Windows and Linux builds. Two observations follow. The optional Mixpanel and Sentry entries mean telemetry is off by default in a self hosted copy unless you fill them in, which is worth knowing for a privacy oriented tool. And the release credentials live in one flat file with no per-target scoping visible in the sample, so a fork that publishes its own builds has to decide for itself what it keeps and what it drops.

MIT licensed and recently touched, but the tags stopped in 2024

The licence is MIT, with the terms in the LICENSE file, so anyone can fork, self host and rebrand the app without asking. The development picture is mixed. The last push was on 2026-08-27 and the repository is not archived, so work continues on the default branch, and the presence of a CHANGELOG.md at the top level, together with integration_test and test directories, points to a maintained project rather than a hobby demo. The release list, however, stops at v2.0.158 from 2024-09-02, with v2.0.156 from the day before and v2.0.155 from May 2024. That gap between a moving branch and a frozen tag list is the single most confusing thing about the project for someone deciding whether to depend on it. If you want a stable build, the app stores are the better source than the GitHub tags, and if you want to self host, the code in the repository is the only artifact you have.

Editorial conclusion

AirDash is a good fit for people who want to move a photo or a document to another device without uploading the file to a storage service, and for developers who want a readable reference implementation of WebRTC file transfer in a Flutter app. It is a poor fit for an organisation that cannot use Firebase, that needs guaranteed delivery behind symmetric NAT without paying for relay capacity, or that expects a current release train, because the newest tag is v2.0.158 from 2024-09-02 while the last push was on 2026-08-27. Before running your own instance, check three things: that a Google STUN server is reachable from your network, whether you need a TURN relay and who pays for it, and that the pairing function deployed from the functions directory matches the Firestore rules and indexes in your project. The application itself is MIT licensed, and the code sits in the open, so the fork path is a realistic option if the Firebase dependency becomes a problem.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. simonbengtsson/airdash on GitHub