Why personal iPhone apps are finally worth building

Xcode has let developers install their own builds on an iPhone for years. I could have done it long ago.

I also could have spent weeks learning Swift for a tool with one user. I never had a good enough reason to do that.

AI coding agents changed the trade. I can describe the rules, let the agent handle the implementation, run the tests, and get a native build onto my phone in an evening.

I wanted to see whether that held up outside a demo.

A small app with real behavior

Every evening, I write tomorrow's main priority on a paper card. Underneath it, I add a smaller fallback that still counts if the day goes wrong. The rule works well, but the card usually stays on my desk.

I wanted the same rule on my phone as a real native app. A mock-up would not help me the next morning, and a browser shortcut was not the experiment I wanted to run.

The app is called One Move.

In the evening, I enter two things:

• X: the outcome I intend to complete tomorrow
• x: the smallest fallback that still counts

The next day, both appear on a read-only screen. I can complete one with a single tap, which locks the other choice. There is no undo, streak, history, account, notification system, or social layer.

The date behavior needed more care than the interface. A declaration from tonight should appear tomorrow. If I ignore the app for two days, the old commitment should disappear rather than hang around as unfinished work.

Everything is stored locally with UserDefaults. The app has no application backend, web host, account system, or remote database.

Why a native app now makes sense

A PWA would have been another option. Simple web apps can store data locally and install from a browser. They are a good answer for many personal tools.

I wanted native behavior and a project that could grow without starting as a hosted product. That meant SwiftUI, local storage, and a development build installed through Xcode. I could stop once it worked on my phone.

Installing the development build followed the usual Xcode path: create the project, sign the build, choose the phone, press Run. The useful change came before that. I could test the idea without first spending weeks learning the platform.

This gets more interesting once a personal app grows beyond a toy. One workflow can turn into several screens, imports, richer local data, or automations. Those features still require clear requirements and tests, but they do not need a market or release plan to justify the first version.

Starting from Apple's blank project

I created a standard SwiftUI project and asked Codex to inspect it before changing anything. The second prompt contained the full rules and asked for the first working slice: tomorrow's entry screen, today's read-only card, local persistence, and day rollover.

I built the rest in small steps:

1. Inspect the untouched project.
2. Build the entry screen, Today screen, persistence, and rollover logic.
3. Add completion, locking, animation, and haptic feedback.
4. Launch a pending card for the camera.
5. Harden the date logic and add automated checks.
6. Polish the interface.
7. Add the icon and home-screen name.

The public repository contains the full source, original specification, and all seven prompts.

Testing the day logic

Calendar behavior is easy to demonstrate badly. Changing a simulator date and seeing one expected screen does not prove the other transitions work.

I asked Codex to make the clock injectable and automate seven cases:

• a same-day relaunch keeps tomorrow's declaration
• the first open on the next day promotes it to today
• the first open two days later drops it
• a second declaration on the same evening replaces the first
• the Today screen uses the correct empty-state copy
• completing X or x locks the other choice
• completion survives a relaunch

All seven tests passed again from a clean clone before I prepared the public repository.

The simulator covered the state transitions. It could not prove signing, installation, the home-screen icon, haptics, or persistence on the device I would actually carry.

Putting the build on my iPhone

I connected my iPhone, selected my Apple Developer Team, confirmed Developer Mode was already enabled, chose the phone as the run destination, and pressed Run.

One Move appeared on the home screen with its own name and icon. I entered a real declaration for the next day, quit the app, and opened it again from the icon. The state was still there.

I also turned on Airplane Mode and checked the project for networking code. One Move continued to work because it had no application service to contact.

You can do personal on-device testing with a free Apple Account. Xcode calls that a Personal Team. Apple currently says free accounts can register 10 App IDs and three test devices per platform; those registrations and provisioning profiles expire after seven days. You may need to rebuild and reinstall the app when the profile expires. A paid Developer Program membership removes those short free-provisioning windows and adds distribution features.

Apple explains the current differences on its membership comparison page.

What I skipped

I stopped at the version I actually needed. I did not add an application backend, web host, account system, TestFlight release, or App Store submission.

That saved more work than the coding session alone suggests. A public app needs decisions about authentication, sync, privacy, support, analytics, distribution, and a wider range of devices. A phone-local development build can leave that entire layer out.

Apple's development system still sits underneath the whole thing. Xcode signs the build, the phone may require Developer Mode, and free provisioning expires. The route is shorter, with Apple's normal development rules intact.

The receipt

I tracked the session because “AI made it easy” says very little without numbers.

• Recorded build: 2 hours
• Preparation: 1 hour
• Dry runs: 0
• Prompts in the recorded session: 7
• Manual interventions: 1
• Swift written by me: 0 lines
• Cost beyond subscriptions I already had: $0

The one manual intervention was selecting my Developer Team in Xcode. I never opened a Swift file to repair the implementation by hand.

One Move is a modest app, and those numbers should not be stretched into a claim about every iOS project. They do show that the whole route can fit into an evening: blank project, real behavior, automated checks, physical-device installation, and a persistent state that survives until the next day.

The next morning

The following morning, the declaration from the night before was waiting on the Today screen. I used it and completed one of the choices.

I still like the paper cards. Writing them is part of the ritual. The phone version covers the moments when the card stays behind.

The part I keep thinking about is what I would build next. I can keep an app small, or add complexity when it helps me. I do not need to pretend it is a startup, design for a market, or maintain infrastructure the app never needed.

I have a whole category of ideas that were too specific to justify weeks of work and too useful to leave as notes. Those ideas can now become real apps.

Build your own version

The One Move repository includes:

• the SwiftUI source
• the full app specification
• every prompt from the recorded build
• the automated day-logic tests
• the app icon
• instructions for installing it on your own iPhone

You can clone One Move, although my ritual probably is not your ritual. The useful part is the pattern. Pick a recurring task, spreadsheet, note, or workaround that already matters to you. Build the first version, put it on your phone, and let your own use decide how far it should grow.