Coding on an iPad
For the last stretch of work I have not opened my laptop. My main machine is an iPad: Blink Shell over mosh into a dedicated server, the same Neovim setup I ran on my Mac, Herdr as the multiplexer, Tailscale for the dev URLs. Here is the whole workflow, and the one piece that was missing badly enough that I had to build it.
Why an iPad works now, and did not before
Most of my code is not typed by me anymore. Agents write it. My job has shifted to orchestration and supervision: describing what should exist, reading what came back, and verifying that it actually works.
That changes what a machine has to be. When you type every character, local tooling and latency matter enormously. When you mostly read, review and steer, the machine in front of you is a terminal and a browser. Once that was true, where I sat stopped mattering, and the iPad stopped being a compromise.
The verification half is still real work, though. You open the app, you poke at the DOM, you watch a request fire, you check what landed in a cookie. Hold that thought.
The setup, piece by piece
Blink Shell, over mosh. The iPad runs Blink Shell, and I connect with mosh rather than plain SSH. That single choice is what makes tablet development bearable. SSH sessions die: you lose signal in a tunnel, you switch from wifi to cellular, the iPad sleeps, and whatever you were in the middle of goes with it. Mosh survives all of it. It roams across networks and renders keystrokes locally, so the terminal stays responsive on a bad connection. I put the iPad down for three hours, pick it up, and the session is exactly where I left it.
A dedicated server does the work. The code lives on the server. The agents run there. Builds, dev servers, test suites, containers, all of it runs on hardware that is plugged into a wall and has no battery to protect. The iPad never compiles anything, never installs a toolchain, and has no repository checked out. This is also why "an iPad is not powerful enough" misses: the iPad's job is to draw text and pixels, and the power sits elsewhere, on a machine far beyond anything I would carry.
Neovim, unchanged. This is the part people do not believe. It is the same Neovim configuration I ran on my Mac: same plugins, same LSP setup, same keymaps. I did not build a tablet version of my editor. I moved the config to the server and carried on working. Nothing in Neovim cares that the terminal at the other end of the pipe is an iPad, which is the whole point of a terminal editor and the reason the move cost me roughly zero days of adjustment.
Herdr as the multiplexer. For splitting the session I use Herdr, a terminal workspace manager built for AI coding agents rather than adapted to them. Panes, tabs, workspaces, sessions that persist on the server, and an agent-aware layer on top: I can see which pane is running what and get told when something needs me. With several agents working at once, the multiplexer stops being a window manager and becomes the dashboard for the actual work.
Tailscale for the dev URLs. The dev server binds to a port on the remote machine. Tailscale puts the iPad and the server on the same private network, so I open the dev URL on the iPad as though it were localhost. No public tunnel, no port forwarding, no address anyone else could stumble onto.
Orion as the browser. I browse those dev sites in Orion by Kagi, for exactly one reason, which is where the whole arrangement nearly fell over.
The tablet browser has no F12
On a laptop, verifying an agent's work is trivial: open the page, hit F12, look inside.
On an iPad there is no F12. iPadOS browsers ship no developer tools, and Apple's rules mean desktop Chrome's inspector is not available there at all. I could see my app. I could not look inside it. Every time something rendered wrong I was back to guessing, or reaching for a laptop, which defeats the entire arrangement.
What iPadOS does have, thanks to Orion, is extensions. Orion runs Chrome and Firefox web extensions on iOS and iPadOS. Support is still maturing and not every extension API exists there, but it is real, and it is the only game in town on a tablet. Chrome itself supports no extensions on iPad or Android, which still surprises people.
So the answer became obvious. If the browser will not give me developer tools but it will run an extension, then the developer tools should be an extension.
Inspector Lab - DevTools
Inspector Lab - DevTools is what I built. It is a Manifest V3 extension that drops a full devtools window directly onto the page you are looking at. Not a panel in a separate app, not a remote debugging session: a movable, resizable inspector rendered into the page itself, inside an isolated Shadow DOM.
It carries the panels you actually reach for all day:
- Elements, with a live DOM tree, an element picker, in-place editing of attributes and text, a styles pane where you can author and toggle declarations, forced element states, and a computed pane with the box-model diagram.
- Console, capturing the page's own logs with
file:linesource links, and evaluating expressions in the page's real JavaScript context. - Network, with live fetch and XHR capture: method, URL, request and response headers, status, timing and bodies, in a details pane that reads like the one you know.
- Sources, as a collapsible file tree with syntax highlighting, fetching external files on demand.
- Cookies and Storage, both editable in place.
It launches from the extension popup with a user gesture and temporary activeTab access, so it holds no standing permission to read every site you visit. It drags anywhere, docks to any viewport edge, remembers the panel you last used per site, and comes back after a reload until you dismiss it. It collects nothing, transmits nothing, and has no servers at all.
Everything it does happens through content scripts and standard extension APIs on the page itself. No debugger protocol, no desktop-only surfaces. That constraint is the design: if a browser can run the extension, you get an inspector on the device you are actually holding.
The details nobody thinks about until they build for a tablet
My favourite is iOS Smart Punctuation. It rewrites "log" into curly quotes and i-- into an em dash while you type, and JavaScript rejects both. So when a console expression fails to parse and curly punctuation is what stopped it, the prompt retries it straightened, and only then, so a curly apostrophe you deliberately pasted inside a string is never touched.
There is also a diagnostics log in the popup: a local ring buffer of the extension's own errors and of sessions that ended without a clean close. It exists because an iPad has no console you can go and check after a crash. Local only, capped, never transmitted.
It does not replace the full DevTools application, and it does not pretend to. Breakpoints, CPU profiling and bypassing a page's Content Security Policy genuinely require the debugger protocol, and they are out of scope by design. On iOS, where the extension API surface is trimmed, some panels fall back to in-page sources and say so on screen rather than going dark. The goal is the twenty inspections you actually do all day, two taps from the page you are supervising.
The loop, end to end
Put together, an ordinary working hour looks like this:
- iPad, Blink, mosh into the server. The session is where I left it.
- Herdr for panes: Neovim in one, agents in others, dev server running.
- Describe what should exist. The agent writes it.
- Open the Tailscale dev URL in Orion, on the same iPad, and reload.
- Tap the extension and verify properly: pick the element, check the computed styles, watch the request fire, read what landed in storage.
- Feed back what is wrong. Repeat.
No switch to another device. No "I will check that properly later". The verification step sits on the same screen as everything else, which is the only reason the whole arrangement holds together.
What actually makes it work
The hard part is not the iPad. The hard part is deciding that your environment lives on a server and committing to it. Once your editor, your agents, your dev server and your sessions are all remote, the client becomes almost irrelevant, and an iPad is a very good client: excellent screen, all-day battery, instant wake, cellular.
Inspector Lab - DevTools is MIT licensed, installs from the Chrome Web Store on desktop and on the iPad alike, and the source is on GitHub. It turns out to be pleasant on desktop Chrome too: an inspector that lives inside the viewport, remembers its panel per site, and comes back after every reload is useful even where F12 exists.