How I built and shipped a real iOS app with AI in 14 days

Over Christmas I gave myself one constraint: ship a real iOS app in two weeks.

Not a prototype or a Figma concept. An app reviewed by Apple and available in the App Store.

Fourteen days later, Still was live. It asks for one sentence and one word a day. There are no accounts, feeds or streaks. It includes widgets, local notifications and on-device storage.

I built it with Claude, GPT and Xcode, without writing Swift by hand. This is the process, including the loops that failed.

If you want the whole thing in one scroll:

1. Set one constraint: one core behaviour, everything else optional
2. Get Claude working in the terminal and give it the permissions it needs
3. Get Xcode running and pay for the Apple Developer account early
4. Write one big prompt that creates a compiling SwiftUI project plus the core system
5. Once it runs, switch to small loops: one screen, one interaction, one edge case
6. Use GPT to clarify and structure, Claude to implement and refactor
7. When Claude is sure but wrong, force visible debugging before you retest
8. Ship: archive, upload, TestFlight, App Review, manual release

1. The constraint

It started with a selfish problem. I wanted a daily kick to get up and move: new-year resolutions, discipline, motivation. The first idea was a motivational quote every morning. While building it, the better version became quieter and more personal, a predictable ritual instead of a content stream.

No feeds.
No streaks.
No gamification.
No pressure.

One sentence a day, one word to reflect. That simplicity was not the starting point. It was the result of saying no, over and over.

This matters more than any prompt. You need a clear definition of what the app is and what it is not, because AI will happily generate fifty features you did not ask for, and your job is to keep the product coherent. It also helps to know what iOS expects at a basic level: widgets, notifications, capabilities, haptics, system conventions and where things tend to break. AI accelerates execution. It does not replace judgement.

The tools were ordinary:

• Claude for building and refactoring (about $20 a month)
• GPT for thinking, structuring and supporting tasks (free or about $20 a month)
• Xcode (free)
• Apple Developer account (99 euros a year)
• Figma, lightly, for supporting assets
• GitHub, because regressions will happen

2. Set up Apple’s environment early

Before the app, I had to learn to work with Claude itself. This is the part people skip, and then everything feels chaotic. The first terminal session looks like the Matrix. That is normal. The key is not being technical. The key is building trust in the loop: ask something, watch what it does, check the result, repeat.

Give it the permissions it needs early. Otherwise you spend the day clicking “Allow” and “Confirm”, and that kills flow. Then warm up with something trivial, like a hello-world website, so you see one task completed end to end before the stakes go up.

For Xcode I took screenshots of every unfamiliar dialog and dropped them into GPT: “What do I click here?” “What is this prompt asking for?” “Which settings matter for iOS development?” This sounds basic, but it is part of the truth: you do not need to know everything. You need to keep moving and remove blockers fast.

The biggest surprise was the paid Apple Developer account. I thought I could delay it. I could not. In the simulator, widgets behaved strangely, capabilities did not stick and notifications felt unreliable. I assumed bugs. The real issue was that I was building a system-integrated iOS app without Apple’s infrastructure set up. After enrolling, App Groups behaved consistently, widgets synced and notifications became predictable. Testing on my own phone became the source of truth. If you want to ship, do this early. It saves days.

3. Start with one end-to-end build

I did not start with small features. I started with one big prompt that did two things at once: create a proper SwiftUI Xcode project and implement the core idea of Still end to end. The prompt read like a spec:

• What Still is and what it is not
• Onboarding flow and user preferences
• Daily sentence logic and one word of reflection per day
• Local-only persistence, no backend, no accounts
• Widgets that must always show the same sentence as the app
• Local notifications and scheduling basics

Before sending it, I had GPT refine my messy version and add developer detail: edge cases, architecture, the persistence approach, the reality of widgets and notifications. Claude then generated a compiling project and a first working version. It was not perfect, but it ran.

That is the moment everything changes. Once you have a compiling project, you stop imagining and start shaping something real.

4. Switch to small, visible loops

Once the foundation existed, I changed how I worked. No more “build everything”. From here the loop was always the same: look at one screen, fix the UX first, then tune UI and interaction.

Does the screen do what it should?
Are the actions there?
Is the hierarchy right?
Does the flow make sense?

Then spacing, type, grid, consistent button styles, and the details that make it feel real: haptics, subtle motion, squircles, calm pacing. Simulator for speed, phone for truth.

The division of labour settled quickly. GPT helped me think: turning vague ideas into structured prompts, reasoning about bugs and how to instruct Claude, explaining Apple requirements, translations and tone checks, App Store Connect fields, legal and privacy texts. Claude helped me build: SwiftUI implementation, state handling, widget timelines, refactoring messy code. A typical loop: screenshot of a problem or an Apple form into GPT, explanation out, direct instruction into Claude. Not one AI building everything.

5. Test the system, not just screens

Even in a small app, systems break in subtle ways. These were real issues that only showed up through testing on a device:

• Widget and app showing different sentences. That can never happen. There must be one source of truth: widget, home screen and the daily logic all read the same stored state.
• Switching at midnight. The sentence changes at midnight in the app, so the widget must update at midnight too. Not on notification delivery, not “whenever”. The widget timeline had to follow app logic, not notification scheduling.
• Past days changing. Yesterday’s sentence changed after midnight because Claude was regenerating instead of persisting. That broke the whole concept. History must not change, so persistence and time became a system requirement, not a feature.
• Onboarding not syncing with settings. Preferences set during onboarding have to be reflected everywhere. State has to stay coherent.

These are not tiny bugs. They are the difference between an app that feels solid and one that feels random. A designer’s eye matters here: you notice the mismatch, you care, you enforce the system.

6. Make AI prove its fixes

This is where it got frustrating. Some things that look simple take absurd iteration. Switching the app icon in settings is a deceptively small feature; it took endless reprompts to get it stable across all cases. A full-width image or a precise layout rule could stall for an hour, because Claude can struggle with basic UI constraints. And it is often extremely confident that it is done when it is not. That is where you either quit or learn a better loop.

Claude’s default move when something failed was “please test and paste the console logs”. That works, but it is slow and makes you the log courier. So I changed the rule. When something feels off, Claude adds visible debug output in the console or on screen, runs the simulator itself and validates state and logic before coming back. Only after it has validated do I test again.

This one shift saved more time than any prompt trick. It forced the model to stop guessing and start proving.

7. Ship through TestFlight and review

Once the app was stable on my phone, shipping looked like this:

1. Archive the build in Xcode
2. Upload to App Store Connect
3. Fill in metadata in English and German
4. Create screenshots
5. Host the legal pages on my website
6. Set up TestFlight

For every field I did not understand, screenshot into GPT. That is how I handled most of App Store Connect. Then I shared Still with friends and family via TestFlight. About 13 people tested it for a few days; feedback came fast, mostly over WhatsApp, and caught issues before the public release.

The first App Review took a day or two. Once approved, I released manually. Still has been live since January 2026.

I had not written Swift by hand. But I had built a full system by directing the machine precisely and testing relentlessly.

8. Distribution is the next product problem

If software becomes easier to build, distribution becomes the bottleneck. I tried TikTok: new account, first videos, calm content. A day later the account was effectively shadow-banned, and I still do not know why. The algorithm is unforgiving.

So distribution is the next design problem I am working on. If you have experience there, I would like to hear it.

Still is available on the App Store. If you try it, I would genuinely like to hear what stays, and what gets in the way.