Flying Carpet: hotspot mode, shared network mode, and the v10 protocol break

Version 10 refuses to talk to a version 9 device

The README opens with the new mode and then a warning: version 10 is a breaking change, and a device on version 10 cannot transfer with version 9 or anything earlier. Instead of connecting you get a version mismatch message. That is a deliberate protocol change rather than a bug, and it means every device you ever transfer between has to be updated in the same sitting.

What version 10 adds is the shared network mode, for when you would rather use a network that already exists than have one device create a hotspot. The three most recent tags are 10.0.6 from 2026-10-24, 10.0.5 from 2026-09-18 and 10.0.4 from 2026-08-12, and the last push to main was on the same day as 10.0.6. Patch numbering on a roughly monthly cadence is the pattern here, so expect the paired update requirement to come back with every release that touches the protocol.

Each platform gets its own artifact and its own package manager

Mobile users have stores, and everyone else picks a file off the releases page.

brew install flying-carpet

On macOS that is one of two routes: a .zip you unzip and drag the .app bundle into Applications, or the Homebrew command above. Linux offers a .AppImage for a standalone run or a .deb installed with dpkg on a Debian based distribution. Windows has a .msi installer, a bare FlyingCarpet.exe, and:

winget install spieglt.FlyingCarpet

Android is on the Play Store and on F-Droid, with an APK on the releases page if you would rather sideload. iOS is in the App Store under the name Flying Carpet File Transfer.

Shared network mode starts with a one-time password and a QR code

The newer mode assumes both devices can already reach the same network. Join them, which the README points out may mean a phone on WiFi talking to a desktop on ethernet, then pick shared network mode and a direction on each device and choose what to send.

Discovery is where this design earns its keep. The receiving device generates a one-time password and shows it with a QR code. Type it on the sending device, or scan it with a phone, and the two find each other on the network and begin the transfer. No Bluetooth is involved in that path, and you never need to know what operating system the other machine runs. That is also why this mode is the only option for two Apple devices, since iOS cannot start a hotspot programmatically. The README's own advice for that case is a manual Personal Hotspot on one device, or just using AirDrop.

Hotspot mode takes your wireless internet down for the transfer

The older mode has one device create an ad hoc WiFi hotspot and the other join it. If both sides have Bluetooth, they swap the hotspot credentials after you confirm a pairing code, so nothing has to be typed. Without Bluetooth, the hosting device displays the password and a QR code for the joining device to read.

The costs are stated plainly in the restrictions. Your wireless internet connection is disabled while the app is in use, except in shared network mode and except on Windows or Android when that device is hosting. VPN should be off on both sides. macOS sometimes reassociates to a wireless network with internet during a long transfer.

The Xcode projects fail the first build until you set DEVELOPMENT_TEAM

Building from source splits into three toolchains. The desktop app is Tauri over Rust, so the path is a Rust install, the Tauri CLI, and the platform libraries.

cargo install tauri-cli

cargo tauri dev

cargo tauri build produces release artifacts for the Windows and Linux desktop app. Android is a separate build from Android/FlyingCarpet/, either ./gradlew assembleDebug or through Android Studio. The Apple side needs a Mac with Xcode, opening Apple/iOS/FlyingCarpet.xcodeproj or Apple/macOS/FlyingCarpet.xcodeproj. DEVELOPMENT_TEAM is left blank on purpose, so a first build stops with "Signing for 'FlyingCarpet' requires a development team" until you choose a team under Signing & Capabilities or pass DEVELOPMENT_TEAM=YOURTEAMID to xcodebuild. The Swift side is an independent port of the protocol and shares no code with the Rust core, so cargo build never touches it.

Cargo.toml raises optimization for dependencies because crypto at zero looks like a network fault

The workspace holds two members and carries two comments that explain more about this project than any documentation page.

[workspace]
resolver = "2"

members = [
    "core",
    "Flying Carpet/src-tauri",
]

[profile.dev.package."*"]
opt-level = 3

The resolver is pinned to v2 on purpose: v1 unifies features across build and dev dependencies and across platform specific dependencies, and since the core crate is split by cfg(windows) and cfg(unix), features from a target nobody is building could leak into the normal graph. The profile line is the more interesting one. Every dependency is optimized even in development builds because snow's ChaCha20-Poly1305 runs about twenty times slower at opt-level 0, slow enough that a development build sender becomes the bottleneck and the transfer appears to be a wire problem. Application code stays at opt-level 0 and stays debuggable, and the cost of that misdiagnosis is written down as a full day of investigation.

Android 10, Windows 10, Linux Mint, and the hotspot API gap

The floors and the rough edges are all in the restrictions list. Android needs at least Android 10, API level 29, and the Android build does not work on some Xiaomi, MIUI and HarmonyOS devices, with the missing LocalOnlyHotspot API given as the likely reason and no testing possible on hardware the author does not own. One Xiaomi phone is confirmed working. Android also asks for location permission to host hotspots and scan for Bluetooth, and camera access for QR codes, while collecting neither location nor camera data. Windows needs version 10 or later, and the first run adds inbound firewall rules for TCP and UDP port 3290, so expect a UAC prompt before anything transfers. Linux was developed and tested on Linux Mint, with Debian based systems the intended target, and there has been at least one issue about a Fedora failure that may involve SELinux and is not yet understood.

Editorial conclusion

Use Flying Carpet when the two devices are close and have no network worth joining, and read the restrictions list before your first transfer. Shared network mode is the mode that works between two Apple devices, because the app cannot start a hotspot programmatically there. Update every device to v10 before your first transfer, since a version mismatch produces an error instead of a connection, and check the LocalOnlyHotspot support of your Android handset if the hotspot never appears.

Frequently asked questions

Official sources

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