Shipping a Code Editor for Phones: What Broke
Keyboards, memory ceilings, gesture conflicts — an honest list of what it took to make typing code on a phone feel right.
Everyone told us coding on a phone was a toy use case. They were wrong about the demand and right about the difficulty. The phone is where developers read, review and patch — and the moment we treated reading code as a first-class activity, the product clicked.
What broke first: the keyboard. An on-screen keyboard hides half the screen and changes height per device, so the editor had to become a layout-aware component, not a fixed view. We rebuilt scrolling and cursor handling around the keyboard's animations, and typing latency finally felt native.
What broke second: memory. A full workspace tree, an editor bundle and an AI context window don't fit in a mid-range phone's budget. The fix was lazy everything — worktrees load on demand, file contents are paged, the AI context is assembled from summaries instead of raw files.
What broke third: assumptions. We assumed people would write features on phones; mostly they review diffs, fix bugs and unblock teammates. Leaning into that reality simplified the UI more than any redesign had.
The meta-lesson: constraints are the spec. Every phone limitation we embraced produced a better product than the desktop assumptions we started with.
Written by
Abdullah A.A.
Full-Stack Developer & Product Builder