Vom SwiftUI-Konzept zum App Store in wenigen Wochen
Es gibt eine typische Verzögerung bei iOS-Projekten: Eine Funktion sollte „in wenigen Wochen“ erscheinen, befindet sich aber drei Monate später noch in Entwicklung, weil ihr Umfang ständig gewachsen ist und die Einreichung mehr Schritte erfordert als erwartet. Eine SwiftUI-App schnell zu veröffentlichen, ist tatsächlich weniger eine Frage des Entwicklungstempos. Entscheidend ist, früh festzulegen, was die App nicht leisten soll, und an dieser Entscheidung festzuhalten, wenn die Versuchung aufkommt, noch eine weitere Funktion hinzuzufügen.
Wir haben mehrere SwiftUI-Apps in kurzer Zeit veröffentlicht. Der Prozess lässt sich wiederholen, erfordert aber Disziplin beim Funktionsumfang, ein klares Verständnis des Einreichungsprozesses bei Apple und die Bereitschaft, etwas Gutes zu veröffentlichen, das noch nicht vollständig ausgebaut ist. So sieht das in der Praxis aus.
Den Funktionsumfang vor dem ersten Commit festlegen
Die wichtigste Arbeit für eine schnelle iOS-Veröffentlichung findet statt, bevor Code geschrieben wird. Die Frage lautet nicht „Was soll diese App können?“, sondern „Welches einzelne Problem löst diese App für den Nutzer in Version eins?“. Jede Funktion, die nicht unmittelbar mit diesem Problem zusammenhängt, gehört in Version zwei.
Das ist schwieriger, als es klingt, denn bei der Konzeption von Grund auf erscheint fast alles relevant. Benachrichtigungen wirken wichtig. Soziale Funktionen wirken wichtig. Detaillierte Analyse-Dashboards wirken wichtig. Tatsächlich können Nutzer diese Funktionen aber erst bewerten, nachdem sie die Kernfunktion der App genutzt und als nützlich erlebt haben. Eine App, die eine Sache gut macht und nach vier Wochen erscheint, liefert hilfreicheres Feedback als eine App, die sechs Dinge einigermaßen gut macht und nach vier Monaten erscheint.
Ein praktisches Hilfsmittel ist eine Liste mit zwei Spalten, die Sie vor Entwicklungsbeginn erstellen: Was gehört in das MVP, und was wird ausdrücklich verschoben? Die Liste der verschobenen Funktionen ist kein Backlog, sondern zwingt zu klaren Entscheidungen. Jede Funktion, die während der Entwicklung hinzukommt, sollte darauf geprüft werden, ob sie auf diese Liste statt in den aktuellen Sprint gehört. Bei den meisten ist das der Fall.
Die ersten zwei Wochen: nur die wichtigsten Ansichten
Eine SwiftUI-App mit einem klaren Einzelzweck benötigt gewöhnlich drei bis fünf Bildschirmansichten: einen Einführungsablauf, eine oder zwei Ansichten für die Hauptinteraktionen sowie eine Einstellungs- oder Kontoansicht. In den ersten zwei Wochen sollten diese funktional vollständig sein: Sie erfüllen ihre Aufgabe mit echten Daten in der richtigen Reihenfolge. Sie müssen noch nicht gestalterisch ausgearbeitet sein. Für Animationen können Systemvorgaben gelten, für die Typografie die Systemschriften und für Fehlerzustände einfache Textmeldungen.
In dieser Phase sind vor allem Architekturentscheidungen wichtig, die sich später schwer ändern lassen: das Navigationsmodell (NavigationStack, TabView oder ein eigener Coordinator), die Zustandsverwaltung (@Observable aus dem Observation-Framework oder weiterhin ObservableObject) und die Strategie zur dauerhaften Datenspeicherung (SwiftData, Core Data oder UserDefaults für einfachen Zustand). Treffen Sie diese Entscheidungen ausdrücklich und früh, statt sie beiläufig entstehen zu lassen. So vermeiden Sie, dass in Woche drei die eine Hälfte der App ein Navigationsmodell verwendet und die andere ein anderes.
Bei Apps mit einem Supabase-Backend verdient der Authentifizierungsablauf in dieser Phase besondere Aufmerksamkeit. Apples App-Review-Richtlinien behandeln dies als zwei getrennte Anforderungen: Apps, die das Erstellen von Konten unterstützen, müssen Nutzern ermöglichen, ihr Konto innerhalb der App zu löschen (Richtlinie 5.1.1(v)). Apps, die für das primäre Konto eine Anmeldung über Drittanbieter oder soziale Netzwerke wie Google Sign-In verwenden, müssen außerdem eine gleichwertige, datenschutzorientierte Anmeldeoption anbieten, in der Praxis meist Sign in with Apple (Richtlinie 4.8). Wenn Ihre App ausschließlich eine eigene E-Mail-/Passwort-Authentifizierung über Supabase verwendet, ist Sign in with Apple nicht erforderlich. Der Ablauf zur Kontolöschung muss jedoch im MVP enthalten sein – nicht, weil Nutzer ihn am ersten Tag verwenden werden, sondern weil App Review die App andernfalls ablehnt. Wenn Sie eine Anmeldung über soziale Netzwerke hinzufügen, planen Sie die gleichwertige Anmeldeoption gleichzeitig ein.
Wochen drei und vier: Feinschliff und TestFlight
In der dritten Woche beginnt die App, wie ein fertiges Produkt auszusehen. Jetzt kümmern Sie sich um Ladezustände – nicht nur „einen Ladeindikator anzeigen“, sondern „einen Ladeindikator anzeigen, der die Wartezeit angemessen vermittelt“ –, leere Ansichten ohne Daten und Fehlerzustände bei fehlgeschlagenen Netzwerkanfragen. Das ist keine bloße gestalterische Verfeinerung: Es prägt das Erlebnis neuer Nutzer, die zunächst keine Daten haben und gelegentlich Netzwerkprobleme erleben.
Die Verteilung über TestFlight sollte in Woche drei beginnen, nicht erst in Woche vier. Beim ersten hochgeladenen Build treten meist unerwartete Build-Probleme auf. App Store Connect validiert die Binärdatei vor der Freigabe zum Testen und erkennt Probleme, die Xcodes lokaler Build nicht sichtbar macht: fehlende Entitlements, falsche Kombinationen von Provisioning-Profilen oder erforderliche, aber fehlende Info.plist-Schlüssel. Treten diese Probleme in Woche drei auf, bleibt Zeit für die Behebung vor der eigentlichen Einreichung. Am Abend vor dem geplanten Start bleibt diese Zeit nicht.
TestFlight-Feedback hilft in dieser Phase vor allem, unklare Navigation und fehlende erkennbare Bedienmöglichkeiten zu finden, weniger beim Sammeln von Funktionswünschen. Fragen Sie Tester: „Gab es etwas, das Sie tun wollten, bei dem Sie aber nicht herausgefunden haben, wie es geht?“, statt „Welche Funktionen wünschen Sie sich?“. Die zweite Frage liefert eine Liste, die den Zeitplan um Monate verlängern würde.
Der Einreichungsprozess im App Store
Die Einreichung im App Store umfasst mehr Schritte, als erstmalige Einreicher erwarten, und jeder davon kann die Veröffentlichung blockieren. Wenn Sie sie frühzeitig durcharbeiten, statt erst nach Abschluss der Programmierung damit zu beginnen, vermeiden Sie Hektik in der letzten Woche.
Screenshots sind vor der Einreichung erforderlich und müssen einer der akzeptierten Pixelabmessungen für die jeweilige Displaygröße entsprechen. Stand Oktober 2026 verlangt App Store Connect iPhone-Screenshots für die Displayklasse mit 6,9 Zoll (zum Beispiel iPhone 16 Pro Max) oder für die Klasse mit 6,5 Zoll (zum Beispiel iPhone 14 Plus), falls keine Screenshots mit 6,9 Zoll bereitgestellt werden, sowie iPad-Screenshots mit 13 Zoll (zum Beispiel iPad Pro (M4) oder iPad Pro mit 12,9 Zoll (6. Generation)), wenn die App auf dem iPad läuft. Sie im Simulator zu erstellen, ist unkompliziert, kostet aber Zeit, wenn Sie bis zum letzten Tag warten. Eine einfache Fastlane-snapshot-Konfiguration kann dies automatisieren.
Im Abschnitt App Privacy in App Store Connect müssen Sie jede Art erhobener Daten, deren Verwendungszweck und eine mögliche Verknüpfung mit der Identität des Nutzers angeben. Dies sind keine optionalen Metadaten: Bei unvollständigen Angaben scheitert die Einreichung. Wenn Ihre App Supabase mit Authentifizierung nutzt, erheben Sie mindestens E-Mail-Adressen und Nutzerkennungen; beides muss angegeben werden. SDKs von Drittanbietern und Analysewerkzeuge erweitern diese Liste. Wenn Sie die Datenerhebung vor der Einreichung korrekt erfassen, vermeiden Sie spätere Aktualisierungen dieser Angaben nach dem Start.
Apple gibt an, gewöhnlich 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden zu prüfen. Eine beschleunigte Prüfung kann bei besonderen Umständen beantragt werden, etwa bei einer kritischen Fehlerbehebung oder einer an ein Ereignis gebundenen Veröffentlichung. Ein Mensch prüft die App anhand der Apple-Richtlinien. Die häufigsten Ablehnungsgründe bei der ersten Einreichung sind fehlende Kontofunktionen (Kontolöschung innerhalb der App oder eine gleichwertige Anmeldeoption zusätzlich zur Anmeldung über soziale Netzwerke), fehlende Zugangsdaten für ein Demokonto bei Apps mit Anmeldung und Abstürze in Randfällen, die Tester nicht entdeckt haben, die Prüfer aber schon.
Was Sie weglassen können und wie
Der schwierigste Teil eines schnellen Veröffentlichungszyklus ist, Kürzungen bewusst statt überhastet wirken zu lassen. Nutzer erkennen den Unterschied zwischen einer absichtlich einfachen und einer unfertigen App. Entscheidend ist vor allem die Vollständigkeit der vorhandenen Ansichten – jede bestehende Ansicht sollte vollständig sein –, weniger deren Anzahl.
Praktische Kürzungen, die einer ersten Veröffentlichung selten schaden: Push-Benachrichtigungen (aufwendig korrekt einzurichten; Nutzer müssen der App vertrauen, bevor Benachrichtigungen willkommen sind), soziale Funktionen (Folgen, Teilen, Bestenlisten – bei größerer Nutzerzahl hilfreich, beim Start ablenkend), umfangreiche Anpassungseinstellungen (die meisten Nutzer ändern die Vorgaben nie) und alle Funktionen, die erhebliche Backend-Infrastruktur erfordern, die das MVP ansonsten nicht benötigt.
Kürzungen, die einer ersten Veröffentlichung schaden: Fehlerbehandlung (ein Absturz bei einem Netzwerk-Timeout verärgert Nutzer nachhaltig), Ladezustände (eine App, die ohne sichtbare Rückmeldung stehen bleibt, wirkt defekt) und grundlegende Kontoverwaltung (Nutzer müssen auch im MVP ihr Passwort zurücksetzen und ihr Konto löschen können).
Nach dem Start: Die ersten zwei Wochen sind am wichtigsten
In den ersten zwei Wochen nach dem Start sind App-Store-Bewertungen besonders empfindlich. Mehrere frühe Ein-Stern-Bewertungen wegen eines im Test nicht aufgetretenen Absturzes schaden der langfristigen Bewertung überproportional. Prüfen Sie Instruments und Xcodes Crash Organizer in der ersten Woche täglich. Reichen Sie nach dem Erkennen kritischer Abstürze innerhalb von 24 Stunden eine Hotfix-Version ein; App Review bietet für Absturzkorrekturen eine beschleunigte Prüfung an.
Widerstehen Sie mindestens zwei Wochen lang dem Impuls, die verschobenen Funktionen unmittelbar nach dem Start zu veröffentlichen. Zu verstehen, wie Nutzer die Kernfunktionen tatsächlich bedienen, ist wertvoller, als bloß Fortschritt zu demonstrieren. Nach zwei Wochen Beobachtung realer Nutzungsmuster lassen sich die vorgesehenen Funktionen für Version zwei besser gestalten, als wenn sie parallel zum Start entwickelt worden wären.
Weiterführende Beiträge
- App-Store-Ablehnungen wegen des App-Icons beheben – Die Anforderungen an sRGB, Alphakanal und TrueColor, die eine Einreichung im letzten Schritt blockieren können.
- Eine App zur Prüfungsvorbereitung mit Tausenden von Fragen entwickeln – Wie die Architektur aussieht, wenn aus dem MVP schließlich ein Produkt mit umfassendem Funktionsumfang werden soll.
- Swift 6 Concurrency: Ein praktischer Migrationsleitfaden – Wann Sie Swift-6-Concurrency-Warnungen in einem schnellen Veröffentlichungszyklus beheben und wann Sie dies verschieben sollten.