Rewriting the Foundation: Why We Built an Alternative to LocalSend in Rust

Before writing the very first line of code for xSend, our team’s devices were littered with almost every popular open-source, cross-platform file transfer tool available: LocalSend, Snapdrop, ShareDrop, Warp, you name it.

Without question, projects like LocalSend are phenomenal. By wrapping an elegant UI around network discovery, they have saved countless users from the misery of moving files between iOS, Windows, and Android. Snapdrop, on the other hand, defined frictionless “use-it-and-leave-it” experiences by relying purely on the browser.

However, as power users moving massive project directories, trying to establish peer-to-peer connections across complex NAT setups, and demanding a background daemon with zero memory footprint, we hit a wall. Tools built on high-level application frameworks eventually reveal their physical and architectural limits.

This is why we decided to tear it all down, rewrite the network stack from scratch in Rust, and build xSend. We wanted to cross three specific technical chasms that couldn’t be solved with simple patches.

1. Crossing the Garbage Collection (GC) Chasm: Dart vs. Rust

LocalSend is built using Flutter/Dart. Flutter is a brilliant cross-platform UI framework, but when it comes to highly intensive network I/O operations, Dart’s Garbage Collector (GC) becomes an invisible bottleneck to raw throughput.

When transferring gigabytes or terabytes of files, the program must endlessly allocate and deallocate memory buffers.

• The Cost of GC: Under heavy object creation pressure, Dart’s GC may trigger brief “Stop-the-World” pauses, resulting in micro-stutters in the network stream. Furthermore, to maintain high throughput, the virtual machine generally demands a significant chunk of RAM.
• Rust’s Zero-Cost Abstractions: xSend’s core transport engine is written entirely in Rust. Rust’s unique model of Ownership and Lifetimes allows us to predictably manage memory allocation at compile-time, entirely eliminating runtime garbage collection.
• The Result: When sitting idly as a background daemon, xSend consumes just a few megabytes of RAM. During a saturated gigabit transfer, the speed curve is flat and unyielding, demanding almost zero CPU overhead—even on low-end Android devices or aging routers.

2. Breaking the Sandbox: From Pure WebRTC to a Native Network Stack

Another incredibly popular approach is used by Snapdrop or ShareDrop, which rely entirely on the browser’s native WebRTC implementation.

As we discussed in a previous article, WebRTC is fantastic. In fact, xSend’s web application natively supports pure-browser transfers. But restricting a tool entirely to the browser limits its ultimate ceiling.

• Browsers enforce strict security sandboxes. Every disk read (File API) and packet sent incurs layers of memory copying.
• More frustratingly, pure web apps cannot run in the background. The moment your phone screen turns off, or you switch tabs on your tablet, the operating system aggressively suspends or kills the transfer.

xSend’s solution is a “Native Core Everywhere” approach. Our Rust engine compiles down to a low-level dynamic library on desktop and mobile. It wields true system privileges, interacting directly with TCP Sockets and the secure QUIC protocol. This unlocks true background crash-recovery and delivers LAN throughput 3x to 5x faster than the absolute limits of a browser sandbox.

3. Ending the “Wrong Subnet” Nightmare: Auto-Route

If you’ve used open-source LAN transfer tools in a corporate office, you’ve likely encountered this classic pain point: “We are in the same building, why can’t my app find your device?”

The reason is simple: large corporate Wi-Fi networks are divided into multiple VLANs. Traditional mDNS/UDP broadcast packets (which these apps use to find each other) are immediately dropped by enterprise routers bridging these subnets. If you don’t know the exact IP address, the tool becomes useless.

From day one, xSend was engineered with a Multi-Tier Auto-Route Architecture:

1. Tier 1 (LAN Native): If you are on the same subnet, ordinary UDP discovery initiates a blazing-fast TCP channel.
2. Tier 2 (WAN P2P Hole Punching): If you aren’t on the same subnet, simply type a 6-digit code. The system asks our Cloudflare Worker signaling nodes to perform UDP hole punching across the WAN, establishing a direct QUIC tunnel.
3. Tier 3 (TURN Relay Failsafe): Even if both users are trapped behind draconian, symmetric NAT enterprise firewalls, traffic seamlessly falls back to a heavily-encrypted TURN relay.

The transfer simply does not fail. Users don’t need to understand IP addresses, subnets, or port forwarding. They just need 6 digits. The system investigates and locks onto the most optimal physical path automatically.

Epilogue: Why Rust?

We are not discounting the value of Flutter or Node.js. (In fact, xSend’s desktop wrapper uses Tauri, and the frontend uses React—because for rendering UI, they are superb).

But for the central nervous and cardiovascular system of the application, we needed an engineering language that runs as fast as C/C++ without the risk of memory leaks and buffer overflows. Rust’s fearless concurrency ensures our asynchronous network stack (powered by Tokio) is rock solid, and its cryptographic libraries make implementing ChaCha20-Poly1305 encryption as natural as breathing.

This is xSend. It is not just a clone of LocalSend; it is a fundamental, bottom-up rebuild engineered for extreme performance and complex networking, born from experiencing the limits of everything that came before it.