Die Launch-Screen-Regel von iOS 27: Vier Schlüssel oder Ablehnung

Apples Release Notes zu iOS 27 machen aus einem Satz in der Dokumentation eine Hürde bei der Einreichung: „iOS- und iPadOS-Apps, die mit dem 27.0-SDK oder neuer gebaut werden, müssen einen Launch Screen enthalten. Die Info.plist Ihrer App muss einen der folgenden Schlüssel enthalten: UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen oder UILaunchScreens. Apps ohne Launch Screen werden abgelehnt, sobald der App Store beginnt, mit dem 27.0-SDK gebaute Apps anzunehmen.”¹

Die Anforderung selbst ist alt. Apples Xcode-Dokumentation beginnt mit dem Satz: „Jede iOS-App muss einen Launch Screen bereitstellen.”² Neu an iOS 27 ist die Konsequenz, wenn man sie ignoriert.

TL;DR

• Apps, die gegen das SDK von iOS 27.0 oder neuer gebaut werden, müssen einen Launch Screen über einen von vier Info.plist-Schlüsseln deklarieren; Builds ohne einen davon lehnt der App Store ab.¹
• Geprüft wird bei der Einreichung, nicht zur Laufzeit. Apple schreibt, Apps würden abgelehnt, „sobald der App Store beginnt, mit dem 27.0-SDK gebaute Apps anzunehmen” – der Fehlschlag landet also in App Store Connect und nicht auf dem Gerät der Nutzer.¹
• Die Regel nennt iOS und iPadOS – und hört dort auf. Auf tvOS, visionOS oder Mac Catalyst dehnt Apple sie in derselben Notiz nicht aus.¹ Die Pflicht zum szenenbasierten Lebenszyklus, die im selben Zyklus kommt, liest sich anders: Der zugehörige Migrationsleitfaden nennt iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 und visionOS 27 namentlich.³
• Zwei Schlüssel decken einen einzelnen Launch Screen ab (UILaunchScreen baut ihn direkt in der Property List, UILaunchStoryboardName benennt eine Storyboard-Datei), zwei weitere decken Varianten je URL-Schema ab (UILaunchScreens, UILaunchStoryboards). Drei der vier sind Dictionaries; allein UILaunchStoryboardName ist ein String.⁴⁵⁶⁷
• Projekte aus aktuellen Xcode-Vorlagen erfüllen die Regel bereits – und zwar über ein Build Setting, nicht über eine Datei.⁸¹¹ Wer sein Repository nach den vier Schlüsseln durchsucht, greift deshalb vollständig ins Leere.

Die Regel, präzise formuliert

Drei Details in Apples Satz sind entscheidend, und die Berichterstattung verwischt meist alle drei.

Erstens ist der Auslöser das SDK, gegen das Sie bauen – nicht das Betriebssystem, das Ihre Nutzer verwenden. Eine gegen iOS 26 kompilierte Binärdatei behält ihren Platz im Store. Bauen Sie jedoch mit Xcode 27 neu, um irgendetwas aus dem neuen SDK mitzunehmen, kommt die Anforderung gleich mit.

Zweitens greift die Durchsetzung bei der Annahme durch den App Store. Apple schreibt „abgelehnt”, womit der Fehlschlag in die Einreichungsprüfung fällt und nicht in den Start der App. Genau darin unterscheidet sich die Launch-Screen-Regel von der Pflicht zum szenenbasierten Lebenszyklus aus demselben Zyklus: Dort formuliert Apple, Apps würden „nicht mehr starten”.¹ Das eine kostet Sie einen abgelehnten Build, das andere eine tote App auf dem Telefon Ihrer Nutzer.

Drittens umfasst der Geltungsbereich iOS und iPadOS. Apples Notiz nennt diese beiden Plattformen und hört dann auf. Wer ein Catalyst- oder tvOS-Target pflegt, sollte die Anforderung als nicht ausgesprochen lesen und nicht als analog erweitert. Der 27er-Zyklus setzt an vielen anderen Stellen Regeln durch – vom szenenbasierten Lebenszyklus über fünf Plattformen hinweg bis zur Entfernung von ImageCreator aus Image Playground –, doch die Notiz zum Launch Screen bleibt eng.

Welcher der vier Schlüssel gilt

Apple bietet zwei Wege, einen Launch Screen zu bauen, und zwei Kardinalitäten – daraus ergeben sich die vier Schlüssel.

UILaunchScreen konfiguriert die Startoberfläche direkt in der Property List, ganz ohne Storyboard-Datei. Apple beschreibt den Schlüssel als Möglichkeit, „die Benutzeroberfläche während des App-Starts zu konfigurieren, ohne auf Storyboards angewiesen zu sein”, und er nimmt untergeordnete Schlüssel für Hintergrundfarbe, Bild sowie die Sichtbarkeit von Navigation Bar, Tab Bar und Toolbar entgegen.⁴ Bei einer App, deren erster Bildschirm nur ein einfarbiger Hintergrund ist, genügt ein leeres UILaunchScreen-Dictionary. Xcodes eigenes Build-System geht genau diesen Weg: Ist GENERATE_INFOPLIST_FILE aktiviert, setzt INFOPLIST_KEY_UILaunchScreen_Generation laut Apple „den Wert des Schlüssels UILaunchScreen in der Info.plist-Datei auf ein leeres Dictionary”.⁸

UILaunchStoryboardName verweist über den Dateinamen auf ein Storyboard, ohne Endung: Aus der Datei LaunchScreen.storyboard wird der String LaunchScreen.⁵ Der Schlüssel stammt aus iOS 9 und ist als einziger der vier ein String statt eines Dictionaries.⁵ Apps mit einem gestalteten Startzustand – und jedes Projekt, das jenes LaunchScreen.storyboard mitliefert, das Xcode seinen Storyboard-Vorlagen bis heute beilegt – brauchen diesen Schlüssel.²

Die Pluralformen gibt es für einen einzigen speziellen Fall, und beide sind Dictionaries, keine Arrays.⁶⁷ UILaunchScreens enthält drei untergeordnete Schlüssel: UILaunchScreenDefinitions, das Array der Launch-Screen-Konfigurationen, von denen jede einen UILaunchScreenIdentifier trägt; UIURLToLaunchScreenAssociations, die Zuordnung von URL-Schema zu Identifier; und UIDefaultLaunchScreen als Rückfallebene.⁶ UILaunchStoryboards spiegelt diesen Aufbau mit UILaunchStoryboardDefinitions, UIURLToLaunchStoryboardAssociations und UIDefaultLaunchStoryboard.⁷ Beide erlauben es, dass eine über myapp://compose geöffnete App einen anderen Startzustand zeigt als dieselbe App, die vom Home-Bildschirm aus gestartet wird. Apple sagt unmissverständlich, dass die meisten Apps darauf verzichten sollten: „Wenn Sie nur einen Launch Screen benötigen, verwenden Sie stattdessen UILaunchScreen.”⁶

Praktisch läuft die Entscheidung auf eine einzige Frage hinaus: Ist Ihr Launch Screen ein Storyboard, deklarieren Sie UILaunchStoryboardName. Ist er es nicht, deklarieren Sie UILaunchScreen. Zu einem Plural-Schlüssel greifen Sie nur, wenn Sie ohnehin schon wissen, wozu Sie ihn brauchen.

Welche Apps es tatsächlich trifft

Eine App aus einer aktuellen Xcode-Vorlage besteht die Prüfung, ohne dass jemand etwas anfassen müsste – genau deshalb lässt sich die Regel leicht abtun und genau deshalb erwischt sie einen. Die gefährdeten Projekte teilen ein Merkmal: Niemand im Team hat die Info.plist in letzter Zeit von Hand geschrieben.

Generierte Property Lists sind die größte Kategorie, und der größte Generator ist Xcode selbst. Xcode 13 änderte die Voreinstellung: Projekte aus mehreren Vorlagen „benötigen keine Konfigurationsdateien wie Entitlements- und Info.plist-Dateien mehr”; stattdessen konfigurieren Sie die Felder im Info-Tab des Targets und im Build-Settings-Editor.⁹ Plattformübergreifende Toolchains, Wrapper-Frameworks und Build-Skripte, die eine Plist erst beim Paketieren erzeugen, legen eine zweite Schicht darüber – und deren Vorlagen können älter sein als UILaunchScreen überhaupt. Eine Datei, die das Build-System schreibt, prüft niemand.

Ausgedünnte Plists bilden die zweite Kategorie. Launch-Storyboards verschwinden bei der Größenoptimierung, bei der Migration weg vom Interface Builder oder beim Aufräumen, das das letzte Storyboard im Projekt entfernt und den Launch Screen gleich mitnimmt. Die App ließ sich weiterhin bauen, also wirkte die Entfernung harmlos.

Geerbte Projekte sind die dritte Kategorie, und diese Gruppe ist kleiner, als die meiste Berichterstattung annimmt. UILaunchStoryboardName kam mit iOS 9, ein seit 2015 fortgeführtes Projekt trägt also bereits einen gültigen Schlüssel.⁵ Die Apps ohne einen der vier sind älter: jene, die ihre Startgrafiken noch über UILaunchImages deklarieren – den Schlüssel aus iOS 7.0, den Apple mit iOS 13.0 und einer einzigen Anweisung für veraltet erklärt hat: „UILaunchImages ist veraltet; verwenden Sie stattdessen Launch-Storyboards von Xcode.”¹⁰ Ein UILaunchImages-Array steht nicht auf Apples Liste der vier. Ein Projekt, das sich weiterhin darauf verlässt und nie eine Storyboard-Referenz übernommen hat, besitzt also nichts, was die Anforderung akzeptiert. Ein Jahrzehnt Xcode-Updates wird daran nichts geändert haben, weil im Build nie etwas fehlgeschlagen ist.

Eine vom Build-System geschriebene Info.plist prüfen

Beginnen Sie mit der Einsicht, dass die Datei womöglich gar nicht existiert. GENERATE_INFOPLIST_FILE schaltet die automatische Erzeugung ein, und jedes Build Setting der Form INFOPLIST_KEY_* schreibt einen Schlüssel in die Plist, die der Build erzeugt.⁸ Für Launch Screens gibt es zwei davon: INFOPLIST_KEY_UILaunchScreen_Generation, das ein leeres UILaunchScreen-Dictionary schreibt, und INFOPLIST_KEY_UILaunchStoryboardName, das den Storyboard-Namen einträgt.⁸ Keines von beiden hinterlässt etwas, das eine Textsuche finden könnte. Xcodes aktuelle Vorlage „iOS SwiftUI App” liefert INFOPLIST_KEY_UILaunchScreen_Generation = YES in ihren gemeinsamen Einstellungen mit; ein so erzeugtes Projekt hat also ein regelkonformes Target, ohne dass irgendwo im Repository ein Text zum Launch Screen auftaucht.¹¹

Fragen Sie das Build-System statt des Dateisystems:

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj -target YourApp \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "^ +(GENERATE_INFOPLIST_FILE|INFOPLIST_FILE|INFOPLIST_KEY_UILaunch)"

Gegen das Projekt Ace Citizenship ausgeführt, liefert der Befehl auf meinem Rechner drei Zeilen:¹¹

    GENERATE_INFOPLIST_FILE = YES
    INFOPLIST_FILE = Ace-Citizenship-Info.plist
    INFOPLIST_KEY_UILaunchScreen_Generation = YES

Die dritte Zeile ist die vollständige Antwort auf die Frage der Konformität – und keine Datei im Repository enthält sie. Lesen Sie die Ausgabe in dieser Reihenfolge. GENERATE_INFOPLIST_FILE = YES zusammen mit einer auf YES gesetzten INFOPLIST_KEY_UILaunch-Zeile bedeutet, dass das Build-System den Schlüssel für Sie schreibt: Apple knüpft jede INFOPLIST_KEY_*-Einstellung an die aktivierte Erzeugung, weshalb dieselbe Zeile unter GENERATE_INFOPLIST_FILE = NO wirkungslos bleibt; und ein Wert von NO schreibt ohnehin nichts.⁸ Ist die Erzeugung aus, muss Ihr Launch-Screen-Schlüssel in der unter INFOPLIST_FILE angegebenen Datei stehen – öffnen Sie sie und suchen Sie nach einem der vier. Ist die Erzeugung an und zugleich ein Dateipfad vorhanden, führt das Build-System beide zusammen, und jede der beiden Quellen erfüllt die Anforderung.⁸

Beide Flags verdienen ihren Platz. -configuration Release zählt, weil die App-Store-Prüfung das Release-Produkt sieht. -sdk iphoneos zählt, weil Xcode diese Einstellungen bei plattformübergreifenden Targets pro SDK schreibt: Das Projekt Reps deklariert INFOPLIST_KEY_UILaunchScreen_Generation dreimal, je einmal für [sdk=iphoneos*], [sdk=iphonesimulator*] und [sdk=appletv*], Banana List die ersten beiden. Lassen Sie -sdk iphoneos weg, löst sich keine davon auf: Der Schlüssel verschwindet aus der Ausgabe, und ein regelkonformes Target sieht plötzlich nach Verstoß aus.¹¹

Prüfen Sie anschließend das Artefakt, das Sie tatsächlich einreichen. In der Ausgabe von plutil -p markieren zwei führende Leerzeichen einen Schlüssel der obersten Ebene:

plutil -p YourApp.xcarchive/Products/Applications/*.app/Info.plist \
  | grep -E '^  "UILaunch'

Gegen ein im April für die Distribution gebautes Return-Archiv kommt eine Zeile zurück; derselbe Befehl gibt bei einem Bundle ohne Launch Screen nichts aus und endet mit Exit-Code 1:¹¹

  "UILaunchScreen" => {

Greifen Sie hier zu plutil statt zu PlistBuddy. Bei einem Pfad, der sich nicht auflösen lässt, schreibt PlistBuddy -c "Print" die Meldung „File Doesn’t Exist, Will Create:” samt einem leeren Dict { } auf die Standardausgabe und endet mit 0; leiten Sie das in ein grep nach den Launch-Screen-Schlüsseln, verschluckt die Pipeline genau die Zeile, die den Fehler verraten würde, und übrig bleibt eine leere Ausgabe, die exakt wie ein fehlender Schlüssel aussieht. plutil nennt die Datei, die es nicht öffnen konnte, und endet mit 1.¹¹

Ein Durchlauf über das Repository hat weiterhin eine Aufgabe, nur eine kleinere als gedacht: von Hand gepflegte Plists zu finden, die einen Blick wert sind.

find . -name "Info.plist" \
  -not -path "*/build/*" -not -path "*/DerivedData/*" \
  -not -path "*/.build/*" -not -path "*/Carthage/*" -not -path "*/Pods/*" \
  -print0 | xargs -0 grep -L -E "UILaunchScreen|UILaunchStoryboard"

Jeder ausgegebene Pfad ist ein Kandidat für den Abgleich mit den Build Settings, kein Target, das bei der Einreichung durchfällt. Bei Banana List liefert der Befehl genau eine Zeile, ./Banana List/Info.plist, und dieses Target bringt trotzdem einen Launch Screen mit: In seinen Build Settings steht INFOPLIST_KEY_UILaunchScreen_Generation, und das archivierte Bundle enthält UILaunchScreen. Ohne die Ausschlüsse gibt derselbe Befehl in diesem Repository 25 Zeilen zurück, 24 davon Build-Artefakte unter build/, darunter Test-Runner-Bundles, XCTest.framework, ein .xcresult-Log und eine Watch-App.¹¹

Den Schlüssel von Hand hinzuzufügen kostet ein paar Schritte statt einer Textänderung. Apples Ablauf: In den Einstellungen Ihres Targets wählen Sie den Info-Tab; im Abschnitt „Custom iOS Target Properties” klappen Sie den Schlüssel „Launch Screen” auf; klicken Sie auf die Schaltfläche zum Hinzufügen, tippen Sie UILaunchScreen und drücken Sie die Eingabetaste; wählen Sie anschließend den Schlüssel UILaunchScreen aus, klicken Sie erneut auf Hinzufügen und ergänzen Sie untergeordnete Schlüssel für die gewünschten Darstellungsoptionen.² Bei einer von Xcode erzeugten Plist erledigt es dieselbe Aufgabe, INFOPLIST_KEY_UILaunchScreen_Generation in den Build Settings des Targets auf YES zu setzen – und das überlebt den nächsten Build.⁸ Wird die Plist von etwas anderem als Xcode erzeugt, ändern Sie die Vorlage des Generators; alles, was Sie an der Ausgabe bearbeiten, verwirft der nächste Build.

Was die Regel nicht sagt

Ein konkretes Datum hat Apple nicht veröffentlicht. Als Auslöser nennt Apple den Zeitpunkt, „sobald der App Store beginnt, mit dem 27.0-SDK gebaute Apps anzunehmen” – historisch liegt das nahe am Herbst-Release des Betriebssystems, für diesen Zyklus hat Apple sich jedoch schriftlich nicht festgelegt.¹ Betrachten Sie jedes konkrete Datum, das Sie irgendwo lesen, als Schlussfolgerung.

Apple hat ebenso wenig gesagt, dass bestehende Apps aufhören zu funktionieren, dass TestFlight-Builds betroffen sind oder dass die Anforderung über iOS und iPadOS hinausreicht. Die Notiz behandelt die Einreichung neuer Builds und sonst nichts.

Die Korrektur ist so klein, dass die interessante Frage nicht lautet, wie man die Regel erfüllt, sondern ob man sie längst erfüllt. Bei einem von Hand gepflegten Projekt lautet die Antwort fast sicher ja. Bei allem mit generierter Plist lohnt es sich, die Antwort beim Build-System einzuholen, bevor der Store anfängt, Nein zu sagen.

FAQ

Erfüllt eine App aus einer aktuellen Xcode-Vorlage die Regel bereits?

Mit ziemlicher Sicherheit ja – und der Beleg liegt in den Build Settings, nicht in einer Datei. Xcodes Vorlage „iOS SwiftUI App” setzt INFOPLIST_KEY_UILaunchScreen_Generation = YES in ihren gemeinsamen Einstellungen, was ein leeres UILaunchScreen-Dictionary in die vom Build-System erzeugte Info.plist schreibt.⁸¹¹ Prüfen Sie es, indem Sie xcodebuild -showBuildSettings für die Release-Konfiguration mit -sdk iphoneos ausführen und nach einer INFOPLIST_KEY_UILaunch-Zeile suchen.

Warum findet eine Suche nach UILaunchScreen in meinem Repository nichts?

Weil Projekte aus mehreren Vorlagen seit Xcode 13 keine Info.plist auf der Festplatte mehr mitführen; Apple hat diese Felder in den Info-Tab des Targets und in den Build-Settings-Editor verlagert.⁹ Der Launch Screen entsteht zur Build-Zeit aus INFOPLIST_KEY_UILaunchScreen_Generation oder INFOPLIST_KEY_UILaunchStoryboardName.⁸ Eine Textsuche über die Quelldateien sieht keine dieser beiden Einstellungen, und die Info.plist-Dateien, die sie doch findet, sind meist Teilfragmente, die das Build-System zusammenführt, oder Build-Artefakte unter build/ und DerivedData/.

Welchen Schlüssel füge ich hinzu, wenn ich wirklich keinen habe?

UILaunchStoryboardName, wenn Sie ein LaunchScreen.storyboard ausliefern, und UILaunchScreen, wenn nicht.⁴⁵ Für eine App, die auf einfarbigem Hintergrund startet, genügt ein leeres UILaunchScreen-Dictionary – genau das erzeugt Xcode standardmäßig.⁸ UILaunchScreens und UILaunchStoryboards lassen Sie aus, sofern Sie nicht für verschiedene URL-Schemata verschiedene Startzustände zeigen; Apples eigene Empfehlung lautet: „Wenn Sie nur einen Launch Screen benötigen, verwenden Sie stattdessen UILaunchScreen.”⁶

Gilt die Anforderung auch für TestFlight-Builds?

Apples Notiz sagt dazu nichts. Sie nennt eine einzige Konsequenz – die Ablehnung, „sobald der App Store beginnt, mit dem 27.0-SDK gebaute Apps anzunehmen” –, und die Verteilung über TestFlight kommt darin nirgends vor.¹ Da TestFlight-Builds durch App Store Connect und die Beta-Prüfung laufen, ist die sichere Annahme, dass ein Build, der die Anforderung verfehlt, überall dort durchfällt, wo er auf eine Prüfung trifft – geschrieben hat Apple das allerdings nicht. Wer sich auf die Antwort verlässt, sollte einen Upload mit dem 27.0-SDK testen, statt einer der beiden Lesarten des Schweigens zu vertrauen.

Die wichtigsten Erkenntnisse

Für iOS-Entwickler: - Fragen Sie die Build Settings ab, bevor Sie Dateien durchsuchen. Führen Sie xcodebuild -showBuildSettings -configuration Release -sdk iphoneos aus und achten Sie auf INFOPLIST_KEY_UILaunchScreen_Generation oder INFOPLIST_KEY_UILaunchStoryboardName.⁸ Eine Textsuche im Repository sieht beides nicht. - Wählen Sie UILaunchStoryboardName, wenn Sie ein Launch-Storyboard ausliefern, und UILaunchScreen, wenn nicht. Die Plural-Schlüssel lassen Sie aus, sofern Sie nicht je URL-Schema unterschiedliche Startzustände ausliefern.

Für Teams, die über plattformübergreifende Toolchains ausliefern: - Prüfen Sie das archivierte .app-Bundle mit plutil -p, nicht die Datei in der Versionsverwaltung. Die Prüfung sieht die Ausgabe des Generators, und plutil scheitert bei einem falschen Pfad lautstark, während PlistBuddy ein leeres Dictionary ausgibt und mit 0 endet. - Ändern Sie die Plist-Vorlage in Ihrer Build-Konfiguration statt der generierten Datei, sonst verwirft der nächste Build die Korrektur.

Für Release-Verantwortliche: - Der Fehlschlag zeigt sich bei der Einreichung im App Store, nicht zur Laufzeit; er kostet Sie also einen Prüfzyklus und keinen Produktionsvorfall. Planen Sie die Prüfung vor der ersten Einreichung mit dem 27.0-SDK ein, nicht nach einer Ablehnung. - Koppeln Sie die Prüfung mit der Migration zum szenenbasierten Lebenszyklus, die denselben Auslöser hat und härter bestraft wird.

Der 27er-Zyklus verwandelt weiterhin Empfehlungen in Vorschriften: ImageCreator funktioniert nicht mehr, der szenenbasierte Lebenszyklus wird zur Startvoraussetzung, und der Launch Screen wird zur Hürde bei der Einreichung. Was sonst noch im selben SDK steckt, steht in Neu in SwiftUI für iOS 27. Der vollständige Überblick zur Reihe findet sich in der Apple-Ecosystem-Reihe.

Quellen