FlyingCarpet: cross-platform file transfer over ad hoc WiFi, without a network

The gap FlyingCarpet fills between a flash drive and a network share

The README frames the problem in three questions: no flash drive, no wireless network, and a file larger than 2GB that has to cross filesystems without setting up a network share. That is a narrower problem than general file sync, and it is the one the project targets. The audience is anyone holding two devices of different platforms in the same room, which in practice means a phone and a laptop, or a work machine and a personal one.

What makes the project unusual is the platform spread. Android, iOS, Linux, macOS and Windows are all supported, and the desktop builds ship as installers and standalone executables. A transfer does not require an access point, a router, an account, or an internet connection. Two devices with WiFi chips in close range are enough, and Bluetooth is optional.

Hotspot mode and Shared Network mode: two different data paths

Version 10 introduced Shared Network mode alongside the original hotspot mode, and the two behave differently enough that the choice matters.

In hotspot mode, one device creates an ad hoc WiFi hotspot and the other joins it. If both devices have Bluetooth, they exchange the hotspot credentials automatically after the user confirms a pairing code. If Bluetooth is unavailable, the hosting device displays the password and a QR code for manual entry. The README notes that this mode disables the wireless internet connection while in use, though not on Windows or Android when those are hosting.

Shared Network mode assumes both devices are already on the same network, WiFi or wired, and the README gives a phone on WiFi transferring with a desktop on ethernet as an example. The receiving device generates a one-time password, displays it with a QR code, and the sender types or scans it. The devices locate each other on that network and start the transfer. No Bluetooth is involved, and neither device needs to know the other's operating system.

The implementation is a Rust workspace with two members, core and Flying Carpet/src-tauri, plus separate Android and Apple application builds. The Cargo.toml comments explain why resolver = "2" is set explicitly: core is split by cfg(windows) and cfg(unix), and resolver v1 would unify features across platform-specific dependencies that are not being built. That is a build-correctness detail, but it tells you the codebase is genuinely per-platform rather than one binary with conditional branches.

The same file sets opt-level = 3 for all dependencies even in dev builds, and the comment gives the reason: snow's ChaCha20-Poly1305 runs roughly 20x slower at opt-level 0, slow enough that a dev-build sender bottlenecks the transfer below the network and looks like a wire problem. Application code stays at opt-level 0. Anyone building from source should expect a slow first compile for that reason.

Installing FlyingCarpet and running a first transfer

Mobile builds come from the stores. Android is on Google Play and F-Droid, or you can sideload the APK from the releases page. iOS is on the App Store under "Flying Carpet File Transfer". The README states that Android requires at least Android 10, API level 29.

On macOS, Homebrew is the shortest path:

brew install flying-carpet

The README also offers a .zip from the releases page, which unzips to a .app bundle you drag into Applications. Linux users download the .AppImage for a standalone build, or a .deb on Debian-based distributions and install it with dpkg. Windows users take the .msi installer or the standalone FlyingCarpet.exe. Windows requires 10 or later, and the first run adds inbound firewall rules for TCP and UDP port 3290, which triggers a UAC prompt.

Building from source needs Rust and the Tauri CLI:

cargo install tauri-cli
cargo tauri dev

On Linux, install the system dependencies first. The README gives an Ubuntu 20 example:

sudo apt install libsoup2.4* libjavascriptcoregtk* libgdk-pixbuf2.0* librust-pango-sys-dev libgdk3.0* librust-atk-dev librust-atk-sys-dev librust-gdk* libwebkit2gtk* librsvg2-dev

For a first transfer, pick the mode that matches your situation. If both devices are already on one network, choose Shared Network mode and a direction on each device, then select what to send. The receiver shows a one-time password and QR code; enter it on the sender, or scan it with a phone. If there is no shared network, use hotspot mode and confirm the pairing code if Bluetooth is available, or type the displayed password on the joining device if it is not.

Where FlyingCarpet breaks: Apple hotspots, VPNs, and MIUI

The restrictions list is the most useful part of the README, and it is unusually candid.

Apple devices cannot programmatically run hotspots. Apple-to-Apple transfers therefore require Shared Network mode, and the README's own suggestion is that you make a Personal Hotspot manually on one iPhone or MacBook, join it from the other, and then run the transfer in Shared Network mode. It then adds a parenthetical: or just use AirDrop. That is the project telling you it is the wrong tool for that pairing.

VPNs should be disabled on both devices. macOS sometimes switches back to a wireless network with internet connectivity during particularly long transfers, which can interrupt the hotspot path. In hotspot mode the wireless internet connection is disabled while the app runs, except on Windows and Android when hosting.

Android has two separate problems. The app does not work on some Xiaomi, MIUI or HarmonyOS devices, and the README attributes this to missing support for the LocalOnlyHotspot API rather than to a bug the author can fix, since those devices are not available for testing. It does note that at least one Xiaomi phone has been confirmed working. Separately, Android requires location permission to host hotspots and scan for Bluetooth, and camera access to scan QR codes. The README states that no location or camera data is collected.

The Linux build was developed and tested on Linux Mint, and the author says the intent is Debian-based distributions. A linked issue reports trouble on Fedora, possibly SELinux-related, and the README does not claim it is resolved. Finally, the Cancel button on desktop can take time to take effect while the OS finishes joining or creating a hotspot. The README asks you to click it once and wait, and admits that a fix looked easy but was not.

How FlyingCarpet compares to LocalSend and plain AirDrop

LocalSend is the closest comparison a reader is likely to make: another cross-platform transfer tool, also aimed at devices on a local network. The difference in approach is where the network comes from. LocalSend assumes an existing LAN that both devices already share, which is the same assumption FlyingCarpet's Shared Network mode makes. FlyingCarpet's hotspot mode removes that assumption by having one device create the network. The trade-off is that creating a hotspot takes over a radio, disables internet on that interface, and depends on the host platform allowing it. Apple does not, which is why the Apple-to-Apple path collapses back to the shared-network case.

AirDrop is the other reference point, and it is the one the README invokes itself for Apple-to-Apple transfers. AirDrop is faster to reach for, but it does not cross into Android or Windows.

The version 10 change is worth weighing against both. Devices on version 10 cannot transfer with version 9 or earlier, and the failure mode is a version-mismatch message rather than a silent corruption. That is the better of the two outcomes, but it means a mixed-version fleet simply stops working until every device is updated.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived. The last push was on 2026-08-12, and version 10.0.4 was released the same day. Versions 10.0.3 and 10.0.2 landed on 2026-08-06 and 2026-07-28, so the version 10 line has been receiving point releases through August 2026.

The upgrade cost is concentrated in one place: the version 10 protocol break. If you have FlyingCarpet on several devices, the update is not optional per device, it is all-or-nothing for any pair that needs to transfer. The README states this directly rather than burying it. For a tool used occasionally, that is a scheduling annoyance; for one used in the field, it is a reason to check versions before you leave.

The licence is GPL-3.0, per the repository's LICENSE.txt and the project metadata. If you plan to redistribute a modified build, or to link the code into a product you ship, the copyleft terms are the thing to read. Nothing here is legal advice, and the licence text is the authority.

One structural detail affects anyone porting or auditing the code: the Swift code for iOS and macOS is an independent port of the protocol and shares no code with the Rust core. The README says so explicitly, which means a protocol change has to be made twice, and cargo build does not touch the Apple side.

Editorial conclusion

Adopt FlyingCarpet if you regularly move large files between machines on different operating systems and have no shared network or flash drive, and update every device to version 10 before you rely on it. Skip it if both endpoints are Apple devices, if you need transfers to survive an active VPN or a mid-transfer network switch, or if you are on a Xiaomi, MIUI or HarmonyOS phone where LocalOnlyHotspot support is uncertain. Verify three things first: that both devices are on 10.0.4 or later, that a hotspot-mode transfer completes on your exact hardware, and that port 3290 is reachable if a firewall sits between the two machines.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes