Architecture Notes
1.1.1 · Dev Platform

How to Implement iPhone Apps with Just an iPhone — a Build-Free Dev Loop

2026.07.02~8 min

00Overview

Tools

  • iPhoneThe main dev devicealready owned
  • Claude ProClaude Code on Web$20/mo
  • GitHubSource control + ActionsFree
  • EAS + Expo GoDelivery and on-device checksFree

01Story

Situation

As laid out in 1.1 the dev environment, there is no time in my day to open a PC. Development happens in the gaps or not at all.

Complication

And what can you do in those gaps? About as much as fiddling with a phone. On the sofa, under the bedtime blanket, on the train. One hand, one phone. That is the entire premise.

Question

Can you build an iPhone app with nothing but a phone?

02Solution

Criteria

  • An iPhone app can be built from a phone alone
  • It works without owning a Mac
  • Security holds — the AI never touches my own assets

Answer

# The full dev loop (the right end circles back to the iPhone)
iPhone → Claude Code on Web → GitHub → GitHub Actions → EAS → Expo Go → iPhone

Send a request from the Claude app on the iPhone, and everything from coding to updating the app in your hand flows automatically; minutes later you're checking the result in Expo Go on the same iPhone.

Ask from the iPhone, check on the iPhone.
And in between, not a single build.

Reason

I chose Claude Code on Web because of the sandbox. On each request, Claude Code on Web spins up a temporary Ubuntu environment in the cloud and runs Claude Code (the AI coding agent) inside it.

The usual Claude Code installs on a PC and runs there. That gives it access to local files, and it starts installing whatever tools it needs (with approval, but still). An AI free to wander around my own machine is, frankly, an uncomfortable feeling. — Though to be fair, my out-of-support Intel Mac can't run Claude Code properly anyway; even if it could, I don't think I would have chosen that path.

On Web, whatever the AI does happens inside a disposable Ubuntu, and it can never reach my assets. I can hand the work over with a clear head. That feeling of being able to fully delegate is what matters in gap-time development: you send the request, close the app, and go back to the kids.

GitHub is the piece that patches over the sandbox's volatility. A disposable environment loses its data when it ends, so the output needs somewhere else to live. That's GitHub: the home of the source and its history. On top of it, GitHub Actions — CI/CD that also spins up a temporary Linux box and runs your commands — takes over the automation downstream.

I chose EXPO because you can verify on a real device without building. EXPO is a React Native-based framework with EAS (Expo Application Services), its cloud platform, and Expo Go, an app for on-device checks. Push the repository's contents to EAS (an "update"), and the app inside Expo Go on your phone swaps itself out. No App Store in between. Which means there is no build anywhere in a development cycle.

Actions triggers on merges to the main branch. Connect it all and it looks like this:

# One cycle
1. Ask Claude to do something (iPhone)
2. Claude codes it and merges to main
3. The merge triggers GitHub Actions
4. Actions runs EAS Update
5. The app inside Expo Go updates itself
6. Check it on the iPhone → next request

From request to check feels like a few minutes. Queue up several requests in one gap, check and re-ask in the next. Spin this loop, and development advances on zero blocks of free time.

Lastly, EXPO being React Native-based also covers the iOS / Android requirement as-is. You can even check the Android side without owning an Android device.

Options

  • Codex (OpenAI) — when I tried it (spring 2026) it wasn't usable from the iPhone app, only through a browser, which failed the one-handed-phone UX test. Note that Codex landed in the ChatGPT app in May 2026, so it deserves a re-evaluation if you're choosing today.
  • Flutter — considered as the cross-platform alternative. But EXPO's PoC (Proof of Concept) satisfied every requirement before Flutter's PoC ever ran. It didn't lose a comparison; the comparison became unnecessary — that's the accurate telling.

03Result

Good

Ask in the Claude app, verify in Expo Go, on one and the same iPhone. The experience is genuinely comfortable. Claude thinks, implements, and the update reaches EAS in a few minutes — ten at the worst — but since you just send the request and walk away, it never grates. As a CI/CD setup for developing in scattered fragments of time, I suspect this is currently as good as it gets.

Cost is kind too. EXPO and GitHub both fit comfortably in their free tiers, so the loop itself adds zero extra cost.

Bad

The pipeline spans three clouds — Claude, GitHub, EAS — chained automatically, so one outage anywhere stops the whole loop.

A real example of how that bites: I fixed a bug, but it wasn't fixed. Strange. I went around the fix-check cycle a few times — and the punchline was an EAS-side outage; updates simply weren't being delivered. Without hard deadlines you can just wait these out, but when behavior looks wrong, check each cloud's status page first. About once a month, the right move is to suspect the infrastructure before your own code.

Follow-up

This loop gets you as far as "an app in development." Reaching the App Store requires build and submit — and the Mac problem re-enters. Continued in 1.1.2 How to build iPhone apps without a Mac.

Also: if you keep using this OTA delivery in production as-is, in-development code can accidentally reach released users during maintenance. Once you've shipped, read 1.1.3 Safe EAS Update operation to split the delivery paths safely.