Flying Carpet 10: Cross-Platform File Transfer Without a Network

The Problem: Moving Files Between Phones and Desktops Without Infrastructure

The core mechanism is a direct WiFi link. In hotspot mode, one device creates an ad hoc hotspot, and the other joins. If both devices support Bluetooth, they exchange the hotspot credentials automatically after you confirm a pairing code. Otherwise, the hosting device displays a password and QR code. In Shared Network mode, both devices join the same WiFi or wired network. The receiving device generates a one-time password and shows a QR code. The sender types the password or scans the QR code, and the devices discover each other on the network. The README emphasizes that you do not need to know the other device's operating system. The protocol is implemented in Rust for the desktop and Android, while the iOS and macOS apps are an independent Swift port that shares no code. This split matters for maintenance, as we will see later.

How It Works: Hotspot Mode and Shared Network Mode

The README gives a concrete example: a phone on WiFi can transfer with a desktop on ethernet if both are on the same network. This is a strong use case for mixed wired and wireless environments. The design choice to use a one-time password rather than a persistent pairing is a security measure, but it also means you must re-authenticate for every transfer. There is no mention of a contact list or persistent trust, so each session starts from scratch. That is a trade-off between simplicity and convenience.

Getting It Running: Downloads, Builds, and Permissions

The permissions are worth noting. Android requires location permission to host hotspots and scan Bluetooth, and camera access for QR scanning. iOS asks for camera, Bluetooth, and local network access. Windows requires a UAC prompt on first run to add firewall rules for port 3290. These are not trivial permissions, but they are necessary for the functionality. The README explicitly states that no location or camera data is collected, which addresses a common concern.

Version 10 Breaking Change: A Hard Compatibility Boundary

Version 10 is a breaking change. Devices running version 10 cannot transfer with version 9 or earlier; you get a version-mismatch message. This is a significant operational constraint. If you have a mixed fleet of devices, you must update all of them to version 10 before any transfer works. The README is direct: "Update Flying Carpet on every device you transfer between." This is a common pain point in peer-to-peer tools, but it is especially sharp here because the tool's value is in cross-device transfers. You cannot gradually upgrade. The release cadence is active: v10.0.2, v10.0.3, and v10.0.4 were pushed within two weeks in August 2026. This suggests the maintainer is fixing bugs quickly, but it also means you may need to update frequently to stay current. For a tool that is often used in offline scenarios, requiring an internet connection to download updates is a practical limitation, though not unique to Flying Carpet.

Limitations and Failure Modes: OS-Specific and Environmental

The README lists several restrictions that are important for adoption. Apple devices cannot programmatically run hotspots, so Apple-to-Apple transfers require Shared Network mode. That means if you have two iPhones and no WiFi network, you cannot use Flying Carpet; the README suggests using AirDrop instead. The hotspot mode disables your wireless internet connection while in use, except on Windows and Android when hosting. This is a real disruption if you need to stay online. VPN must be disabled on both devices, which is a security and privacy consideration. macOS may switch back to an internet-connected network during long transfers, which could interrupt the transfer. The Android version requires Android 10 or later and does not work on some Xiaomi, MIUI, or HarmonyOS devices due to lack of support for the LocalOnlyHotspot API. The maintainer notes they cannot test these devices, so the issue is unresolved. The Linux version is developed on Linux Mint and mainly intended for Debian-based distributions; there is a known issue on Fedora, possibly related to SELinux. Finally, clicking Cancel on desktop platforms can take time to fully stop the hotspot, and the README advises clicking only once. These are not hypothetical edge cases; they are documented limitations that will affect real users.

Alternatives and the Trade-Off in Approach

The most obvious alternative is AirDrop, which is built into Apple devices. AirDrop uses a proprietary protocol and works only between Apple devices. Flying Carpet's approach is to be cross-platform, but it cannot match AirDrop's integration on Apple hardware. For Android-to-Android, you might use Google's Nearby Share, which uses Bluetooth and WiFi Direct, but it is not available on all platforms. For desktop-to-desktop, tools like Syncthing or Resilio Sync use a different model: they sync folders over an existing network or the internet, rather than creating a direct ad hoc link. Flying Carpet's difference is the ad hoc hotspot mode, which requires no preexisting network. That is a genuine differentiator for offline scenarios. The trade-off is that you lose the convenience of a persistent sync folder; you must initiate each transfer manually. The README also mentions that the original implementation was in Go, but was rewritten in Rust due to issues with the Go/Qt paradigm. This is a historical note, but it signals that the maintainer is willing to rewrite for maintainability.

Maintenance, Licensing, and Upgrade Cost

The project is licensed under GPL-3.0, which means any derivative work must also be GPL-licensed. This is a strong copyleft license, which may be a concern for commercial or closed-source use. The README does not discuss contribution guidelines or a roadmap beyond a planned iOS Share menu shortcut. The repository is active, with recent releases in August 2026, so the maintenance cost appears to be low in terms of bug fixes. However, the independent Swift port for iOS and macOS means that any protocol change must be implemented twice: once in Rust and once in Swift. This duplication increases the maintenance burden and the risk of divergence. The README notes that the Swift code shares no code with the Rust core, so a bug fix in one does not automatically apply to the other. For users, the upgrade cost is mainly the need to update all devices simultaneously to avoid version mismatch. There is no mention of a migration path or backward compatibility, so each major version could introduce the same breaking change. Before adopting, you should check the release notes for each new version and plan for coordinated updates.

Editorial conclusion

Adopt Flying Carpet if you regularly move large files between different operating systems without a shared network, especially in field or offline scenarios. Avoid it if you need Apple-to-Apple transfers (use AirDrop) or if your Android device lacks LocalOnlyHotspot support. Before adopting, verify that all devices run version 10, test hotspot mode on your specific hardware (especially Xiaomi or Fedora), and confirm that the first-run firewall prompt is acceptable in your environment. The project is actively maintained, but the version mismatch is a hard boundary: update every device or stay on version 9.

Official sources

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