CodeMote

Using an iPad for real development work

By Salvatore Castellitti, developer of CodeMote · 21 July 2026

The "can you code on an iPad" question comes up every year, and the answer is always some version of no: iPadOS won't give you a real filesystem, a real terminal, or a real toolchain, and the workarounds are worse than carrying a laptop.

I don't try to make the iPad do any of that anymore. My dev machine is a desktop at home (a VPS works identically), it runs a small host process, and the iPad opens a browser tab that renders the workspace: files, editor, terminals, git, Claude Code sessions. Compiles happen on the desktop. The iPad contributes a screen, a keyboard and long battery life, which are the things it's actually good at.

This has been my travel setup for a while now. Below is the setup and an honest list of what works and what doesn't.

Setup

On the machine that will do the computing, inside a project:

npx codemote-cli start

Node 18+ required. It prints a pairing code. On the iPad, open the connect page in Safari and paste it. The connection is an outbound tunnel from the host machine, so it works even when that machine sits behind home NAT with nothing forwarded; this post covers how.

What works better than I expected

Typing, with a real keyboard. With the Magic Keyboard or any Bluetooth keyboard, editing feels close to editing on a laptop. The workspace is built keyboard-first, so most shortcuts I reach for exist.

Terminals. They're real PTYs on the host machine, so anything that machine can run, the iPad can display: builds, test watchers, htop. And because the sessions live on the host, Safari's habit of suspending background tabs doesn't destroy anything. Come back to the tab, it reconnects, the terminal is where you left it. Without that property this whole setup would be unusable, because Safari suspends tabs constantly.

Reviewing agent work. This has quietly become my main iPad use case. I start Claude Code tasks at the desk during the day; in the evening I read the diffs and answer permission prompts from the couch. Reading a diff on a touchscreen is comfortable. Writing code on glass is not, and this split means I rarely have to.

What doesn't work, so you're not surprised

Safari keeps some keyboard shortcuts for itself and there's nothing to be done about it. Cmd-W closes the tab, not your editor split. You adapt, mostly, but the first week involves reopening the workspace more than you'd like.

There's no meaningful local-file story. Dragging a file from the iPad's Files app into the remote workspace isn't a thing I do; when I need to get an asset onto the dev machine, I still use cloud storage or AirDrop to another machine.

Latency is real physics. Host and iPad on the same continent: feels local. When I was in a different timezone from my desktop, keystrokes in the editor had a small but noticeable delay. Terminals tolerate this better than editing does.

And the obvious one: if the host machine is off or asleep, the iPad is a very nice screen showing a reconnect spinner. Sleep settings on the host matter more than anything on the iPad side.

Why not just pay for a cloud IDE

Codespaces and similar tools solve the same problem, and if your employer pays for them, fine. For personal work the calculation didn't favor them for me: metered hours, cold starts, and my code sitting on infrastructure I don't control, versus a machine I already own running a free host process. The cost comparison is its own post; short version, a $6 VPS embarrasses the metered pricing for daily use.

The larger thing I noticed after a few months: the question "which device do I need to buy to code comfortably while traveling" stopped mattering. Any browser is the same workspace now. The iPad happens to be the nicest screen-and-battery combination I own, so that's what comes along.

Beta signup is on the homepage if you want to try it with hardware you already have.