CrossDrop: a Flutter implementation of Quick Share for macOS, iOS and Linux

An Android-to-Mac file transfer that is not AirDrop

CrossDrop is a partial implementation of Google's Quick Share in Flutter for macOS, iOS and Linux. The app lives in your menu bar and saves files to your downloads folder.

The problem it addresses is the gap between Android and everything else. AirDrop covers Apple devices, Nearby Share and Quick Share covered Android, and for a long time there was no comfortable way to move a file from a phone to a Linux machine or an iPhone without a cable, a cloud drive or a third-party server in the middle. CrossDrop fills that gap for the local network case.

It is based on NearDrop, a Swift implementation of Nearby Share for macOS, and the protocol documentation is available in the NearDrop repository, which is where you would look for the wire format details.

The audience is a developer or power user with an Android phone and a non-Android machine, on the same network, who wants a two-click transfer without installing a server-side component. The repository topics name the platforms directly: android, flutter-apps, ios-app, linux-app, macos-app, nearby-sharing and quick-share.

The project is MIT licensed, the primary language is Dart, and the last push was on 2026-06-23. The repository publishes no GitHub releases, which is worth noting given the install instructions below point at a Releases page.

Why the project is back in an experimental state

The very first thing in the README is an important notice, and any evaluation has to start there. The repository is back in an experimental continuation state on main. Google has announced official compatibility between Quick Share and AirDrop, so the project may no longer be necessary for everyday use, but the codebase remains available.

That is an unusual and honest thing for a project to say about itself. The upstream platform change removes the reason the project existed, and rather than quietly continuing, the author has flagged the situation and downgraded the project's own status.

The practical consequence for an adopter is that you are picking up a project whose author has told you the problem is being solved elsewhere. The code is a reference implementation you can study or fork, and the protocol documentation alongside it in NearDrop is arguably the more durable artefact here.

The feature list also reads as a work in progress rather than a finished product. Send and receive files to and from Android and other CrossDrop devices, with a PIN confirmation and QR-code pairing for hidden and contacts-only senders. Send text and links. Receive text, links and Wi-Fi credentials, surfaced in the app with copy and open actions instead of being auto-opened.

The Wi-Fi credential handling is the detail that shows the security posture is deliberate. Credentials arriving over a proximity protocol are not opened automatically; they are displayed for you to act on.

Visibility modes and the wake-from-hidden beacon

The visibility model is where most of the engineering went, and it has three states: Everyone, Hidden, and Visible for 1 minute, which auto-reverts. The mode is controllable from the menu-bar tray and from the settings panel.

The interesting part is the wake-from-hidden behaviour. While in Hidden mode, CrossDrop scans via Bluetooth LE for the beacon that a nearby device emits when it starts sharing, and when it sees one it briefly makes itself discoverable and notifies you. The stated idea is to stay private by default and be reachable on demand, and the README notes this works on macOS, Linux and iOS.

The limitation section then explains the hard edge of that design. Visibility is LAN-based. CrossDrop advertises over mDNS while Everyone or Visible for 1 minute is selected, and stops advertising while Hidden. While Hidden it still listens for the BLE beacon to wake on demand, but it cannot advertise that beacon itself, because Apple platforms forbid custom BLE service-data advertising, so it cannot trigger Android's own device nearby is sharing notification. Google's account-based Contacts visibility requires talking to Google servers, which is not something a LAN-only tool can do.

So there are two visibility systems and they do not compose. mDNS handles the LAN side, the BLE beacon handles the wake-up side, and Google's Contacts mode is simply out of reach. The result is a design that is private by default but also invisible by default, with one narrow way to be woken.

Installing on each platform, and the signing problem

The install instructions are per platform, and the macOS path is the interesting one because of the signing state.

The note explains that the author is currently in the process of joining the Apple Developer Program so that CrossDrop can be released for macOS, signed and notarized, and possibly later for iOS and iPadOS as well. Until that happens, the Homebrew cask is described as once published to the tap, so it is not there yet:

  brew install --cask Medformatik/tap/crossdrop

The manual route is to download the universal macOS zip, unzip it, and move CrossDrop.app to /Applications. The README is explicit about the consequence of unsigned builds: locally built apps require a right-click then Open, or you clear the quarantine attribute with `xattr -dr com.apple.quarantine CrossDrop.app`.

On Linux there are two artifacts. The AppImage is downloaded, made executable with chmod +x and run. The tarball is extracted and run as ./CrossDrop. The naming pattern differs per platform and version, with CrossDrop-<version>-linux-x86_64.AppImage and CrossDrop-<version>-linux-x64.tar.gz.

For iOS there is no public distribution yet, and you build and run from source.

Publishing release builds are signed with a Developer ID and notarized by Apple, so Gatekeeper opens them without warnings. That is the target state, and the manual install path is what exists while the author waits for the Developer Program membership.

Building from source with Flutter 3.44.2 or newer

The build requirements are specific: the Flutter SDK, 3.44.2 or newer. Getting the code and its dependencies is three commands:

git clone https://github.com/Medformatik/CrossDrop.git
cd CrossDrop
flutter pub get

Running in development picks the target device explicitly:

flutter run -d macos   # or: -d linux

And the release builds are three more commands, one per platform:

flutter build macos --release    # → build/macos/Build/Products/Release/CrossDrop.app
flutter build linux --release    # → build/linux/x64/release/bundle/
flutter build ios --release      # requires an Apple Developer account for signing

On Linux the native toolchain has to be in place first, and the list of packages is given:

sudo apt-get install -y clang cmake ninja-build pkg-config libgtk-3-dev liblzma-dev

The repository layout matches a standard Flutter project with the platform folders, so lib/ holds the Dart code, macos/, linux/ and ios/ hold the runner projects, and there are assets/, docs/ and a packaging/ directory. There is a test/ directory and a pubspec.yaml with a lock file, and an analysis_options.yaml for the Dart analyzer.

The release pipeline is described in the contributing section. The CI workflow formats, analyzes and tests on every push and pull request, then compiles the macOS, Linux and iOS apps. Pushing a v* tag triggers the release workflow, which builds a signed and notarized macOS app plus packaged Linux artifacts, an AppImage and a tarball, and attaches them to a GitHub release. That is why the version placeholder in the file names matters: the artifacts are named for the tag you build from.

LAN only, and why Wi-Fi Direct and Bluetooth are missing

The limitations section is the most useful part of the README for anyone deciding whether this is usable, and the first limitation is LAN only. Your Android device and your Mac need to be on the same network for the app to work.

The README compares this with Google's implementation, which supports multiple mediums including Wi-Fi Direct, Wi-Fi hotspot, Bluetooth, some kind of 5G peer-to-peer connection, and even a WebRTC-based protocol that goes over the internet through Google servers. CrossDrop supports the mDNS and LAN path and not the others.

The reason for Wi-Fi Direct being absent is stated in the FAQ, and it is a good illustration of why cross-platform proximity protocols are hard. AirDrop uses AWDL, Apple's own proprietary take on peer-to-peer Wi-Fi, which works on top of 802.11 itself, the low-level Wi-Fi protocol, and thus cannot be implemented without messing with the Wi-Fi adapter drivers and raw packets. The author, who is an Android developer and has looked into it, calls implementing AirDrop on Android nigh-impossible: it might be possible, but it would at the very least require root and possibly a custom kernel, and there is an open-source implementation of AWDL and AirDrop for Linux linked from the README.

Bluetooth needs further reverse engineering, which the README says plainly. The BLE beacon support in CrossDrop is the listening half of that, and the visibility section explains why the advertising half is blocked on Apple platforms.

The second FAQ answers why CrossDrop exists next to NearDrop rather than replacing it. NearDrop is a Swift implementation of Nearby Share for macOS and therefore only works on macOS. CrossDrop is the Flutter implementation, serving the same purpose but working on more platforms, so that Nearby Share can also be used on Linux and iOS.

Editorial conclusion

Adopt CrossDrop if you need to move files from an Android phone to a Linux or iOS machine on the same network, and you are willing to run an unsigned build or wait for notarized releases. Do not adopt it if you need cross-network transfer, since it is LAN only, and do not adopt it as a long-term dependency now that the README states the project may no longer be necessary. Verify first that your Android device and your machine share a network, that you accept the missing Wi-Fi Direct and Bluetooth transports, and whether a signed macOS build exists for your version yet, since the author is still joining the Apple Developer Program.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Medformatik/CrossDrop on GitHub
4. README