OpenDrop: sending files to Apple AirDrop receivers from Linux and macOS

What problem OpenDrop solves, and who it is actually for

AirDrop is Apple's peer-to-peer file transfer, and it runs exclusively over Apple Wireless Direct Link, a Wi-Fi link layer Apple does not document. That means a Linux laptop has no supported way to appear as an AirDrop peer. OpenDrop fills that gap by reimplementing the protocol in Python so that a non-Apple machine can send a file to an iPhone or a Mac. The README calls it "protocol-compatible with Apple AirDrop", which is the whole point: the receiving device does not need OpenDrop installed.

The audience is narrow and technical. This is the output of the Open Wireless Link research project at TU Darmstadt, and the README describes it as "experimental software and is the result of reverse engineering efforts". If you want a general purpose file sync tool, this is the wrong project. If you are studying AWDL, building tooling around Apple's proximity protocols, or you need one Linux box to hand a file to an iPhone, it is the only open option here.

AWDL is the dependency, and that decides your platform

OpenDrop does not implement the radio layer. It requires the target platform to support AWDL already, which per the README means macOS, or Linux running "an open re-implementation of AWDL such as OWL". This is the single most important architectural fact about the project. On macOS you get AWDL from the operating system. On Linux you get it from a separate project that has to be installed and running first, and OpenDrop's own installation steps do not cover it.

The practical consequence: a Linux user who installs the pip package and runs opendrop find on a machine without OWL will not get a working discovery scan, because there is no AWDL interface for the tool to use. The README states the requirement but does not walk through the OWL setup. Plan for that as a separate integration task, and check your kernel and Wi-Fi chipset support before you spend time on the Python side.

Above AWDL, OpenDrop uses mDNS style discovery to find receivers, then an HTTP based exchange to ask the receiver to accept and upload the file. The dependencies listed in setup.py reflect that stack: zeroconf for discovery, requests and requests_toolbelt for the transfer, libarchive-c to build the archive, fleep and Pillow for file type handling and icons.

Installing OpenDrop and sending your first file

The release install is one pip command. The README gives it directly:

pip3 install opendrop

If you want the development version instead, the README clones the repository and installs the local directory:

git clone https://github.com/seemoo-lab/opendrop.git
pip3 install ./opendrop

On macOS there is one extra step before either of those, because the system libarchive is too old for OpenDrop's use of libarchive-c. The README recommends Homebrew:

brew install libarchive

OpenDrop sets DYLD_LIBRARY_PATH itself to find the Homebrew copy, but the README notes you may need to update that variable if you installed the library somewhere else. Linux distributions are expected to ship a recent enough libarchive, so this step is macOS specific.

Sending is a two step procedure. First discover receivers in proximity; the process keeps running until you interrupt it:

opendrop find

The output lists each device with an index, an ID and a name, for example "Found index 0 ID eccb2f2dcfe7 name John's iPhone". Stop it with Ctrl+C once the target appears, then send using whichever of the three identifiers is convenient. OpenDrop tries index first, then ID, then name:

opendrop send -r 0 -f /path/to/some/file

A successful run prints "Asking receiver to accept ...", then "Receiver accepted", then "Uploading file ..." and "Uploading has been successful". Since version 0.13 you can send a URL instead of a file with the --url flag, and the receiving Apple device opens its browser on accept. Receiving is the simplest path: run opendrop receive and it accepts all incoming files automatically, writing them into the current directory. Note the README's own caveat that OpenDrop receivers only handle regular files, not URLs.

The limitations the README admits, and the one it does not fix

The limitations section is unusually honest, and it is the part to read before committing. Three items stand out.

First, discovery. Apple devices start their AWDL interface and AirDrop server only after receiving a custom Bluetooth LE advertisement. OpenDrop does not send that advertisement. So an iPhone that is discoverable by everyone may still not appear in opendrop find, because its AWDL interface is asleep. This is not a bug you can configure around; it is a missing protocol step, and it is the most likely reason a first attempt fails.

Second, authentication. The README states plainly that OpenDrop does not verify that the TLS certificate is signed by Apple's root, and does not check the Apple ID validation record. It also auto-accepts any file it receives because there is no connection state. That last point matters if you run opendrop receive on an untrusted network: anything that can reach the port is written to disk. The README frames this as a research limitation, and it is accurate to read it that way.

Third, multiple files. Apple AirDrop sends several files at once; OpenDrop sends one. The README explains the work involved (adding files to the archive, modifying the HTTP /Ask request), which tells you it is a real protocol change rather than a UI gap.

There is also a versioning limitation worth naming: the latest release in the repository is v0.13.0 from 2021-04-29, while the last push to master was on 2026-08-17. The project is not archived, but the release cadence and the commit cadence do not match, so the pip release and the repository state are not the same thing.

Contacts-only mode and the keychain extractor

AirDrop has a contacts-only mode that normally requires Apple-signed certificates, which an open implementation cannot obtain legitimately. The README's original text struck through the claim that OpenDrop could only reach devices discoverable by everybody, and replaced it with a pointer to the project's keychain extractor, which pulls AirDrop credentials (keys and certificates) out of macOS.

That is a meaningful capability change, and it is also the part of the project with the most obvious legal and ethical edges. Extracting credentials from your own Mac to talk to your own devices is one thing. The README does not describe any consent flow, and the authentication limitations above mean the peer on the other end is not verified. If you need contacts-only reach, you are relying on credentials you extracted yourself and on a peer verification path the README says is absent.

OpenDrop versus Apple's AirDrop, and versus a plain file server

The obvious alternative is AirDrop itself. The difference is that AirDrop is a closed, Apple-only stack with peer authentication and multi-file support, and it only runs on Apple hardware. OpenDrop trades those properties for portability: it runs on Linux and macOS, it is scriptable from Python, and it is inspectable. The trade is explicit in the README, which lists the missing authentication, the missing Bluetooth LE trigger and the single-file limit.

A second alternative is not a competitor at all: run a local HTTP server or use SCP and let the other person open a browser. That works everywhere, needs no AWDL, and has no reverse-engineered protocol to break. It fails exactly where OpenDrop succeeds, which is the case where the receiving side is an iPhone or a Mac and nobody is going to type a URL. If your transfer is between two computers you control, OpenDrop is the more fragile choice. If the receiver is an Apple device in someone's hand, it is the only open choice here.

Maintenance, licence and what a GPL-3.0 dependency means

OpenDrop is licensed under GPL-3.0, and setup.py declares the same classifier. The README's disclaimer notes it is not affiliated with or endorsed by Apple, and that it may be incompatible with future AirDrop versions. That is not a hypothetical: AirDrop is a moving target maintained by a vendor that has no incentive to keep third-party implementations working.

The repository is not archived, and the last push was on 2026-08-17, but the newest tagged release is v0.13.0 from 2021-04-29. The README states the author does not have capacity to work on the listed limitations and is happy to assist someone who takes them on. Read that as a project kept alive by its users rather than by a maintainer with a roadmap. For upgrade cost: pip3 install opendrop gives you the release, and the git clone plus pip3 install ./opendrop path gives you whatever is on master, which may be ahead of the release. There is no documented rollback procedure in the README, so pin a version if you need reproducibility. On the licence side, GPL-3.0 is a copyleft licence; if you link or distribute OpenDrop inside a product, the obligations attach to that distribution. That is a question for your own counsel, not something this article can settle.

Editorial conclusion

OpenDrop is for engineers who already run AWDL on Linux via OWL, or who work on macOS and want a scriptable AirDrop sender, and who accept that the receiver side auto-accepts files with no peer authentication. It is not for anyone who needs a supported, audited file transfer tool, multiple-file sends, or reliable discovery of sleeping iPhones, since the README states Apple devices only start their AWDL interface after a Bluetooth LE advertisement. Before adopting it, verify two things on your own hardware: that opendrop find actually lists the target device, and that your libarchive version is new enough, because the README notes macOS ships an old one and points to brew install libarchive.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. seemoo-lab/opendrop on GitHub