Era iPhone'a o zmiennym rozmiarze: jak przygotować aplikację przed wrześniem

Jak przygotować aplikację na iPhone’a do ekranów o zmiennym rozmiarze? Granicę wyznacza SDK, z którym aplikacja jest linkowana: Device Hub w Xcode 27 wprost traktuje tryb zmiany rozmiaru jako nieobsługiwany dla aplikacji linkowanych z SDK iOS 26 lub wcześniejszym, a każdy wpis o zmianie rozmiaru w informacjach o wydaniu iOS 27 jest uwarunkowany zwrotem „zbudowana z SDK iOS 27”.¹² Następnie: należy przejrzeć każde założenie o stałym rozmiarze (odczyty UIScreen.main.bounds, zakodowane na sztywno ramki, układy uzależnione od orientacji), oprzeć się na klasach rozmiaru i adaptacyjnych kontenerach SwiftUI oraz testować na bieżąco w podglądach Resizable Canvas w Xcode 27 i w trybie zmiany rozmiaru w Device Hub.² Wymóg orientacji, który blokował ciągłą zmianę rozmiaru, jest w bieżących informacjach o wydaniu oznaczony jako Fixed, więc droga jest wolna.¹

Jesienne bety Apple przez całe lato zbiegały się w jednym przekazie dla twórców aplikacji na iPhone’a: koniec z założeniem stałego prostokąta. Dowody są w narzędziach i w informacjach o wydaniu, a nie w keynote’ach: możliwość zmiany rozmiaru przychodzi wraz z linkowaniem do SDK iOS 27, płótno podglądu skaluje się swobodnie, a informacje o wydaniu usunęły ostatnią przeszkodę strukturalną w miarę dojrzewania cyklu bet. Niezależnie od tego, jaki sprzęt pojawi się tej jesieni, kontrakt po stronie oprogramowania już się zmienił.

TL;DR: iOS 27 wprowadza ciągłą zmianę rozmiaru w aplikacjach zbudowanych z nowym SDK; Xcode 27 dostarcza powierzchnie do testowania tego (podglądy Resizable Canvas, tryb zmiany rozmiaru w Device Hub); a bieżące informacje o wydaniu — edycja dla bety 7, przy czym beta 7 ukazała się 24 sierpnia — wskazują wymóg orientacji jako Fixed: przeszedł on ze znanych problemów do problemów rozwiązanych między edycjami dla bety 4 i bety 6, a zadeklarowane orientacje nie decydują już o tym, czy aplikacja zmienia rozmiar.¹ Praca polega głównie na odejmowaniu: trzeba znaleźć miejsca, w których układ wierzy w jeden rozmiar ekranu, i tę wiarę usunąć. Poniżej lista kontrolna w kolejności, w jakiej sam bym ją przerabiał.

Dlaczego teraz

Zegar nastawiają trzy opatrzone datą fakty:

1. Beta 7 pojawiła się 24 sierpnia, gdy cykl wszedł w fazę stabilizacji: późne bety Apple raczej naprawiają, niż dodają, a wersje finalne co roku ukazywały się we wrześniu.¹
2. Granicą możliwości zmiany rozmiaru jest linkowanie do SDK. Informacje o wydaniu Xcode 27 opisują wejście w tryb zmiany rozmiaru w Device Hub „z aplikacją linkowaną z SDK iOS 26 lub wcześniejszym” jako „nieobsługiwane”.² Ten sam schemat przewija się przez informacje o wydaniu iOS: każdy wpis o zmianie rozmiaru jest uwarunkowany zwrotem „zbudowana z SDK iOS 27”. Przebudowa stawia aplikację po skalowalnej stronie tej granicy; pozostanie przy starym SDK oznacza rezygnację z kierunku, w którym idzie platforma.
3. Ostatnia strukturalna blokada zniknęła. W czasach bety 4 aplikacja na iPada, której UISupportedInterfaceOrientations pomijało którąkolwiek z czterech orientacji, była traktowana jako niepodlegająca ciągłej zmianie rozmiaru: znany problem, którego udokumentowane obejście miało nieudokumentowany koszt, opisany przeze mnie we wpisie o tym obejściu. Problem ten przeszedł ze znanych problemów do rozwiązanych między edycjami dla bety 4 i bety 6, a bieżąca edycja oznacza go jako Fixed: „Począwszy od iOS 27 obsługiwane orientacje interfejsu nie powinny już stanowić warunku ciągłej zmiany rozmiaru”. Lista znanych problemów UIKit w informacjach dla bety 7 jest pusta.¹

Razem: platforma oczekuje teraz, że układ będzie funkcją swojego kontenera, a nie specyfikacji urządzenia. iPad nauczył tego jako pierwszy przy wielozadaniowości; iOS 27 rozciąga ten sam kontrakt na iPhone’a.

Lista kontrolna

1. Przebudować z SDK iOS 27, a potem naprawdę popatrzeć

Zgodą na udział jest przebudowa. Zanim zmieni się choćby wiersz kodu układu, warto zbudować aplikację w Xcode 27, otworzyć tryb zmiany rozmiaru w Device Hub i pociągnąć za krawędź. Większość dobrze rozłożonych aplikacji SwiftUI przechodzi ten pierwszy kontakt lepiej, niż spodziewają się ich autorzy; to, co się psuje, jest pouczające i psuje się za każdym razem w tej samej garstce miejsc — o czym mówi cała reszta tej listy.

2. Wytropić przekonania o stałym rozmiarze

Klasyczni winowajcy w kolejności, w jakiej zwykle gryzą:

• UIScreen.main.bounds używane jako „rozmiar ekranu”. W świecie zmiennych rozmiarów nie ma jednego rozmiaru ekranu, a UIScreen.main jest formalnie wycofywane od iOS 26. Rozmiary należy wyprowadzać z window scene lub — w SwiftUI — z kontenera, przez oszczędnie używany GeometryReader albo świadomie użyty containerRelativeFrame(_:).
• Zakodowane na sztywno ramki i magiczne liczby dobrane pod konkretne urządzenia („390 punktów szerokości znaczy iPhone”). Każde wnioskowanie o urządzeniu w rodzaju if width == <number> skłamie.
• Układ uzależniony od orientacji zamiast od rozmiaru. Sprawdzanie orientacji zawsze było tylko namiastką; skoro iOS 27 odcina orientacje od możliwości zmiany rozmiaru, ta namiastka jest już oficjalnie balastem. Rozgałęziać należy według poziomej i pionowej klasy rozmiaru, bo do tego właśnie służą.
• Buforowanie wymiarów przy starcie. Wszystko, co zmierzone raz przy uruchomieniu i zapisane, jest nieaktualne po pierwszej zmianie rozmiaru.

3. Pozwolić adaptacyjnym kontenerom robić swoje

Nowoczesny zestaw układu w SwiftUI powstał dokładnie w tym celu: ViewThatFits do wyboru między wariantami rozmieszczenia, containerRelativeFrame do wymiarowania względem kontenera, a nie ekranu, oraz siatki i elastyczne ramki na wszystko pomiędzy. Jeśli aplikacja pochodzi z epoki stałego prostokąta, największą dźwignię daje zwykle zastąpienie jednego nośnego układu opartego na GeometryReader i arytmetyce tymi prymitywami. Aplikacje UIKit osiągają ten sam efekt dzięki klasom rozmiaru i sterowanym środowiskiem sekcjom UICollectionViewCompositionalLayout.

Zmiany w paskach narzędzi i w układzie w iOS 27 pchają w tę samą stronę: framework daje teraz jawną kontrolę w punktach, w których kończy się miejsce, a miejsce kończy się teraz dynamicznie.

4. Testować tam, gdzie zmiana rozmiaru naprawdę zachodzi

Xcode 27 daje dwie powierzchnie stworzone specjalnie do tego, obie dojrzałe od wczesnej fazy cyklu bet:

• Tryb Resizable Canvas w podglądach: nie jest już ograniczony do konkretnych proporcji rozmiaru (ograniczenie zniesiono w becie 2), więc można przeciągać przez cały zakres kształtów, jakie aplikacja może przybrać.²
• Tryb zmiany rozmiaru w Device Hub dla działających aplikacji, z furtkami awaryjnymi naprawionymi od bety 3 (wyjście z trybu zmiany rozmiaru przez awarię lub przejście w tło nie blokuje już ekranu urządzenia aż do ponownego uruchomienia).²

Warto przejść przez każdy główny ekran w obu trybach. Znalezione błędy skupią się na ekranach, które buforowały, zakładały albo wnioskowały.

5. Ponownie przemyśleć flagi ustawione lata temu

UIRequiresFullScreen i wąskie deklaracje UISupportedInterfaceOrientations to sposób, w jaki aplikacje historycznie wypisywały się z wymagań wielozadaniowości iPada. Żadna z nich nie jest wycofana, ale obie są teraz nośne w nowy sposób: cykl bet poświęcił kilka edycji na ustalenie, jak współgrają z ciągłą zmianą rozmiaru, a znane problemy z czasów bety 4 dotyczące zachowania UIRequiresFullScreen przy zmianie rozmiaru są teraz oznaczone jako Fixed wśród problemów rozwiązanych.¹ Jeśli te klucze siedzą w pliku Info.plist z powodu decyzji podjętej w 2019 roku, to jest właśnie miesiąc, by podjąć tę decyzję na nowo i świadomie. Analiza kosztu obejścia omawia skutki uboczne zestawu orientacji, które warto sprawdzić przed rozszerzeniem czegokolwiek.

6. Zaplanować efekty drugiego rzędu

Zmienny rozmiar oznacza, że tekst łamie się inaczej, obrazy kadrują się inaczej, NavigationSplitView zwija się i rozwija według czyjegoś kaprysu, a starannie dopracowane stany puste pokazują się w proporcjach, których nigdy nie było w podglądzie. Nic z tego nie jest trudne z osobna. To wszystko razem jest powodem, dla którego lista zaczyna się teraz, a nie w tygodniu premiery sprzętu.

Co bym pominął

Warto pominąć spekulacje o konkretnych urządzeniach. Kontrakt zmiany rozmiaru jest w SDK, które można pobrać dzisiaj, opisany w informacjach o wydaniu, które można przeczytać dzisiaj, i testowalny w narzędziach, które trafiły do pierwszej bety Xcode 27. Jeśli składany iPhone pojawi się tej jesieni, aplikacje po powyższej liście są gotowe; jeśli pojawi się następnej wiosny, ta sama praca od razu zwraca się przy wielozadaniowości iPada i przy wszystkim innym, czemu platforma pozwoli zmieniać rozmiar. Przygotowanie na mechanizm bije przygotowanie na plotkę.

Najważniejsze wnioski

• Granicą zgody jest linkowanie do SDK. Po przebudowie z SDK iOS 27 zmiana rozmiaru staje się problemem i szansą aplikacji; Device Hub traktuje aplikacje ze starszym SDK w trybie zmiany rozmiaru jako nieobsługiwane.²
• Blokada orientacji zniknęła. Zadeklarowane orientacje nie decydują już o zmianie rozmiaru: problem jest w bieżących informacjach oznaczony jako Fixed, a lista znanych problemów UIKit jest pusta.¹
• Praca polega na usuwaniu założeń, nie na dodawaniu funkcji. Odczyty rozmiaru ekranu, układy na magicznych liczbach, namiastki w postaci orientacji, bufory z chwili startu: znaleźć, zastąpić układem wyprowadzonym z kontenera, gotowe.
• Testować na prawdziwych powierzchniach. Podglądy Resizable Canvas i tryb zmiany rozmiaru w Device Hub istnieją dokładnie po to; jedno przejście przez każdy z nich na każdym ekranie wyłapuje większość tego, co ugryzie.

FAQ

Czy aplikacja staje się skalowalna automatycznie?

Granicą wyznaczoną przez Apple jest linkowanie do SDK: informacje o wydaniu Xcode 27 nazywają tryb zmiany rozmiaru z aplikacjami na SDK iOS 26 lub wcześniejszym nieobsługiwanym, a informacje o wydaniu iOS uzależniają każde zachowanie związane ze zmianą rozmiaru od zbudowania z SDK iOS 27.¹² Co stanie się dalej, zależy od układu: SwiftUI sterowany kontenerem w większości się dostosowuje; założenia o stałym rozmiarze wychodzą na wierzch jako błędy.

Czy nadal trzeba deklarować wszystkie cztery orientacje, aby uzyskać ciągłą zmianę rozmiaru?

Nie: bieżące informacje o wydaniu oznaczają warunek orientacji jako Fixed (sprawa rozwiązała się między edycjami dla bety 4 i bety 6) i stwierdzają, że „obsługiwane orientacje interfejsu nie powinny już stanowić warunku ciągłej zmiany rozmiaru”.¹ Wcześniejsze bety wymagały obejścia z czterema orientacjami, które miało skutki uboczne w całej aplikacji, warte zrozumienia, jeśli trafiło do wydania.

Czy UIRequiresFullScreen jest już wycofany?

Nie. Pozostaje obsługiwanym kluczem, a znane problemy z cyklu bet dotyczące jego zachowania przy zmianie rozmiaru są w bieżących informacjach oznaczone jako Fixed wśród problemów rozwiązanych.¹ Jest to jednak dokładnie ten rodzaj podjętej przed laty rezygnacji, którą warto świadomie przemyśleć na nowo na platformie stawiającej zmienny rozmiar na pierwszym miejscu.

Kiedy staje się to pilne?

Finalnych wydań iOS 27 należy spodziewać się we wrześniu, a jesienny cykl wymagań SDK Apple oznacza, że nowe zgłoszenia przejdą na SDK iOS 27 zgodnie ze zwykłym harmonogramem Apple po tej dacie. Powyższa lista to dla większości aplikacji tydzień skupionej pracy — spokojnie do zrobienia przed sezonem premier, jeśli zacząć teraz.

Źródła