Mobile Encryption for File Transfer: Secure Sharing on the Go

Mobile file encryption runs in Safari on iOS and Chrome/Firefox on Android using the Web Crypto API — the same crypto.subtle.encrypt call that works on desktop. Files picked from the Photos library or Files app get encrypted with AES-256-GCM before any byte leaves the phone. The heavy lift is PBKDF2 key derivation, which on an iPhone 14 Pro finishes 600,000 iterations in about 350 ms. For a 500 MB .mov from a recent vacation, the real bottleneck is upload bandwidth, not encryption. Mobile-first transfer services don't need native apps — the browser has everything required.

Why browser-based beats native apps on mobile

Native iOS and Android apps for file transfer (Dropbox, WeTransfer's pre-2023 app) request broad permissions, stay in memory after use, and push ads. A browser-based workflow asks for no install, runs once, and closes when the tab does. More importantly, Apple's App Store rejection of true zero-knowledge apps (Cryptee's 2021 saga is documented) makes browser delivery the only way to guarantee the encryption logic isn't silently swapped by an app store update. The same JavaScript bundle runs everywhere, verifiable against SHA-384 hashes.

The Web Crypto API on iOS and Android

Safari 17 on iOS 17+ supports crypto.subtle fully: deriveKey, encrypt, decrypt, sign, verify. Chrome on Android has supported it since version 37 (2014). Both implementations delegate to native OS primitives — CommonCrypto on iOS, BoringSSL on Android — so the crypto is hardware-accelerated on ARM's AES instructions. A 5 MB chunk encrypts in roughly 15 ms on a Pixel 8. The API doesn't expose raw key material to JavaScript (CryptoKey objects are opaque handles), which helps against malicious extensions though mobile browsers have far fewer of those.

Handling large files without blowing memory

Mobile Safari limits JavaScript heap to about 2 GB on iPhones with 6 GB RAM, less on older devices. A naive "read file into ArrayBuffer, encrypt, upload" pattern crashes on anything over 1 GB. Streaming is mandatory. Use File.slice() to read 5 MB chunks, encrypt each with a subkey derived via HKDF, and upload via fetch() with a ReadableStream body. Progressive upload keeps peak memory under 50 MB even for 10 GB videos. Chrome on Android supports streaming fetch requests since version 105; Safari added full support in 17.4.

Battery and thermal considerations

AES-256-GCM is cheap on hardware — ARMv8's Cryptography Extensions make it run at nearly DRAM speed. A 1 GB encryption on an iPhone 14 Pro consumes about 2% battery, mostly the radio for upload, not the CPU. Where users feel heat is PBKDF2 at high iteration counts; 1.2 million iterations (OWASP 2024 recommendation) takes 700 ms and spikes the A17 to 90°C briefly. Dialing iterations to 600,000 balances security and thermals. Argon2id with m=32MB is gentler on sustained workloads because memory-hardness is slower but less power-dense.

Cellular, Wi-Fi, and upload reliability

Mobile uploads fail. A subway tunnel, an elevator, a switch from Wi-Fi to LTE — any of these kills a naive fetch(). Robust mobile transfer uses resumable uploads with chunk-level acknowledgment, protocols like tus.io (tus 1.0 spec, widely supported) or S3 multipart uploads. Each 5 MB chunk uploads independently; a failure re-sends only that chunk. The client stores chunk state in IndexedDB so a browser tab reload or iOS tab eviction doesn't restart the whole job. SwissTransfer and HexaTransfer both implement resumable uploads; WeTransfer's mobile web flow does not, which is why 2 GB uploads over LTE often fail there.

Keyboard entry and the password UX problem

Typing a 16-character strong password on a phone keyboard is miserable. Offer alternatives: scan a QR code containing the password from the sender's screen, paste from the native password manager (iOS fills from Keychain via .well-known/apple-app-site-association equivalents for web), or use a passkey registered during a prior transfer. For one-off cases, use the Web Share Target API to let a companion app (Signal, say) inject the password without the user retyping.

Accessibility and small screens

A 4.7-inch iPhone SE doesn't fit a desktop-style drag-and-drop uploader. Mobile encryption UIs should respect the viewport: full-screen file picker, progress bars that remain visible above the soft keyboard, VoiceOver labels on every button (role="progressbar" with aria-valuenow for accessibility), and a minimum 44x44px tap target per Apple HIG. Don't hide controls behind hover states — there is no hover on touch. Test with iOS Low Power Mode, which throttles background timers and breaks polling-based progress updates.

iOS Safari quirks that break uploads

Safari on iOS has some traps. The Fetch API's upload progress events don't fire reliably before iOS 16.4. The File System Access API isn't supported, so you can't stream large files from local storage the way Chrome does. Safari aggressively evicts inactive tabs on memory pressure, which kills in-flight uploads. Mitigations: use XMLHttpRequest with progress events as a fallback (still works fine), keep the tab foregrounded during upload, and warn the user to not lock the screen for big files. Screen-on drains battery but prevents tab eviction.

Android's broader device fragmentation

Android spans from Pixel 8 Pro to $80 Moto e14 devices running Android Go. Web Crypto works on all of them, but performance varies wildly — an MT6762 at 2 GHz takes 1.8 seconds for 600,000 PBKDF2 iterations where an Apple M3-class phone takes 200 ms. Detect the device via Device Memory API and Hardware Concurrency, scale iteration counts accordingly (down to 300,000 for Go devices), and warn users on cellular-only connections that uploads over 1 GB may be unreliable. The payoff: encrypted transfer works on the majority of the world's phones without requiring a flagship.

Try it at hexatransfer.com — free, no account, 10 GB max.