My First iOS App
40 hours, two AI assistants, and a lot of waiting for Apple to approve things
My first iOS app is running on my phone. đ
This is a story about building an app. Itâs also a story about what AI makes more accessible, and what it doesnât.
I am not a mobile app developer. As previously shared, I code mainly in Python, with working and research-level experience programming in C, C++, and R. I have built interactive websites and systems in HTML, CSS, PHP, and ReactJS. But SwiftUI and Xcode were completely new territory.
What I also do have is a research background and a habit of thinking through systems⊠that turned out to be enough to get started.
If youâve been following me on Signal & Noise, you know that this is not my first time building AI-powered systems. Iâve built agents, platforms, and tools for governance and assurance. But those are set up for desktops and/or servers.
Native mobile is a completely different world.
You are dealing with Appleâs ecosystem, their developer program, provisioning profiles, App Store review timelines, Firebase setup specific to iOS, SwiftUI design patterns. None of that was familiar to me.
What I found truly fascinating was how much my two AI collaborators walked me through it, step by step.
It wasnât just the code. It was everything around it. Account creation, registration flows, configuring services, and understanding what each step was even for. I had never gone through this process before, so there was a lot of âokay, what does this screen mean, and what do I do here.â The LLMs handled that patiently. The only thing they could not speed up was waiting for Apple to approve things, which is its own exercise in accepting that some things just take as long as they take.
I used two AI tools in parallel, each with a different role. ChatGPT handled the thinking and planning side. Working through features, figuring out how flows should behave, stress-testing logic before anything got built. Claude handled the building: writing code, wiring components, refactoring when the structure needed to shift. One thing I found truly useful with Claude was setting up skills; basically, they are structured instructions that tell Claude how to behave for a specific kind of task. Instead of re-explaining the context every session, the skill carries the setup. It keeps the work consistent and cuts down on the overhead of getting the model oriented each time.
The screenshot Iâm sharing here is from one of those sessions. What youâre looking at is a handoff between two AI systems, with me sitting in the middle, managing scope, context, and intent.
That middle role, my role in the process, is more demanding than it sounds, and it is also where most of the real work sits. LLMs operate within context windows; the longer and messier a thread gets, the less useful the model becomes within it. You burn through credits faster, the outputs get less focused, and at some point, you are paying for noise. Managing this well means knowing when to summarize and reset a thread, what to carry forward and what to drop, and how to pass just enough context between sessions to keep the build coherent without starting from scratch every time. It is closer to project management than coding. You are constantly making decisions about what the model needs to know right now versus what is just overhead.
There is also a governance layer to this. Every handover between sessions required an audit of the system and updates to four or five documentation files: what was built, what changed, what the current state of the system was, what decisions were made, and why. To me, this is not optional overhead. It is how I keep the build coherent across 40 hours of work spread over weeks, with two different AI systems, and no shared memory between sessions. The documentation is the continuity. Without it, youâre relying on the next session to guess where you left off⊠it wonât.
The whole thing took roughly 40 hours of actual co-development time, spread across weeks because I had a real job running in parallel. Research meetings, consulting, governance work, everything else. I was building in the gaps. Some sessions were a few hours on a weekend. Others were 30 minutes squeezed between meetings.
The app started as a personal problem. I travel often and plan in detail. Flights, meals, check-ins, activity windows, and buffer time for the delayed connection that will definitely happen. I have tried many travel apps. None of them works the way I think it should. So I have been living in a very detailed Google Doc that my travel companions follow with varying levels of enthusiasm.
The app is running on my phone now. I am still stress-testing before I say more about the features, but if you are the kind of traveler who wants every booking detail accessible and every timeline structured, it was built for someone like you.
The app itself is almost secondary to what the process showed me. Getting a prototype off the ground used to mean assembling a team. I once flew a full-stack developer from Manila to Singapore just to get one started. That was not so long ago.
The barrier is lower now; much, much lower. What has not changed is what the system needs from the person driving it. The clarity about what it should do, enough domain knowledge to catch it when it wanders, and the patience to work through a process you have never done before⊠one unfamiliar screen at a time.