Ekran startowy w iOS 27: cztery klucze albo odrzucenie

Apple w informacjach o wydaniu iOS 27 zamienia zdanie z dokumentacji w bramkę przy zgłaszaniu aplikacji: „Aplikacje na iOS i iPadOS zbudowane przy użyciu SDK w wersji 27.0 lub nowszej muszą zawierać ekran startowy. Plik Info.plist aplikacji musi zawierać jeden z następujących kluczy: UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen lub UILaunchScreens. Aplikacje bez ekranu startowego zostaną odrzucone, gdy App Store zacznie przyjmować aplikacje zbudowane przy użyciu SDK w wersji 27.0”.¹

Sam wymóg nie jest nowy. Przewodnik Apple dla Xcode zaczyna się zdaniem „Każda aplikacja na iOS musi udostępniać ekran startowy”.² Nowością w iOS 27 są konsekwencje jego zignorowania.

W skrócie

• Aplikacje zbudowane przy użyciu SDK z iOS w wersji 27.0 lub nowszej muszą deklarować ekran startowy za pomocą jednego z czterech kluczy Info.plist, a App Store odrzuca kompilacje, które tego nie robią.¹
• Bramka działa przy zgłaszaniu, nie w trakcie działania aplikacji. Apple pisze o odrzuceniu „gdy App Store zacznie przyjmować aplikacje zbudowane przy użyciu SDK w wersji 27.0”, więc niepowodzenie ujawnia się w App Store Connect, a nie na urządzeniu użytkownika.¹
• Zasada wymienia iOS i iPadOS — i na tym poprzestaje. Apple nie rozciąga jej w tej samej notatce na tvOS, visionOS ani Mac Catalyst.¹ Nakaz cyklu życia scen, pojawiający się w tym samym cyklu, brzmi inaczej: jego przewodnik migracji wymienia z nazwy iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 i visionOS 27.³
• Dwa klucze obsługują pojedynczy ekran startowy (UILaunchScreen buduje go w samej liście właściwości, UILaunchStoryboardName wskazuje plik storyboardu), a dwa kolejne — warianty przypisane do schematów URL (UILaunchScreens, UILaunchStoryboards). Trzy z czterech to słowniki; jedynie UILaunchStoryboardName jest ciągiem znaków.⁴⁵⁶⁷
• Projekty utworzone z niedawnych szablonów Xcode spełniają ten wymóg już na starcie, przy czym spełniają go poprzez ustawienie kompilacji, a nie plik.⁸¹¹ Audyt polegający na przeszukiwaniu repozytorium pod kątem czterech kluczy w ogóle nie prowadzi zatem do odpowiedzi.

Zasada sformułowana precyzyjnie

Trzy szczegóły w zdaniu Apple mają realne znaczenie, a publikacje na ten temat zwykle zacierają wszystkie trzy.

Po pierwsze, wyzwalaczem jest SDK, przy użyciu którego kompiluje się aplikację, a nie system, z którego korzystają użytkownicy. Plik binarny skompilowany przy użyciu SDK z iOS 26 zachowuje swoje miejsce w sklepie. Wystarczy jednak przebudować go w Xcode 27, by sięgnąć po cokolwiek z nowego SDK — wymóg przychodzi w komplecie.

Po drugie, punktem egzekwowania jest akceptacja w App Store. Apple użyło słowa „odrzucone”, co umieszcza niepowodzenie na etapie weryfikacji zgłoszenia, a nie przy uruchamianiu. To rozróżnienie oddziela zasadę ekranu startowego od nakazu cyklu życia scen, który pojawia się w tym samym cyklu i przy którym Apple pisze, że aplikacje „nie uruchomią się”.¹ W pierwszym przypadku kosztem jest odrzucona kompilacja, w drugim — martwa aplikacja na telefonie użytkownika.

Po trzecie, zakres to iOS i iPadOS. Notatka Apple wymienia te dwie platformy i milknie. Kto utrzymuje target dla Catalyst albo tvOS, powinien czytać ten wymóg jako niewypowiedziany, a nie rozszerzony przez analogię. Cykl 27 egzekwuje sporo w innych miejscach — od cyklu życia scen na pięciu platformach po usunięcie ImageCreatora z Image Playground — ale notatka o ekranie startowym pozostaje wąska.

Który z czterech kluczy zastosować

Apple oferuje dwa sposoby zbudowania ekranu startowego, a każdy z nich występuje w wariancie pojedynczym i mnogim — stąd cztery klucze.

UILaunchScreen konfiguruje interfejs startowy bezpośrednio w liście właściwości, bez udziału pliku storyboardu. Apple opisuje go jako sposób „konfigurowania interfejsu użytkownika podczas uruchamiania aplikacji bez polegania na storyboardach”; przyjmuje przy tym klucze podrzędne odpowiadające za kolor tła, obraz oraz widoczność paska nawigacji, paska kart i paska narzędzi.⁴ Dla aplikacji, której pierwszy ekran to zwykłe tło, pusty słownik UILaunchScreen spełnia wymóg. Sam system kompilacji Xcode idzie tą drogą: „Gdy GENERATE_INFOPLIST_FILE jest włączone”, INFOPLIST_KEY_UILaunchScreen_Generation „ustawia wartość klucza UILaunchScreen w pliku Info.plist na pusty słownik”.⁸

UILaunchStoryboardName wskazuje storyboard nazwą pliku, bez rozszerzenia: plik LaunchScreen.storyboard staje się ciągiem LaunchScreen.⁵ Klucz pochodzi z iOS 9 i jako jedyny z czwórki przyjmuje ciąg znaków zamiast słownika.⁵ Ten klucz jest właściwy dla aplikacji z zaprojektowanym stanem startowym oraz dla każdego projektu, który dostarcza plik LaunchScreen.storyboard wciąż dodawany przez Xcode do szablonów opartych na storyboardach.²

Formy w liczbie mnogiej istnieją dla jednego konkretnego przypadku i obie są słownikami, nie tablicami.⁶⁷ UILaunchScreens mieści trzy klucze podrzędne: UILaunchScreenDefinitions, czyli tablicę konfiguracji ekranów startowych, z których każda niesie UILaunchScreenIdentifier; UIURLToLaunchScreenAssociations, czyli mapowanie schematu URL na identyfikator; oraz UIDefaultLaunchScreen jako wariant awaryjny.⁶ UILaunchStoryboards odzwierciedla ten kształt kluczami UILaunchStoryboardDefinitions, UIURLToLaunchStoryboardAssociations i UIDefaultLaunchStoryboard.⁷ Każdy z nich pozwala aplikacji otwartej z myapp://compose pokazać inny stan startowy niż ta sama aplikacja otwarta z ekranu głównego. Apple mówi wprost, że większość aplikacji powinna je pominąć: „Jeśli potrzebny jest tylko jeden ekran startowy, należy zamiast tego użyć UILaunchScreen”.⁶

W praktyce decyzja sprowadza się do jednego pytania. Jeśli ekran startowy jest storyboardem, trzeba zadeklarować UILaunchStoryboardName. Jeśli nie jest — UILaunchScreen. Po klucz w liczbie mnogiej warto sięgać tylko wtedy, gdy już wiadomo, po co.

Aplikacje, które realnie wpadają w pułapkę

Aplikacja utworzona z aktualnego szablonu Xcode przechodzi bez niczyjej ingerencji — i właśnie dlatego tę zasadę tak łatwo zbagatelizować i tak łatwo dać się na niej złapać. Zagrożone projekty łączy jedna cecha: nikt w zespole nie pisał ostatnio Info.plist ręcznie.

Generowane listy właściwości to kategoria największa, a największym generatorem jest sam Xcode. Xcode 13 zmienił domyślne zachowanie: projekty tworzone z kilku szablonów „nie wymagają już plików konfiguracyjnych, takich jak pliki uprawnień i Info.plist”, a pola konfiguruje się zamiast tego w karcie Info targetu oraz w edytorze ustawień kompilacji.⁹ Drugą warstwę dokładają wieloplatformowe łańcuchy narzędzi, frameworki opakowujące i skrypty kompilacji, które syntetyzują plist na etapie pakowania — ich szablony mogą być starsze niż samo istnienie UILaunchScreen. Nikt nie przegląda pliku, który zapisuje system kompilacji.

Okrojone pliki plist to kategoria druga. Storyboardy startowe znikają przy optymalizacji rozmiaru, przy migracji z Interface Buildera albo przy porządkach, które usunęły ostatni storyboard w projekcie i zabrały ze sobą ekran startowy. Aplikacja nadal się kompilowała, więc usunięcie wyglądało bezpiecznie.

Trzecia kategoria to projekty odziedziczone, a jej zasięg jest węższy, niż zakłada większość publikacji. UILaunchStoryboardName pojawił się w iOS 9, więc projekt prowadzony nieprzerwanie od 2015 roku ma już kwalifikujący się klucz.⁵ Aplikacje pozbawione wszystkich czterech są starsze: to te, które wciąż deklarują grafikę startową przez UILaunchImages — klucz z iOS 7.0, wycofany przez Apple w iOS 13.0 wraz z jedną instrukcją: „UILaunchImages zostało wycofane; należy używać storyboardów startowych Xcode”.¹⁰ Tablica UILaunchImages nie figuruje na liście czterech kluczy Apple, więc projekt, który wciąż na niej polega i nigdy nie przyjął odwołania do storyboardu, nie ma niczego, co wymóg zaakceptuje. Dekada aktualizacji Xcode niczego nie dodała, bo nic w kompilacji nigdy nie zawiodło.

Audyt pliku Info.plist, który pisze system kompilacji

Punkt wyjścia: pogodzić się z tym, że ten plik może nie istnieć. GENERATE_INFOPLIST_FILE włącza automatyczne generowanie, a każde ustawienie kompilacji INFOPLIST_KEY_* zapisuje jeden klucz do pliku plist powstającego w wyniku kompilacji.⁸ Ekranom startowym odpowiadają dwa takie ustawienia: INFOPLIST_KEY_UILaunchScreen_Generation, które zapisuje pusty słownik UILaunchScreen, oraz INFOPLIST_KEY_UILaunchStoryboardName, które zapisuje nazwę storyboardu.⁸ Żadne z nich nie zostawia niczego, co znalazłoby wyszukiwanie tekstowe. Aktualny szablon Xcode „iOS SwiftUI App” dostarcza w ustawieniach współdzielonych INFOPLIST_KEY_UILaunchScreen_Generation = YES, więc tak utworzony projekt ma zgodny target, choć w całym repozytorium nie ma ani słowa o ekranie startowym.¹¹

Zamiast systemu plików warto zapytać system kompilacji:

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

Na moim komputerze, uruchomione w projekcie Ace Citizenship, polecenie zwraca trzy wiersze:¹¹

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

Trzeci wiersz to cała odpowiedź w kwestii zgodności — i żaden plik w repozytorium go nie zawiera. Wynik należy czytać w tej właśnie kolejności. GENERATE_INFOPLIST_FILE = YES plus wiersz INFOPLIST_KEY_UILaunch ustawiony na YES oznacza, że klucz zapisuje za programistę system kompilacji: Apple uzależnia każde ustawienie INFOPLIST_KEY_* od włączonego generowania, więc ten sam wiersz pozostaje martwy przy GENERATE_INFOPLIST_FILE = NO, a wartość NO i tak niczego nie zapisuje.⁸ Przy wyłączonym generowaniu klucz ekranu startowego musi znaleźć się w pliku wskazanym przez INFOPLIST_FILE — trzeba więc otworzyć ten plik i poszukać jednego z czterech kluczy. Przy generowaniu włączonym i jednocześnie podanej ścieżce pliku system kompilacji scala oba źródła, a wymóg spełnia dowolne z nich.⁸

Obie flagi zasługują na swoje miejsce. -configuration Release ma znaczenie, bo weryfikacja w App Store widzi produkt Release. -sdk iphoneos ma znaczenie, bo w targetach wieloplatformowych Xcode zapisuje te ustawienia osobno dla każdego SDK: projekt Reps deklaruje INFOPLIST_KEY_UILaunchScreen_Generation trzykrotnie, po razie dla [sdk=iphoneos*], [sdk=iphonesimulator*] i [sdk=appletv*], a Banana List deklaruje dwa pierwsze warianty. Bez -sdk iphoneos żadne z nich nie zostaje zastosowane, klucz znika z wyniku, a zgodny target wygląda na niespełniający wymogu.¹¹

Następnie warto sprawdzić artefakt, który faktycznie trafia do zgłoszenia. W wyniku plutil -p dwie spacje na początku wiersza oznaczają klucz najwyższego poziomu:

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

Na archiwum projektu Return zbudowanym do dystrybucji w kwietniu wraca jeden wiersz, a to samo polecenie na pakiecie bez ekranu startowego nie wypisuje nic i kończy się kodem 1:¹¹

  "UILaunchScreen" => {

W tym miejscu lepiej sięgnąć po plutil niż po PlistBuddy. Przy ścieżce wskazującej nieistniejący plik PlistBuddy -c "Print" wypisuje na standardowe wyjście „File Doesn’t Exist, Will Create:” oraz pusty Dict { } i kończy się kodem 0; po przepuszczeniu tego przez grep szukający kluczy ekranu startowego jedyny wiersz zdradzający pomyłkę zostaje połknięty, a puste wyjście wygląda dokładnie jak brakujący klucz. plutil nazywa plik, którego nie udało się otworzyć, i kończy się kodem 1.¹¹

Przeczesanie repozytorium wciąż ma swoje zadanie, tyle że mniejsze, niż się wydaje: znalezienie ręcznie utrzymywanych plików plist wartych przejrzenia.

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"

Każda wypisana ścieżka jest kandydatem do skonfrontowania z ustawieniami kompilacji, a nie targetem, który odpadnie przy zgłoszeniu. W Banana List polecenie zwraca dokładnie jeden wiersz, ./Banana List/Info.plist, a ten target i tak dostarcza ekran startowy: jego ustawienia kompilacji niosą INFOPLIST_KEY_UILaunchScreen_Generation, a zarchiwizowany pakiet zawiera UILaunchScreen. Bez wykluczeń to samo polecenie zwraca w tym repozytorium 25 wierszy, z czego 24 to artefakty kompilacji w katalogu build/, w tym pakiety testowe, XCTest.framework, log .xcresult i aplikacja na zegarek.¹¹

Ręczne dodanie klucza to kilka kroków, a nie edycja tekstu. Sekwencja według Apple: w ustawieniach targetu wybrać kartę Info; w sekcji Custom iOS Target Properties rozwinąć klucz Launch Screen; kliknąć przycisk dodawania, wpisać UILaunchScreen i nacisnąć Return; następnie zaznaczyć klucz UILaunchScreen, kliknąć dodawanie ponownie i dodać klucze podrzędne dla wybranych opcji wyglądu.² Przy pliku plist generowanym przez Xcode to samo zadanie wykonuje ustawienie INFOPLIST_KEY_UILaunchScreen_Generation na YES w ustawieniach kompilacji targetu — i przetrwa ono kolejną kompilację.⁸ Jeśli plist generuje coś innego niż Xcode, trzeba poprawić szablon generatora; kolejna kompilacja i tak nadpisze wszystkie zmiany wprowadzone w pliku wynikowym.

Czego zasada nie mówi

Apple nie opublikowało konkretnej daty. Wyzwalacz sformułowano jako moment, „gdy App Store zacznie przyjmować aplikacje zbudowane przy użyciu SDK w wersji 27.0” — historycznie przypada to blisko jesiennego wydania systemu, ale w tym cyklu Apple nie zobowiązało się do tego na piśmie.¹ Każdą konkretną datę, na jaką można trafić, należy traktować jako domysł.

Apple nie stwierdziło też, że istniejące aplikacje przestaną działać, że wymóg dotyczy kompilacji w TestFlight ani że wykracza poza iOS i iPadOS. Notatka obejmuje zgłaszanie nowych kompilacji i nic ponadto.

Poprawka jest na tyle drobna, że interesujące pytanie nie brzmi „jak spełnić wymóg”, lecz „czy przypadkiem już go nie spełniam”. W projekcie utrzymywanym ręcznie odpowiedź niemal na pewno brzmi: tak. Przy czymkolwiek z generowanym plikiem plist warto ją potwierdzić w systemie kompilacji, zanim sklep zacznie mówić „nie”.

FAQ

Czy aplikacja zbudowana z aktualnego szablonu Xcode spełnia już wymóg?

Niemal na pewno, przy czym dowód kryje się w ustawieniach kompilacji, a nie w pliku. Szablon Xcode „iOS SwiftUI App” ma w ustawieniach współdzielonych INFOPLIST_KEY_UILaunchScreen_Generation = YES, co zapisuje pusty słownik UILaunchScreen do pliku Info.plist tworzonego przez system kompilacji.⁸¹¹ Można to potwierdzić, uruchamiając xcodebuild -showBuildSettings dla konfiguracji Release z -sdk iphoneos i szukając wiersza INFOPLIST_KEY_UILaunch.

Dlaczego przeszukiwanie repozytorium pod kątem UILaunchScreen niczego nie znajduje?

Ponieważ od Xcode 13 projekty tworzone z kilku szablonów nie mają na dysku pliku Info.plist; Apple przeniosło te pola do karty Info targetu i do edytora ustawień kompilacji.⁹ Ekran startowy pojawia się z INFOPLIST_KEY_UILaunchScreen_Generation albo INFOPLIST_KEY_UILaunchStoryboardName na etapie kompilacji.⁸ Wyszukiwanie tekstowe po plikach źródłowych nie widzi żadnego z tych ustawień, a znajdowane pliki Info.plist to zwykle częściowe fragmenty scalane przez system kompilacji albo artefakty kompilacji w katalogach build/ i DerivedData/.

Który klucz dodać, jeśli faktycznie nie ma żadnego?

UILaunchStoryboardName, jeśli dostarczany jest plik LaunchScreen.storyboard, a UILaunchScreen, jeśli nie.⁴⁵ Pusty słownik UILaunchScreen wystarcza aplikacji uruchamiającej się na zwykłym tle — i to właśnie generuje Xcode domyślnie.⁸ UILaunchScreens i UILaunchStoryboards można pominąć, o ile nie prezentuje się różnych stanów startowych dla różnych schematów URL; własne zalecenie Apple brzmi: „Jeśli potrzebny jest tylko jeden ekran startowy, należy zamiast tego użyć UILaunchScreen”.⁶

Czy wymóg dotyczy kompilacji w TestFlight?

Notatka Apple tego nie mówi. Wymienia jedną konsekwencję — odrzucenie „gdy App Store zacznie przyjmować aplikacje zbudowane przy użyciu SDK w wersji 27.0” — a dystrybucja przez TestFlight nie pojawia się w niej w ogóle.¹ Ponieważ kompilacje TestFlight przechodzą przez App Store Connect i weryfikację wersji beta, bezpieczne założenie jest takie, że kompilacja niespełniająca wymogu polegnie wszędzie tam, gdzie trafi na weryfikację — Apple jednak tego nie zapisało. Kto opiera się na tej odpowiedzi, powinien przetestować wysłanie kompilacji zbudowanej na SDK 27.0, zamiast ufać którejkolwiek interpretacji tego milczenia.

Najważniejsze wnioski

Dla deweloperów iOS: - Zanim przeszuka się pliki, warto odpytać ustawienia kompilacji. Uruchomić xcodebuild -showBuildSettings -configuration Release -sdk iphoneos i poszukać INFOPLIST_KEY_UILaunchScreen_Generation albo INFOPLIST_KEY_UILaunchStoryboardName.⁸ Wyszukiwanie tekstowe w repozytorium żadnego z nich nie zobaczy. - Wybrać UILaunchStoryboardName, jeśli dostarczany jest storyboard startowy, a UILaunchScreen, jeśli nie. Klucze w liczbie mnogiej pominąć, chyba że prezentuje się różne stany startowe zależnie od schematu URL.

Dla zespołów wydających przez wieloplatformowe łańcuchy narzędzi: - Audytować zarchiwizowany pakiet .app poleceniem plutil -p, a nie plik w systemie kontroli wersji. To wynik generatora widzi weryfikacja, a plutil zawodzi głośno przy złej ścieżce tam, gdzie PlistBuddy wypisuje pusty słownik i kończy się kodem 0. - Poprawiać szablon pliku plist w konfiguracji kompilacji, a nie plik wygenerowany — inaczej kolejna kompilacja nadpisze poprawkę.

Dla osób zarządzających wydaniami: - Niepowodzenie ujawnia się przy zgłoszeniu do App Store, a nie w trakcie działania aplikacji, więc kosztuje cykl weryfikacji, a nie incydent produkcyjny. Audyt warto zaplanować przed pierwszym zgłoszeniem zbudowanym na SDK 27.0, a nie po odrzuceniu. - Sprawdzenie warto połączyć z migracją cyklu życia scen, która ma ten sam wyzwalacz i niesie surowszą karę.

Cykl 27 konsekwentnie zamienia sugestie w egzekwowanie: ImageCreator przestaje działać, cykl życia scen staje się wymogiem uruchomienia, a ekran startowy — bramką przy zgłaszaniu. Po resztę tego, co trafia w tym samym SDK, warto zajrzeć do artykułu Co nowego w SwiftUI w iOS 27. Centrum całej serii to Seria o ekosystemie Apple.

Bibliografia