Wie ich meine erste iOS-App mit AI gebaut habe
TL;DR
- Ich habe Nami im App Store veröffentlicht, einen nativen SwiftUI Habit Tracker. Ich hatte vorher noch nie eine iOS-App geschrieben.
- Der Stack: Claude Code (Agent Teams + Custom Skills), Codex CLI, XcodeBuildMCP und ASC CLI.
- Ich habe zwei eigene Skills geschrieben,
ios-frontend-designundios-swift-dev(995 Zeilen), die sowohl Claude Code als auch Codex genutzt haben. - XcodeBuildMCP hat den agentischen Loop geschlossen: Agents konnten Code schreiben, testen, Screenshots machen und ihre eigene Arbeit validieren.
- Drei Wochen Entwicklung im Januar. Februar für Tests und App Store Connect. Null externe Swift-Package-Abhängigkeiten.
Das Problem
Ich wollte eine iOS-App bauen. Ich hatte noch nie eine geschrieben.
Ich wusste, dass es Swift gibt. Ich hatte SwiftUI-Demos gesehen. Aber echte Erfahrung mit Xcode-Projekten, State Management, StoreKit oder den ganzen Frameworks, die man für eine richtige App braucht? Null.
Der klassische Weg: Kurs machen, Tutorial-App bauen, dann die echte App. Das sind Monate. Ich wollte wissen, ob AI-Tooling inzwischen gut genug ist, um das deutlich zu verkürzen. Nicht durch Abkürzungen, sondern indem es die Stellen übernimmt, an denen ich sonst stundenlang Dokumentation lesen würde.
Die App
Nami (Daily Flow) ist ein Habit Tracker mit einer bewussten Einschränkung: Maximal drei Gewohnheiten. Das ist die Produktentscheidung. Kein Sammeln von Habits. Drei auswählen, dranbleiben, reflektieren.
Der technische Umfang:
- SwiftUI-only: Kein UIKit, keine externen Swift-Package-Abhängigkeiten
- SwiftData für Persistenz
- WidgetKit + ActivityKit (Dynamic Island)
- StoreKit 2 für In-App-Käufe
- UserNotifications für Erinnerungen
- Nur Dark Mode, OLED-optimiert
- Lokalisiert in Englisch und Deutsch
- 117 Swift-Dateien, umfassend getestet
Ich habe Nami bewusst so geschnitten, dass alles auf dem iPhone lebt. Diese Entscheidung hat alles geprägt.
Kein Backend-Server. Kein CloudKit-Sync. Keine externe Authentifizierung. Keine Abo-Infrastruktur. Keine Echtzeit-Kollaboration. Kein Multi-Device-Sync. Kein Push-Notification-Server. Alles läuft on-device, lokal persistiert mit SwiftData.
Jeder dieser Punkte ist ein eigenes Rabbit Hole. Allein CloudKit hat eine berüchtigt steile Lernkurve: Konfliktauflösung, CKSyncEngine, Subscription-basierte Benachrichtigungen, Offline-Caching-Strategien. Sign in with Apple ist Pflicht, sobald man Third-Party-Login anbietet, was Keychain-Management, Token-Handling und Session-Persistenz nach sich zieht. Auto-renewable Subscriptions bedeuten serverseitige Receipt-Validierung, Grace Periods, Billing-Retry-Logik und App Store Server Notifications. Und Multi-Device-Sync? Das ist ein eigenes Projekt.
Ich habe das alles übersprungen. Nicht weil diese Features unwichtig sind, sondern weil keines davon nötig war für einen Habit Tracker, der drei Dinge auf einem Gerät trackt. Das Ziel war eine voll funktionsfähige, feature-complete App, die ich tatsächlich in den App Store bringen kann. Kein Prototyp, aber auch nicht die komplexeste App der Welt. Ein MVP im besten Sinne: poliert, vollständig und eine App, die ich selbst jeden Tag benutze.
Die Toolchain
Was ich benutzt habe und wofür.
Claude Code: Spec + Design
Claude Code habe ich für Spezifikation und Design eingesetzt. Zu Beginn habe ich Agent Teams genutzt, um die App-Spezifikation durchzuarbeiten. Mehrere Claude-Instanzen, die Anforderungen prüfen, Lücken finden und das Design auf Herz und Nieren testen. Bevor ich auch nur eine Zeile Swift geschrieben habe.
Für die UI-Arbeit habe ich Claude Code mit einem eigenen ios-frontend-design Skill genutzt, der SwiftUI-Patterns, Layout-Regeln und die visuelle Sprache der App kodifiziert. In Claude Code wurde jede Idee in etwas Baubares geformt.
Codex CLI: Implementierung
Codex CLI hat die eigentliche Implementierung übernommen. Sobald Spec und Design standen, hat Codex den Swift-Code geschrieben, die Features umgesetzt und die Tests geschrieben. Es war das Arbeitstier, das Spezifikationen in funktionierenden Code verwandelt hat.
Geteilte Infrastruktur: XcodeBuildMCP + ASC CLI
Beide Umgebungen haben mit denselben Custom Skills und denselben Tools darunter gearbeitet.
XcodeBuildMCP war das kritischste Stück im gesamten Setup. Ein MCP-Server, der AI-Agents direkte Kontrolle über Xcode gibt: Builds, Simulator, Screenshots, UI-Interaktion und Tests.
Warum so kritisch? Ohne XcodeBuildMCP gibt es eine Lücke. AI-Agents können Code schreiben, aber sie können nicht sehen, was er tut. Sie können ihre eigene Arbeit nicht verifizieren. XcodeBuildMCP schließt genau diesen Loop. Der Agent schreibt Code, baut ihn, startet den Simulator, macht einen Screenshot, liest die UI und entscheidet, ob er nachbessern muss. Das ist nicht nur Automatisierung. Das ist der Agent, der seinen eigenen Output validiert. End-to-End-Tests werden zu etwas, das der Agent selbst ausführen und auf das er reagieren kann, statt etwas, das man hinterher prüft.
Mein Setup aus AGENTS.md:
session-set-defaults:
projectPath: dots/dots.xcodeproj
scheme: nami
simulatorName: "iPhone 17 Pro"
useLatestOS: true
Mit über 32 aktivierten XcodeBuildMCP-Methoden konnten beide Umgebungen builden, Unit Tests laufen lassen, den Simulator starten, Screenshots machen, die UI beschreiben und Elemente antippen. Die Feedback-Loop lief dutzende Male pro Session. Code schreiben, builden, testen, Screenshot, anpassen. Der agentische Loop, geschlossen.
ASC CLI hat die App Store Connect Automatisierung übernommen: Apps auflisten, In-App-Käufe verwalten, Screenshots hochladen, Einreichungsstatus prüfen. Ohne das Tool hätte ich Tage in der ASC-Weboberfläche verbracht.
Eigene Skills schreiben
Das war für mich der größte Hebel im gesamten Projekt.
Ich habe zwei eigene Skills geschrieben, die sowohl Claude Code als auch Codex im gesamten Projekt genutzt haben:
-
ios-frontend-design: iOS-Design-Patterns, SwiftUI-Komponenten-Konventionen und die visuelle Sprache der App. Dark Mode, OLED-sichere Farben, Layout-Regeln. -
ios-swift-dev: 995 Zeilen zu Swift 6.2 Concurrency,ObservableState Management, SwiftData-Patterns, dem XcodeBuildMCP-Workflow und Testing-Konventionen. Alles, was ich über iOS-Entwicklung gelernt habe. Festgehalten, damit die AI es zwischen Sessions nicht vergisst.
Die Skills waren mein persistenter Speicher. Statt jede Session die Projektarchitektur neu zu erklären, luden sowohl Claude Code als auch Codex die Skills und starteten mit vollem Kontext. Das war entscheidend für Konsistenz: dieselben Naming-Conventions, dieselben Error-Handling-Patterns, dieselbe Architektur über 117 Dateien hinweg.
Immer wenn ich ein neues Swift-Pattern verstanden habe, kam es in ios-swift-dev. Die AI hat in späteren Sessions weniger Fehler wiederholt. Jede neue Session startete schlauer als die vorherige.
Die Timeline
Los ging es am 11. Januar 2026. Drei Wochen Entwicklung: Architektur, SwiftData-Modelle, MVVM-Struktur, die komplette UI in SwiftUI, Benachrichtigungen, Onboarding, Lokalisierung, Widgets. Alles parallel dazu, Swift von Grund auf zu lernen und meine Claude Code Skills so weit zu bringen, dass der generierte Code auch tatsächlich kompilierte.
Anfang Februar war die App feature-complete. Den Rest des Monats habe ich mit ausgiebigem Testen verbracht (Unit Tests mit Swift Testing, End-to-End-Validierung über XcodeBuildMCP) und dem App Store Connect Prozess.
Dieser zweite Teil verdient einen eigenen Abschnitt.
Der App Store Connect Spießrutenlauf
Das hat das Projekt fast entgleist.
Die App zu bauen war der kreative Teil. Sie in den App Store zu bekommen war etwas völlig anderes: Code Signing, Provisioning Profiles, Export-Optionen, Screenshot-Specs pro Gerätegröße, IAP-Konfiguration, Datenschutzerklärungen, Altersfreigaben. Nichts davon ist Programmieren. Das ist Bürokratie mit Build-System.
ASC CLI hat mich hier gerettet. Statt jede Operation manuell in Apples Weboberfläche durchzuklicken, konnte ich Apps auflisten, In-App-Käufe konfigurieren und Screenshots hochladen, alles direkt aus dem Terminal. Dazu habe ich Upload-Skripte geschrieben, die beide Lokalisierungen (EN und DE) abdecken. Und dann endlich: Einreichung am 19. Februar.
Tools, die das möglich gemacht haben
| Tool | Rolle | Link |
|---|---|---|
| Claude Code | Spezifikation und iOS-Design | claude.com/product/claude-code |
| Claude Code Agent Teams | Multi-Agent Spec-Review | code.claude.com/docs/en/agent-teams |
| Claude Code Skills | Persistentes iOS-Wissen (geteilt von beiden) | code.claude.com/docs/en/skills |
| Codex CLI | Implementierung und Tests | github.com/openai/codex |
| XcodeBuildMCP | Build, Run, Test, Screenshot via MCP | github.com/getsentry/XcodeBuildMCP |
| ASC CLI | App Store Connect Automatisierung | asccli.sh |
Drei Lektionen für iOS-Erstentwickler
1. Schreib Skills, nicht nur Code.
Der größte Hebel war kein einzelnes Tool. Es war, das Gelernte in Claude Code Skills festzuhalten. Wenn du AI für iOS-Entwicklung nutzt, investiere früh in deine Skills-Dateien. Sie akkumulieren.
2. Schneide es so, dass du auch wirklich shippen kannst.
Jedes Feature, das du in v1 packst, kann deinen Launch blockieren. CloudKit-Sync, serverseitige Receipt-Validierung, Multi-Device-Handoff, Echtzeit-Kollaboration: jedes davon sind Wochen Arbeit und eine neue Kategorie von Bugs. Für meine erste App habe ich das alles gestrichen. Alles läuft auf einem Gerät, lokal persistiert. Allein diese Entscheidung hat mir vermutlich einen Monat gespart. Erst shippen. Der App Store belohnt keine Ambition, sondern Apps die existieren.
3. Plane echte Zeit für App Store Connect ein.
Ich habe ASC unterschätzt. Code Signing, Screenshots, IAP-Konfiguration, Datenschutzerklärungen. Das kostet eine volle Woche, selbst mit CLI-Automatisierung. Nicht als Halbtagesaufgabe einplanen. Richtig Zeit dafür blocken.
Fazit
Ich habe eine native SwiftUI-App in den App Store gebracht, ohne je eine geschrieben zu haben. Ohne die AI-Toolchain hätte ich das nicht in einem Monat geschafft. Aber der eigentliche Multiplikator waren die eigenen Skills, die festgehalten haben, was ich unterwegs lernte. Die Tools haben die Syntax übernommen. Die Skills die Konsistenz.
Nami im App Store ansehen oder mehr über das Projekt auf der Nami Projektseite erfahren.
Quellen
