A lot of AI-backed services end up needing a person to make a call: approve this, decline that, answer a question the system can't answer for itself. The fastest place to make that call is the phone already in your pocket. I build native SwiftUI iPhone apps that put those decisions on the lock screen and send the answer back reliably, even when the signal doesn't cooperate.
Why Native
A web dashboard is fine when you're at a desk. It's the wrong tool when a decision needs to happen in the next five minutes and you're somewhere else. A native app gets things the browser can't do well: push notifications with action buttons you can use without unlocking, interruption levels that match how urgent something really is, credentials held in the Keychain, and a camera that can scan a QR code in one tap.
I learned Swift by shipping the app my own booking business runs on. It went from my first Swift file to production in months, and it has been in daily use since. That's the Gaines Concierge case study, and most of what follows comes from building it.
What I Build
- Operator consoles for AI and web services — the decisions your system needs from a person, delivered as prompts they can answer from anywhere
- Actionable push notifications — APNs categories with Approve/Decline actions on the lock screen, with urgency mapped to interruption level
- Typed API contracts in Swift — a Swift package that holds every request and response type and is tested against the same JSON fixtures as the server
- Offline-tolerant writes — answers given with no signal are saved and retried with their original idempotency key, so nothing is lost and nothing happens twice
- Secure device setup — Keychain-backed tokens and provisioning that doesn't need Xcode
- Camera workflows — QR scanning for intake, hand-off, and lookup
How I Build Them
Contract first
The app and the server agree on a written contract before either side writes code: routes, payloads, error codes, and the rules for retrying. A machine-readable OpenAPI mirror and a folder of example payloads sit next to it in git. Both sides test against those same files, so if one of them drifts, a test fails before a user sees it.
Tolerant of what it doesn't know yet
Servers change faster than App Store releases. I use open enums for anything the server might extend, such as kinds, statuses, and error codes. If the server sends a value this build has never seen, that one item degrades to a read-only notice. A strict decoder would have rejected the whole response, and the app would have shown nothing.
"Push is best-effort. Notifications get dropped, delayed, and coalesced. The app is designed so that a missed push costs you a few seconds, never a lost decision."
Thin client, honest state
The real work stays on the server. The phone shows what needs a decision and sends the answer. Whatever surface a decision is made on, it goes through the same server path, so approving on a laptop also clears the question on the phone.
Good Fits
- Approval steps in an AI or agent workflow that need a quick human yes or no
- Small-business tools such as bookings, intake, and dispatch that need someone to respond quickly
- A mobile companion for an existing Flask, FastAPI, or Node backend
- Turning a web dashboard nobody checks into notifications people actually act on
Need an App That Answers Back?
If your service needs a person in the loop, I can design the contract, build the iPhone app, and wire it to your backend, from start to finish.
Talk About Your App