Skip to content
VED.EXE
All filings

600Networking, cross-platform

SwiftDrop

Photos, videos and files straight between phones and a PC over your own Wi-Fi. No cloud, no cable, no account.

Role
Sole developer. Built under SNOWBROS.
Year
2026
Status
v1.1.0 for Windows and Android. iPhone joins by QR, no app needed.
Stack
TypeScript, Node.js, React, Flutter, Dart, Vitest, Playwright
Website Repository
The SwiftDrop website: 'Send anything. Directly.' beside a transfer console showing 32.0 MB/s from an iPhone to a PC.
MB/s, 10,000 × 50 KB files, loopback
232 → 314
MB/s, 1,000 × 10 KB files, loopback
66 → 111
blocks, each hashed and verified on arrival
1 MiB
bytes through the internet
0

(57) Abstract

The PC is the endpoint. Phones send in parallel, resumable chunks over the local network, every block is verified on arrival, and an interrupted transfer resumes where it stopped instead of starting again.

Background

Moving a phone's videos to a PC usually means a cable, a cloud upload or a messaging app that recompresses everything. On the same Wi-Fi the bytes only need to cross the room. SwiftDrop moves them there, at the speed of the network rather than the speed of an upload.

Drawings

  1. FIG. 1The SwiftDrop website. The console is the product's own transfer readout, from phone to PC.
  2. FIG. 2From the architecture record. Every 1 MiB block carries its xxh64 digest; the receiver checks it before the write lands.
  3. FIG. 3Two processes, as in real use. Loopback is the software ceiling, not Wi-Fi: on a real network the radio is the limit.
The SwiftDrop website with a transfer console: 32.0 MB/s, iPhone to PC.
  1. 602One line: what it does
  2. 604Live throughput readout
  3. 606Windows installer and Android APK
FIG. 1The SwiftDrop website. The console is the product's own transfer readout, from phone to PC.
The data path
phone  -- up to 6 parallel HTTP requests over Wi-Fi -->  PC  -->  disk

sender                            receiver
  read a 1 MiB block
  hash it (xxh64)       ---->       verify the digest
                                    write it in place to .part
                        <----       204, and mark the block in a bitmap
                                    (bitmap saved every second)
FIG. 2From the architecture record. Every 1 MiB block carries its xxh64 digest; the receiver checks it before the write lands.
Loopback benchmark: contiguous batch frames
MB/s, engine to server    before    after
1,000 × 10 KB               66.5    110.7
10,000 × 50 KB             232.3    313.5
FIG. 3Two processes, as in real use. Loopback is the software ceiling, not Wi-Fi: on a real network the radio is the limit.

Detailed description

Why not WebRTC

Safari's DataChannel tops out far below Wi-Fi speed, burns CPU, and can only save received data from an in-memory Blob, which dies on multi-gigabyte videos. Plain HTTP to the PC gets kernel congestion control, six parallel connections and positional writes straight to disk.

Measure first, then change one thing

A benchmark that ran sender and receiver in one Node process was measuring its own shared event loop. Splitting them into two processes, as in real use, is the rule now: every change is kept only if it wins beyond a ±5% noise band, with the JSON results committed.

Small files were the hard case

Many small files were serialized behind a naming lock and sent as multi-part bodies that arrived five times slower in Node. Atomic name reservation and one readdir per folder instead of one stat per file fixed the disk side; sending each batch as one contiguous buffer alone took 10,000 × 50 KB from 232 to 314 MB/s.

Resume, never restart

Receive state is a bitmap of verified blocks, persisted every second. A dropped connection or a restarted receiver resends only the missing blocks, and a file changed on disk after it was picked is refused rather than sent stale.

One engine, ported to native

The transfer engine was ported to a pure-Dart core that the Flutter Android and Windows apps share, kept byte-compatible with the TypeScript engine through shared test vectors for digests, bitmaps and batch frames.

What is claimed is:

  1. 1.

    A file transfer in which every 1 MiB block is verified on arrival and a damaged block is sent again.

  2. 2.

    The transfer of claim 1, wherein an interrupted transfer resumes from a bitmap of verified blocks.

  3. 3.

    The transfer of claim 1, wherein no byte leaves the local network.

  4. 4.

    The transfer of claim 1, wherein the TypeScript and Dart engines are held byte-compatible by shared test vectors.