Why personal iPhone apps are finally worth building • VelvetShark<br>Toggle dark / light mode

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:

Inspect the untouched project.

Build the entry screen, Today screen, persistence, and rollover logic.

Add completion, locking, animation, and haptic feedback.

Launch a pending card for the camera.

Harden the date logic and add automated checks.

Polish the interface.

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...