iOS 27 Startbildschirm prüfen: App-Store-Checkliste 2026

Risiko: Fehlt bei einem Build mit dem iOS-27.0-SDK eine anerkannte Startbildschirm-Konfiguration, kann Apple die App bei der Annahme zurückweisen.
Schnellste Abnahme: Prüfen Sie die iOS-27-Startbildschirm-Anforderungen anhand des tatsächlich eingereichten App-Produkts, kontrollieren Sie das Archive und testen Sie anschließend den sichtbaren Startbildschirm.

Das gilt für iOS- und iPadOS-Apps, die mit dem iOS-27.0-SDK oder einem neueren SDK gebaut werden. Es bedeutet nicht, dass jede App, die noch mit einem älteren SDK erstellt wurde, sofort neu gebaut werden muss. Apple beschreibt die SDK-Bedingung und den Ablehnungsfall in den iOS- und iPadOS-27-Release-Notes.

Für wen:
Sie wechseln ein bestehendes App-Projekt auf das iOS-27-SDK und wollen die Startbildschirm-Konfiguration vor der Einreichung belegen.
Sie pflegen Storyboard-, SwiftUI- oder programmatisch aufgebaute Oberflächen und müssen klären, welches Target die Konfiguration liefert.
Sie bauen auf einem Remote Mac oder in einer CI-Umgebung und möchten prüfen, ob die Einstellung tatsächlich im ausgelieferten Archive angekommen ist.

Zuletzt geprüft am 20.10.2026. Die Anforderung und die genannten Konfigurationsschlüssel wurden anhand der Apple-Release-Notes, der Technischen Notiz TN3208 und der Xcode-Dokumentation abgeglichen. Ein konkretes Startdatum der Annahmebedingung wird hier nicht ergänzt.

Die SDK-Grenze bei der iOS-27-Startbildschirm-Anforderung

Entscheidend ist, mit welchem SDK die App gebaut wird. Drei Angaben, die in Projekten oft nebeneinander auftauchen, beantworten verschiedene Fragen:

• SDK: Welche Plattform-Schnittstellen und Build-Anforderungen für die Kompilierung verwendet werden. Die von Apple bestätigte Vorgabe richtet sich an Apps, die mit dem iOS-27.0-SDK oder einem neueren SDK gebaut werden.
• Mindestbereitstellungsversion: Welche ältere iOS-Version das Projekt als unterstütztes Ziel festlegt. Sie beantwortet nicht, welches SDK den aktuellen Build erstellt hat.
• Betriebssystem des Testgeräts: Welche Version auf einem konkreten Simulator oder Gerät läuft. Auch sie ersetzt nicht die Prüfung des SDK-Stands im Build.

Das bedeutet: Eine App kann weiterhin eine ältere Mindestversion unterstützen und trotzdem mit dem iOS-27-SDK erstellt werden. Ist das der Fall, dürfen Sie die Mindestversion nicht als Begründung verwenden, die Startbildschirm-Anforderung zu übergehen. Umgekehrt folgt aus Apples Vorgabe nicht, dass alle bestehenden Builds mit älterem SDK automatisch ungültig sind. Für die konkrete Ablehnungsbedingung und den Beginn der Annahme von Builds sollten Sie die aktuellen iOS- und iPadOS-27-Release-Notes heranziehen. Tragen Sie kein konkretes Wirksamkeitsdatum in Ihren Release-Plan ein, solange Apple es nicht bestätigt hat.

Notieren Sie vor der Abnahme den tatsächlich verwendeten Xcode-Stand, das ausgewählte SDK und die Build-Konfiguration. Prüfen Sie den Status und die Versionshinweise auf der Seite Apple Developer Releases sowie in den Xcode-Release-Notes. So vermeiden Sie, eine Projektangabe aus der Entwicklungsumgebung mit dem Werkzeugstand des eingereichten Builds gleichzusetzen. Gerade bei einem Wechsel der Entwicklungsumgebung kann ein Entwickler lokal ein anderes Xcode verwenden als der CI- oder Remote-Build, der das App-Store-Archive erstellt.

Konfigurationsdeklaration in Info.plist

Apple nennt mehrere mögliche Schlüssel für die Launch-Screen-Konfiguration. Die Technische Notiz TN3208 und die Xcode-Dokumentation zur Festlegung des Startbildschirms führen UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen und UILaunchScreens auf. Maßgeblich ist nicht, dass alle Schlüssel gleichzeitig gesetzt sind: Es muss eine passende, von Apple anerkannte Konfiguration vorhanden sein.

Welche Variante sinnvoll ist, hängt davon ab, wie Ihr Projekt den Startbildschirm definiert. Ein Projekt kann auf ein Launch-Storyboard verweisen; ein anderes verwendet eine Konfiguration, die direkt in der Property List beschrieben ist. Die Xcode-Dokumentation erläutert die verfügbaren Konfigurationswege. Ändern Sie nicht vorsorglich mehrere Schlüssel, nur um eine Prüfung optisch „vollständiger“ erscheinen zu lassen. Eine unnötige Änderung kann die bestehende Startansicht beeinflussen und schafft keinen zusätzlichen Nachweis, wenn der Build ohnehin den passenden Schlüssel enthält.

Der häufige Prüfungsfehler liegt an einer anderen Stelle: Entwickler sehen im Repository eine plist-Datei mit dem erwarteten Eintrag und schließen daraus, das eingereichte Produkt sei abgedeckt. Xcode kann Einstellungen jedoch aus verschiedenen Projekt- und Build-Konfigurationsquellen beziehen. Die Apple-Dokumentation zur Verwaltung der App-Informationen in der Property List beschreibt, dass die Informationen für die App im Build-Produkt zu prüfen sind. Daher gilt: Der Quelldatei-Eintrag ist ein Hinweis, aber kein abschließender Abnahmenachweis.

Wenn die Projektstruktur mehrere Property-List-Dateien enthält, ordnen Sie jede Datei zunächst dem zugehörigen Target und der Build-Konfiguration zu. Prüfen Sie außerdem, ob die Werte direkt in einer plist-Datei stehen oder durch Build-Einstellungen erzeugt beziehungsweise überschrieben werden. Eine Datei im Repository kann korrekt aussehen, während der Release-Build eine andere Datei verwendet. Der Entscheidungsmaßstab bleibt der Inhalt der App im Archive, nicht der Dateiname oder der Ort, an dem Sie zuerst nach dem Schlüssel gesucht haben.

Target-Abdeckung im Projekt

Prüfen Sie nicht bloß, ob im Projekt irgendwo eine passende Einstellung auftaucht. Entscheidend ist, ob sie für die iOS- oder iPadOS-App gilt, die Sie tatsächlich einreichen. Bei mehreren Targets oder Build-Konfigurationen kann ein Eintrag nur für einen Teil des Projekts wirksam sein. Ein Test-Target oder eine Erweiterung belegt nicht automatisch die Konfiguration des Hauptprodukts.

Gehen Sie Ihre Projektstruktur anhand der späteren Einreichung durch. Ermitteln Sie, welches Target das App-Bundle erzeugt, welche Build-Konfiguration für den Archive-Auftrag verwendet wird und ob die Konfiguration in Entwicklungs- und Release-Builds voneinander abweicht. Wenn mehrere eigenständige iOS- oder iPadOS-Apps eingereicht werden, behandeln Sie jedes App-Produkt als separate Prüfeinheit. Apples Hinweise zur Property List und zur Verteilung von Apps für Beta-Tests und Releases helfen dabei, Projektkonfiguration und auszulieferndes Produkt auseinanderzuhalten.

Diese Gegenüberstellung trennt die Fragen „Ist die Konfiguration vorhanden?“, „Wurde das richtige Produkt geprüft?“ und „Sieht der Startbildschirm beim tatsächlichen Start korrekt aus?“. Nur die Kombination aus passendem Target, Archive-Nachweis und Starttest deckt diese unterschiedlichen Fehlerquellen ab. Bei einem Projekt mit mehreren App-Targets sollten Sie den Nachweis nicht von einem Target auf ein anderes übertragen, selbst wenn beide dieselbe Codebasis verwenden.

Archive-Prüfung des fertigen Produkts

Prüfen Sie das Archive, das für die Einreichung vorgesehen ist, nicht ein älteres Ergebnis aus einem früheren Lauf. Öffnen Sie das .xcarchive in Xcode oder im Finder und navigieren Sie zum App-Produkt unter Products/Applications. Im App-Bundle liegt die zu prüfende Info.plist. Apples Anleitung zur Verteilung und Archivierung einer App beschreibt den Zusammenhang zwischen Archive und Distributionsprozess.

Sie können den Pfad zur Property List im Terminal ermitteln und ihren Inhalt mit plutil anzeigen lassen. Ersetzen Sie den Platzhalter durch den Pfad Ihres eigenen Archives:

find "/Pfad/zum/Archiv.xcarchive/Products/Applications" -maxdepth 4 -name Info.plist -print
plutil -p "/Pfad/zum/App.app/Info.plist"

Der zweite Befehl muss auf die Info.plist im App-Bundle des geprüften Archives zeigen, nicht auf eine Datei im Projektordner. Kontrollieren Sie, ob mindestens einer der von Apple genannten Schlüssel für den Startbildschirm im App-Produkt vorkommt. Falls Sie ein exportiertes Produkt statt des Archives einreichen, prüfen Sie auch dieses exportierte App-Bundle. Der Prüfpfad sollte sich auf das Artefakt beziehen, das in Ihrem Release tatsächlich weitergegeben wird.

Halten Sie neben dem Ergebnis fest, welcher Xcode- und SDK-Stand verwendet wurde, welches App-Target archiviert wurde und welche Build-Konfiguration aktiv war. Für eine wiederholbare Prüfung können Sie einen kurzen Nachweis zum Archive-Pfad, zum gefundenen Schlüssel und zum Build-Lauf aufbewahren. Ein Screenshot der Projekteinstellungen allein ist schwächer: Er dokumentiert nicht, dass die Einstellung in genau diesem App-Bundle enthalten ist. Ein knapper Prüfvermerk kann beispielsweise den Namen des Build-Laufs, den Pfad des Archives, den gefundenen Schlüssel und das Ergebnis des Starttests aufführen.

Ein zweiter typischer Fehler entsteht, wenn ein Archive erfolgreich geprüft wurde, danach aber noch eine Änderung an der plist-Datei oder Build-Konfiguration erfolgt. Der vorhandene Nachweis bleibt dann für das ältere Artefakt gültig, nicht für den neuen Quellstand. Erstellen Sie nach der Änderung ein neues Archive und wiederholen Sie die Kontrolle. Wenn der Build abbricht oder die Property List im fertigen Paket keinen anerkannten Eintrag enthält, behandeln Sie das nicht als bloßen Dokumentationsfehler: Korrigieren Sie die Konfiguration vor dem nächsten Einreichungsversuch.

Startverhalten auf Simulator oder Gerät

Eine vorhandene Deklaration ist notwendig, aber kein Beleg dafür, dass der Startbildschirm visuell abgenommen ist. Starten Sie die App aus dem geprüften Build und beobachten Sie den Übergang vom System-Startbildschirm zur ersten App-Ansicht. Apple erläutert Zweck und Gestaltung des Startbildschirms in den Human Interface Guidelines zum Starten von Apps. Für die Fehlersuche bei unerwartetem Verhalten ist außerdem die Technische Notiz TN3118 relevant.

Prüfen Sie insbesondere, ob Farben, Logo, Text und grundlegende Anordnung zum unmittelbar folgenden Einstieg passen, ob Inhalte abgeschnitten werden und ob sich der Startbildschirm bei den vorgesehenen Geräte- und Orientierungsszenarien anders verhält als erwartet. Diese Kontrolle ist eine Produkt- und Layoutprüfung, keine zusätzliche Behauptung über eine bestimmte technische Pflicht. Wählen Sie einen Simulator oder ein verfügbares Gerät, das zum geplanten Testumfang passt, und halten Sie fest, auf welcher Umgebung Sie die Beobachtung gemacht haben.

Wenn sich die App-Oberfläche seit dem letzten Archive geändert hat, testen Sie nicht bloß eine bereits installierte ältere Fassung. Bauen Sie erneut, erstellen Sie ein frisches Archive und starten Sie die daraus stammende App. So verhindern Sie, dass ein visueller Test und ein Plist-Nachweis aus unterschiedlichen Build-Ständen zusammengeführt werden. Auch wenn die Plist-Prüfung erfolgreich ist, sollten Sie die Startansicht nicht als erledigt markieren, bevor Sie das tatsächliche Verhalten geprüft haben: Ein vorhandener Schlüssel belegt die Deklaration, aber weder das Layout noch den Anschluss an die erste interaktive Ansicht.

FAQ zur Abnahme

Muss ein mit dem iOS-27-SDK gebautes App-Projekt einen Startbildschirm enthalten?

Ja. Apple verlangt für iOS- und iPadOS-Apps, die mit dem iOS-27.0-SDK oder einem neueren SDK gebaut werden, eine anerkannte Startbildschirm-Konfiguration. Die Vorgabe bezieht sich auf den SDK-Stand des Builds, nicht pauschal auf alle älteren, bereits erstellten Apps. Prüfen Sie vor der Einreichung die aktuelle Formulierung der Release-Anforderung und ändern Sie nicht allein wegen einer älteren Mindestbereitstellungsversion Ihr gesamtes Deployment-Ziel.

Welche Schlüssel in Info.plist kann ich verwenden?

Apple führt UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen und UILaunchScreens als mögliche Schlüssel auf. Welche Konfiguration zu Ihrem Projekt passt, hängt davon ab, wie der Startbildschirm eingerichtet ist. Sie müssen nicht alle Varianten zugleich setzen. Entscheidend ist, dass die passende Einstellung für das eingereichte App-Target wirksam ist und anschließend im App-Bundle des Archives nachgewiesen wird.

Wie prüfe ich die Einstellung im Archive?

Suchen Sie unter Products/Applications im tatsächlich erstellten .xcarchive das App-Bundle und lesen Sie dessen Info.plist aus. Mit plutil -p lässt sich der Inhalt im Terminal anzeigen. Vergleichen Sie das Ergebnis mit einem anerkannten Schlüssel und dokumentieren Sie Xcode, SDK sowie Build-Konfiguration. Nach einer Korrektur benötigen Sie ein neu erzeugtes Archive; die Prüfung einer älteren Datei ist kein Nachweis für den aktualisierten Build.

Muss ich zusätzlich im Simulator testen?

Ja, wenn Sie auch das sichtbare Ergebnis abnehmen wollen. Die Plist-Prüfung zeigt, dass eine Konfiguration im gebauten Produkt vorhanden ist, aber nicht, ob Inhalt und Layout beim Start passen. Starten Sie die App aus dem geprüften Build kalt und kontrollieren Sie den Übergang zur ersten Ansicht. Bei Auffälligkeiten grenzen Sie zunächst ein, ob die Abweichung bereits im Archive angelegt ist oder erst beim tatsächlichen Start sichtbar wird.

Veröffentlichungsnachweis vor dem Upload

Machen Sie die Prüfung zu einem nachvollziehbaren Bestandteil Ihrer App-Store-Abnahme. Die folgenden Punkte lassen sich für jedes einzureichende App-Produkt abhaken:

• [ ] Der Build verwendet das dokumentierte Xcode- und SDK-Paar; die SDK-Angabe wurde nicht mit der Mindestbereitstellungsversion verwechselt.
• [ ] Das tatsächlich archivierte Haupt-App-Target ist identifiziert; Test-Targets und Erweiterungen wurden nicht als Ersatz für das Hauptprodukt behandelt.
• [ ] Im App-Bundle des aktuellen Archives steht mindestens einer der von Apple anerkannten Startbildschirm-Schlüssel.
• [ ] Eine abweichende Build-Konfiguration oder ein anderes einzureichendes App-Produkt wurde separat geprüft.
• [ ] Der Startbildschirm wurde aus dem geprüften Build auf einem passenden Simulator oder Gerät angesehen.
• [ ] Nach jeder Änderung wurde ein neues Archive erstellt; Nachweise aus einem älteren Build wurden nicht übernommen.
• [ ] Die Release-Notes wurden vor der Einreichung erneut auf eine aktualisierte Annahmebedingung geprüft; ein nicht bestätigtes Wirksamkeitsdatum wurde nicht in den Plan geschrieben.

Schlägt ein Prüfschritt fehl, halten Sie die Einreichung dieses Builds an. Korrigieren Sie die Konfiguration im passenden Target oder in der zuständigen Build-Einstellung, erstellen Sie ein neues Archive und wiederholen Sie sowohl die Plist- als auch die Startprüfung. Eine Änderung im Quellprojekt ohne anschließenden Neubau reicht nicht aus, weil sie noch nichts über das einzureichende Produkt aussagt. Bewahren Sie die Ergebnisse so auf, dass ein weiteres Teammitglied nachvollziehen kann, welches Artefakt geprüft wurde und ob die Freigabe auf demselben Build-Stand beruht.

Wenn Xcode beim lokalen Build nicht verfügbar ist oder Ihr Entwicklungs-Mac durch Archive und Simulatoren stark belegt wird, vergleichen Sie zunächst den vorhandenen Ablauf mit einem Remote-Mac-Build. Ein lokaler Mac bietet direkte Geräteanschlüsse und vermeidet die Abhängigkeit von einer Netzwerkverbindung; für einen einzelnen Entwickler kann der Kauf eines eigenen Rechners außerdem sinnvoll sein, wenn die Auslastung dauerhaft und vorhersehbar hoch ist. Eine gemietete Mac-Umgebung ist eher dann eine Prüfung wert, wenn Sie zeitweise einen reproduzierbaren Build benötigen, ohne ein zusätzliches Gerät dauerhaft anzuschaffen. Berücksichtigen Sie dabei Netzwerkzugriff, Zugangsschutz und die sichere Aufbewahrung von Signiermaterial. Ein Remote-Aufbau passt weniger gut, wenn Sie für Ihre Tests zwingend lokale Schnittstellen benötigen oder die Build-Last dauerhaft hoch und gleichmäßig anfällt.

Einen Überblick zu Einsatzmöglichkeiten für Mac-Umgebungen können Sie mit Ihren Anforderungen abgleichen; die Mietkonditionen von KVMFLUX sollten Sie vor einer Entscheidung auf Laufzeit und benötigte Zugangsart prüfen. Für die Veröffentlichung bleibt unabhängig vom Build-Ort dieselbe Regel bestehen: Freigeben sollten Sie nur das neu erstellte und nachvollziehbar geprüfte Archive.