DEV Community: KaiDev

How to Transfer Files Between iPhone and Android (No Apps, No Cables)

KaiDev — Sat, 30 May 2026 01:54:58 +0000

If you've ever tried to send a video from an iPhone to an Android phone, you know the feeling. AirDrop doesn't work. Bluetooth is slow. You end up uploading to Google Drive, waiting, then sending a link — or worse, emailing the file and hoping it doesn't get bounced back for being "too large."

The core problem is simple: Apple and Android don't talk to each other natively. AirDrop is iPhone-to-iPhone only. Quick Share is Android-to-Android only. If you're crossing the divide, you're on your own.

This guide walks through the real options — what works, what doesn't, and why a browser-based P2P tool like TransP2P is often the simplest answer.

Why This Is Still a Problem in 2026
You'd think by now there'd be a universal "send" button. There isn't. Here's what you're up against:

iPhone → Android: No AirDrop. iMessage doesn't help. You're left with third-party workarounds.
Android → iPhone: Same problem in reverse. Quick Share is great, but only if the other device speaks the language.
Cross-platform photos/videos: These are the files people transfer most often, and they're exactly the ones that break the easiest.
Let's look at what people actually try, and where each option falls short.

Option 1: The USB Cable Route
This is the "old school" approach, and it's more complicated than most people remember.

To transfer iPhone photos to an Android phone via USB cable, you actually need:

A computer (both phones use different connectors)
Software on the computer to read iPhone (iTunes or Finder)
Software on the computer to talk to Android (MTP driver)
Two cables (iPhone to computer, then computer to Android)
So it's not really "phone to phone" — it's phone → computer → phone. That's two transfers, two cables, and two sets of drivers. Doable, but far from convenient.

Best for: Emergency transfers when everything else fails. Skip if: You want a one-step solution.

Option 2: iCloud + Google Drive (The Cloud Shuffle)
A common workaround: upload iPhone photos to iCloud, download them to a computer, then upload to Google Drive, then download to Android.

That's four steps for one file transfer.

Some people skip the middle steps by using the Google Drive app on iPhone to upload directly, but it still requires:

Sufficient cloud storage (free tiers are 5-15GB)
Upload time (slow for large files)
Download time on the other end
Best for: Archiving and long-term access. Skip if: You want to move files right now, without waiting.

Option 3: Messaging Apps (WhatsApp, Telegram)
This is what most people default to. It's convenient because you both already have the apps.

The problem? Quality loss.

WhatsApp compresses photos and videos. That 4K video you shot? It arrives looking like 720p. Telegram has better compression but still alters the files.

Also, size limits apply: WhatsApp caps at 2GB, Telegram at 4GB. Fine for casual sharing, but not for large projects.

Best for: Quick, casual sharing where quality doesn't matter. Skip if: You need original quality or files larger than 2GB.

Option 4: Dedicated Transfer Apps (Send Anywhere, SHAREit)
Apps built specifically for cross-platform file transfer solve some of these problems — but introduce new ones.

Send Anywhere: Works well, generates a 6-digit code. Both devices need the app installed. Limited to 1GB per transfer on most plans.

SHAREit: Popular in some regions. Fast, but known for aggressive ads and tracking.

Xender: Ad-supported. No size limit. Both devices need the app.

The common catch: you have to install an app on both devices, and hope the other person is willing to do the same.

Best for: Occasional transfers when you both already have the app. Skip if: You don't want to install yet another app.

Option 5: Browser-Based P2P (The TransP2P Approach)
This is the approach that avoids almost all of the above problems — and it's surprisingly simple.

How it works: Two browsers create a direct peer-to-peer connection. Your file goes from one device to the other, period. No server in between. No upload, no download. Just direct transfer.

Step-by-Step (Same for Both Devices)
Both devices open transp2p.com in their browser
One device creates a room, generating a 6-digit code (or QR code)
The other device enters the code or scans the QR
The connection is established — now both sides can send and receive files freely
Drag and drop files. They transfer directly. Like chatting.
That's it. No app installation. No account creation. No file size limits.

Why This Works So Well
Speed: On local Wi-Fi, it's as fast as AirDrop. Over the internet, transfers start immediately — no "upload first" delay.

Privacy: Files go directly between devices. No third-party server ever touches your data.

File Size: No limits. A 10MB PDF and a 50GB video project work the same way.

Resume Support: If the connection drops (Wi-Fi briefly disconnects, someone walks out of range), TransP2P resumes from where it left off. You don't have to start over — unlike cloud uploads or most apps.

Cross-Platform: Any device with a modern browser can participate. iPhone, Android, Windows, Mac, Linux — they all work.

The Only Limitation
You need an internet connection to establish the connection. Once connected, the transfer itself is direct (P2P), but the initial handshake requires connectivity. The cache mode offers an alternative if the recipient isn't available immediately.

Quick Comparison
Method Need to Install File Size Limit Quality Loss Privacy
USB Cable Drivers only None No High
Cloud Storage No 5-15GB free No Low
Messaging Apps Both have it 2-4GB Yes Low
Transfer Apps Both install 1GB+ No Medium
TransP2P (P2P) Neither None No Highest
When to Use Each Method
TransP2P works for:

iPhone ↔ Android (no native option exists)
Large files (videos, archives, project files)
Privacy-sensitive transfers
Quick transfers without app installation
Use other methods when:

Native options work (AirDrop for Apple-only, Quick Share for Android-only)
The recipient prefers a specific app
You need long-term storage, not just transfer
The Bottom Line
Cross-platform file transfer doesn't have to be complicated. The browser-based P2P approach removes the two biggest barriers: app installation and file size limits.

If you regularly transfer files between iPhone and Android, or between different devices in general, it's worth trying a browser-based tool. No commitment, no account, no setup — just open, connect, and send.

Originally published on the TransP2P Blog. For more guides, tutorials, and file transfer comparisons, visit the blog.

Building Browser-to-Browser File Transfer with WebRTC: What I Learned Building TransP2P

KaiDev — Mon, 04 May 2026 09:00:58 +0000

TL;DR: I built a P2P file transfer tool that runs entirely in the browser. No install, no server relay, no account. Here's what I learned about WebRTC data channels, resumable transfers, and the browser storage mess along the way.

Most file transfer tools follow the same pattern: upload to a server, get a link, the recipient downloads from that server. Your file sits on someone else's infrastructure, at least for a while.

I wanted to try a different approach: what if the file never leaves the browser at all?

That question turned into TransP2P — a browser-based P2P file transfer tool built on WebRTC. In this post I'll walk through the technical decisions, the parts that were harder than expected, and the two browser storage paths that almost no one talks about.

The basic architecture

The flow is straightforward in theory:

Both devices open the site (no install, no account).
A WebSocket signaling server helps them exchange SDP offers/answers and ICE candidates.
A direct WebRTC data channel is established.
The file is chunked and sent over the data channel.
The receiver reassembles the chunks and saves the file.

The signaling server never touches the file data. Once the connection is established, it's just helping with connection maintenance.

Chunking everything — even when you don't need to

One early decision that paid off: every file is chunked during transfer, regardless of whether resumable transfer is enabled.

The alternative — sending a file as one blob — seems simpler but creates problems fast. Large files block the main thread, and any network hiccup means starting over.

With chunking, each piece is typically 64 KB. The sender streams chunks over the data channel; the receiver buffers them in memory and writes to disk on download. This gives the best speed because there's no intermediate disk I/O during the transfer itself — the bottleneck is the data channel throughput, not your disk.

The resumable transfer problem (and why there are two solutions)

Resumable transfer was where things got interesting — and where browser differences forced two completely separate implementations.

The goal

If a transfer is interrupted (network drops, user closes the tab), the receiver should be able to resume from where it left off, not start from zero.

The core idea is simple: track which chunks have been received, and tell the sender to start from chunk N on reconnect.

But where you store those chunks is the hard part, because browsers don't give you raw disk access. And they definitely don't all give you the same APIs.

Path 1: OPFS + File System Access API (Chrome, Edge, Firefox)

Modern Chromium-based browsers and newer Firefox versions support the Origin Private File System (OPFS). OPFS lets you write files in a sandboxed origin-private directory, and it's fast — writes happen off the main thread when used with Web Workers.

My implementation:

File chunks are written directly into OPFS using a writable stream from a Web Worker. This bypasses the browser's memory limit entirely — you can handle files that are gigabytes in size.
File metadata (chunk count, received chunk indices, file name, total size) is stored in IndexedDB, because it's small, structured, and queryable.

On reconnection, the receiver queries IndexedDB to check whether the transfer was completed for that file. If not, it sends the last successfully received chunk index to the sender via the signaling channel. The sender skips ahead and starts from that chunk.

Path 2: IndexedDB only (Safari / iOS)

Safari does not support OPFS access from Web Workers, and the File System Access API is entirely unavailable on iOS. That means you can't stream to disk off the main thread.

For Safari users, the fallback is IndexedDB for everything — both the file chunks and the metadata.

This works, but it has a ceiling. IndexedDB stores data in memory before flushing to disk, so very large files eventually hit Safari's memory limit. On iOS in particular, the limits are strict — file size is effectively capped, and the experience degrades gracefully by showing a size warning before the transfer starts.

It's not ideal, but it's honest. The tool tells you what your browser can and can't do, rather than failing silently.

Signaling: keep it minimal

The signaling server's only job is to relay SDP and ICE candidates between peers until the WebRTC connection is established. I use WebSocket for this — it's simple, widely supported, and low-latency.

The server doesn't authenticate users (no account needed), doesn't store messages beyond the active session, and doesn't know what's being transferred. Once the data channel opens, the signaling server becomes irrelevant to the transfer.

For production, you do need STUN/TURN servers so peers behind NAT can connect. I use a combination of public STUN servers and a self-hosted TURN server for scenarios where UDP is blocked.

Bypassing browser memory limits

This is the part that surprised me most: the data channel itself doesn't have a memory problem — the receiver's storage strategy does.

If you receive a 2 GB file and try to reassemble it in an ArrayBuffer, you'll crash the browser. The key is streaming the incoming chunks directly to storage (OPFS or IndexedDB) without holding the whole file in memory.

With OPFS + a Web Worker, this works beautifully — the main thread stays responsive, and the file never exists as a single in-memory object. This is how TransP2P can handle multi-gigabyte files on supported browsers.

Safari and iOS Safari can't do this, which brings us back to the two-path problem. It's a good reminder that "works in the browser" and "works equally across all browsers" are two different statements.

Async mode: when P2P isn't possible

P2P is great when both peers are online simultaneously. But sometimes you want to send a file to someone who isn't online yet, or the connection keeps failing.

For this, TransP2P has an optional server cache mode. You upload the file to the server (encrypted, with a randomly generated key that's never sent to the server), get a download link or code, and the recipient retrieves it later. Files expire automatically — either after a set time or after a download count is reached.

This is a paid feature because it consumes server resources, but the encryption design means the server never sees the file contents. The encryption key is derived client-side and embedded in the download link fragment (the part after #), so it never reaches the server at all.

Things I wish I knew earlier

ICE candidate gathering takes time. Don't assume the connection is stuck — it often just needs a few more seconds. Show feedback to the user.

Mobile browsers are not desktop browsers. iOS Safari has the tightest restrictions of any modern browser. Test on it early, not after launch.

Data channel reliability vs speed is a tradeoff. ordered: true gives you guaranteed ordering but can stall on packet loss. For file transfer, I went with ordered: true and chunk-level checksumming — the stall is rare in practice and ordering bugs are worse.

People don't understand "P2P". The biggest UX challenge wasn't technical — it was explaining why the file transfers without uploading. If you build something similar, spend time on the "how it works" copy.

Try it / See the code

TransP2P is free to use (the P2P mode is entirely free; server cache is paid). No account, no install:

https://transp2p.com

The site also has a few longer reads on how P2P file transfer actually works and the hidden privacy risks of cloud-based file transfer — written for a general audience if you're curious about the non-technical side of this.

If you've built something with WebRTC data channels, I'd love to hear what tradeoffs you made — particularly around large file handling. The browser storage landscape is still messy in 2026, and more field reports would help everyone.

This post was originally written by the author of TransP2P. If you're working on P2P tools or browser-based file transfer, feel free to reach out.

I built an AI Image Upscaler that runs 100% in the browser (no server uploads)

KaiDev — Wed, 08 Apr 2026 08:50:21 +0000

I’ve been building AI tools for the web, and I just launched a lightweight AI image upscaler that works entirely in your browser.

The main goal was simple: privacy + speed + no bloat.

✨ Key Features

100% local in-browser processing (your images never leave your device)
Upscale photos, anime, and digital art up to 4K resolution
No sign-up required, no watermarks on free outputs
3 free daily uses for everyone
Clean, fast UI with zero unnecessary bloat

🛠️ Tech Stack

Frontend: Astro + TypeScript + Preact
AI Runtime: TensorFlow.js / ONNX Runtime Web
Models: Optimized real-world AI upscaling models for web performance

If you’re into AI on the web, browser-side machine learning, or just need a private, no-fuss tool to enhance your photos, give it a try. I’d love to hear your feedback and feature requests!

🔗 Try it here: https://imgupscaleai.com

I Built an AI Image Upscaler — Welcome Any Feedback

KaiDev — Fri, 03 Apr 2026 10:48:20 +0000

Hi everyone 👋

I’m a solo indie developer building lightweight, browser-based AI tools.

Lately I’ve been working on an AI image upscaler — something I built to fix a really common problem:
blurry small images, old photos, compressed screenshots, and pictures you just can’t safely upload to third-party servers.

What it helps you do:

Clean up and sharpen blurry screenshots, old photos, and low-res social images
Enlarge small pictures without pixelation
Fix compression artifacts from repeated saving or messaging apps
Process sensitive or private images safely, all within your browser

This tool is made for:

Content creators and social media users who need clean, clear images for posts
People looking to restore and digitize old family photos
Professionals working on presentations, resumes, and reports with blurry assets
Online sellers who need to enhance product images quickly
Anyone who values privacy and doesn’t want to upload personal files externally

It’s simple, fast, and designed for real daily use cases — not overbuilt for professional studios.

You can check it out here: https://imgupscaleai.com
I’m here to share my progress, learn from other builders, and get feedback.
Nice to meet you all!

introduction #indiedev #ai #webdev #tools #contentcreation