Eine native iOS-App mit SwiftUI wirkt flüssig, nutzt alle Systemfunktionen und hat im Review selten Probleme mit Minimum Functionality. Mit Claude Code lässt sich auch dieser Weg deutlich beschleunigen, obwohl Apple-Entwicklung traditionell stark an Xcode gebunden ist. Der Agent arbeitet im Terminal, Xcode bleibt Ihr Werkzeug für Vorschau, Signierung und Upload. Wie diese Arbeitsteilung gelingt und was Sie vor der Einreichung prüfen sollten, lesen Sie hier.
Arbeitsteilung zwischen Agent und Xcode
Claude Code bearbeitet Swift-Dateien, führt Befehle aus und liest Build-Ausgaben, sieht aber nicht Ihre Xcode-Oberfläche. Das ist kein Nachteil, wenn Sie den Build über xcodebuild oder über ein Swift Package im Terminal ansteuern. Hinterlegen Sie in der CLAUDE.md den exakten Build- und Testbefehl inklusive Scheme und Simulator-Ziel. Dann kann der Agent nach jeder Änderung selbst kompilieren und Fehler beheben.
Ein bewährtes Muster ist, Geschäftslogik in lokale Swift Packages auszulagern. Diese lassen sich schnell und ohne Simulator testen, und Claude Code bekommt kurze Feedback-Schleifen. Die eigentliche App-Hülle mit Assets, Entitlements und Info.plist bleibt schlank.
SwiftUI-Code, der auch in einem Jahr noch wartbar ist
KI-Agenten neigen dazu, Views mit Logik zu überfrachten oder veraltete Muster zu mischen. Legen Sie in der CLAUDE.md fest, welche Architektur gilt, etwa Observation-basierte Modelle, und welche Mindest-iOS-Version unterstützt wird. Ein Subagent für Code-Review kann jede Änderung gegen diese Regeln prüfen, bevor Sie sie übernehmen.
Fordern Sie außerdem konsequent Barrierefreiheit ein: Accessibility-Labels, Dynamic Type und ausreichende Kontraste. Das kostet beim Schreiben kaum Zeit, ist im Nachhinein aber mühsam. Für Lokalisierung empfiehlt sich von Anfang an ein String Catalog, damit keine fest verdrahteten Texte im Code landen.
Vor der Einreichung: die Checkliste
Die technischen Hürden liegen bei nativen Apps weniger im Code als in der Konfiguration. Gehen Sie diese Punkte vor dem ersten Upload durch:
- Prüfen Sie Bundle Identifier, Version und Build-Nummer und legen Sie die App in App Store Connect an.
- Ergänzen Sie für jede genutzte Berechtigung einen klaren Usage-Description-Text in der Info.plist.
- Legen Sie ein Privacy Manifest an, das genutzte Required-Reason-APIs und erhobene Daten deklariert.
- Erstellen Sie ein Archiv in Xcode oder per fastlane und laden Sie es zuerst in TestFlight hoch.
- Hinterlegen Sie für das Review einen Demo-Zugang und beschreiben Sie nicht offensichtliche Funktionen in den Review-Notizen.
Tests als Sicherheitsnetz für den Agenten
Je mehr Code Claude Code schreibt, desto wichtiger werden automatisierte Tests. Für Logik in Swift Packages eignen sich Unit-Tests mit XCTest oder dem neueren Swift Testing, die in Sekunden laufen. Für kritische Abläufe wie Registrierung, Login und Kauf lohnen sich zusätzlich UI-Tests, die im Simulator echte Taps ausführen. Lassen Sie den Agenten zu jedem neuen Feature mindestens einen Test schreiben und erst dann die Implementierung, so entsteht automatisch eine wachsende Testbasis.
Ein Hook, der nach jeder Änderung den schnellen Teil der Tests startet, verhindert, dass sich Fehler über mehrere Schritte aufstauen. Die langsameren UI-Tests laufen besser in der CI. Ein praktischer Nebeneffekt: Mit UI-Tests lassen sich auch die Screenshots für App Store Connect reproduzierbar erzeugen, in allen geforderten Gerätegrößen und Sprachen. Das spart bei jedem Update viel Handarbeit.
Signierung, Upload und Review ohne Reibung
Automatische Signierung in Xcode reicht für Einzelentwickler oft aus. Sobald mehrere Personen oder eine CI bauen, sollten Zertifikate zentral verwaltet werden, etwa mit fastlane match. Für den Upload aus der Pipeline brauchen Sie einen App-Store-Connect-API-Schlüssel statt eines persönlichen Passworts. Bietet Ihre App Google- oder Facebook-Login an, verlangt Guideline 4.8 eine gleichwertige datenschutzfreundliche Alternative wie Sign in with Apple.
appsubmitter richtet Signierung, fastlane-Lanes und CI in Ihrem Apple-Konto ein und übernimmt Einreichung sowie Review-Kommunikation. Wenn Sie die App selbst mit Unterstützung erfahrener AI Code Engineers bauen oder Ihr Team in Claude Code schulen möchten, ist neooutput der richtige Partner. Im kostenlosen 15-Minuten-Erstgespräch finden wir heraus, wo Sie gerade stehen.
Häufige Fragen
Kann Claude Code SwiftUI-Previews sehen?
Nein, die Xcode-Vorschau ist für den Agenten nicht sichtbar. Er kann aber Build-Fehler, Testergebnisse und auf Wunsch Screenshots aus Simulator-Läufen auswerten. Die visuelle Abnahme bleibt bei Ihnen.
Brauche ich zwingend einen Mac?
Für native iOS-Entwicklung ja, denn Xcode und das iOS-SDK laufen nur unter macOS. Alternativ können Builds in einer CI mit macOS-Runnern oder in Xcode Cloud entstehen. Claude Code selbst kann auch auf dem Mac im Terminal laufen.
Lohnt sich nativ gegenüber Capacitor oder Expo?
Wenn Sie nur iOS bedienen oder tiefe Systemintegration wie Widgets, Live Activities oder HealthKit brauchen, ist SwiftUI meist die beste Wahl. Für zwei Plattformen mit einer Codebasis sind Expo oder Flutter oft wirtschaftlicher.