Build an iPhone app from your iPhone
Use your iPhone to control a remote coding agent, run a cloud iOS build, and test with TestFlight—with an honest guide to what still needs a computer.
· 8 min read
You can build and test an iPhone app while using only your iPhone as the control screen. The coding agent runs on another computer or cloud server, and the Xcode build runs on a cloud Mac. Your phone starts the work, reviews the changes, and installs the result from TestFlight.
That wording matters. The iPhone is not locally compiling its own App Store binary. It is controlling a remote development system. Once that system is prepared, the loop can be genuinely phone-first: describe a change, let the agent implement it, trigger the build, test it, and report the next issue from the same device.
A phone-only workflow is excellent for iteration after setup. It is a poor place for the one-time work: creating Apple credentials, resolving a large merge conflict, or repairing a broken project structure. Prepare the runway first.
The four parts of a phone-first setup
| Part | Purpose | Example |
|---|---|---|
| iPhone | Prompts, reviews, screenshots, and real-device testing | Agent app or secure remote terminal + TestFlight |
| Agent host | Repository and coding process | Cloud agent, desktop host, or Linux VPS |
| Cloud Mac | Xcode compile, archive, and code signing | NoMac release build |
| Apple services | Build processing and beta distribution | App Store Connect + TestFlight |
You can swap the coding agent or its host without changing the Apple half. The essential requirements are that the agent can read the repository and call NoMac where that repository lives.
Choose how the iPhone reaches the agent
A mobile agent app
Cursor's iPhone and iPad app can start agents, track their work, review diffs, and notify you when input is needed. Cursor says its mobile experience can work with agents on its infrastructure or your own computer. See the official Cursor mobile announcement and the current iOS app documentation before choosing a host.
A secure remote session to a VPS
If your coding agent runs in a persistent terminal on a Linux server, the iPhone can connect through a secure SSH client or a private web terminal. The session should survive a temporary mobile-network interruption. Use SSH keys, restrict network access, and do not expose an unauthenticated terminal to the public internet.
The Hetzner Linux server case study shows this architecture in detail. The server keeps the repository and agent alive; NoMac is the separate macOS build worker.
Codex Remote—with one important limit
OpenAI's current official Codex Remote documentation says the ChatGPT mobile app connects to a Mac or Windows host running the desktop app. It does not connect directly to a Codex CLI or IDE session. That makes it useful for steering a prepared desktop session, but it is not the direct route to a headless Linux VPS.
Prepare everything before going phone-only
- ·Repository: the remote host has access, Git identity, the correct branch, and no uncommitted mystery changes.
- ·Project: a complete iOS project or workspace, known scheme, correct bundle ID, and explicit deployment target.
- ·Agent: installed, authenticated, and able to survive a disconnected mobile session.
- ·NoMac: authenticated beside the repository and registered as an MCP server for the agent.
- ·Apple: app record, connected API key, internal tester, and TestFlight installed on the iPhone.
Authenticate NoMac once on the agent host:
npx @nomac/cli login
Then configure the agent to launch npx @nomac/cli mcp. Exact examples are in the Claude Code guide, Cursor guide, Grok Build guide, and Codex guide.
A complete iteration from the iPhone
1. Ask for one observable change
Small tasks are easier to inspect on a small screen. Name the current behavior, the desired behavior, and the acceptance check. Avoid asking for a broad redesign while you cannot comfortably review dozens of files.
On the Add Expense screen, keep the Save button disabled until the amount is greater than zero and a category is selected. Show a short validation message after the user tries to save. Add unit tests for the validation rules. Inspect the existing design before changing it and do not change unrelated screens.
2. Review the summary and diff
Ask the agent to list changed files, tests added, unresolved warnings, and assumptions. On a phone, review risky files first: project settings, entitlements, dependency files, storage migrations, permissions, and anything that handles secrets.
3. Run a smoke build
Tell the agent to call push_project, start workflow=smoke, and pollstatus. If it fails, require get_failure and a plain-English root cause before approving a fix. Repeat until the compile check passes.
4. Approve a TestFlight release
Start workflow=release. NoMac archives and signs the app on macOS and uploads it to App Store Connect. Apple then processes the binary. When it becomes available, install the new build from TestFlight on the same iPhone.
5. Test and send evidence back
Reproduce the acceptance check. If it fails, take a screenshot and report the screen, exact taps, actual result, and expected result. If it passes, test one adjacent case such as an empty category, a decimal amount, backgrounding the app, or reopening saved data.
Design the work for a small screen
- ·Ask for a five-line status summary before a long explanation.
- ·Keep changes narrow enough that the diff is reviewable on a phone.
- ·Require the agent to call out project, signing, permission, and data-model changes.
- ·Use screenshots for layout bugs and exact reproduction steps for behavior bugs.
- ·Commit after a passing build so every working phone beta has a known source revision.
- ·Stop when the task becomes architecture work and continue from a larger screen.
What you can and cannot do comfortably
| Good phone-first tasks | Better on a computer |
|---|---|
| Small UI fixes and copy changes | Creating the first Apple account and credentials |
| Adding a contained feature | Resolving a large merge conflict |
| Starting builds and reading classified failures | Repairing a damaged Xcode project file |
| Installing and testing TestFlight builds | Pixel-level comparison across many screens |
| Reviewing focused diffs | Auditing a large dependency or security change |
The distinction is not about what is theoretically possible. It is about keeping enough context to make a good decision. A phone is unusually good for testing an iPhone app because it is the product's real environment. It is unusually bad for reviewing a 2,000-line project rewrite.
Safety rules for unattended agents
- ·Never paste the App Store Connect private key into a chat.
- ·Do not allow arbitrary public access to the agent host.
- ·Require confirmation before installing dependencies or changing entitlements.
- ·Let the agent create beta builds, but require a separate confirmation for App Store review.
- ·Keep branch protection, backups, and a remote Git history even when you work alone.
- ·Read the actual TestFlight build before accepting store metadata written by the agent.
Can you publish to the App Store from the iPhone?
The agent can prepare the release, run review_lint, fill metadata, upload screenshots, and stage publication through NoMac. You can review some App Store Connect state from Apple's mobile tools. But privacy, age rating, encryption, content rights, legal agreements, and the final submission still need an informed human answer.
Use the phone for the strong part of this workflow: rapid, real-device feedback. When the beta is stable, read Apple's paperwork blockers and the AI-built app review guide before authorizing submission.
The realistic answer
You can build an iPhone app from your iPhone if “from” means directing the work, reviewing it, triggering a remote Xcode build, and testing the native result. Set up the agent host and Apple connection once on a larger screen. After that, the iPhone can be the control room and the test device for a complete development loop.