Projektowanie dla iPhone'a Duo: co się przesuwa, co się dzieli, a co zostaje

Czego wymaga projektowanie dla iPhone’a Duo? Dwóch układów, a nie jednego układu na każdą pozycję: „Układ w compact width dla ekranu zewnętrznego i układ w regular width dla ekranu wewnętrznego dają podstawy pod każdą pozycję”, a rada samego Apple brzmi: „zaprojektuj aplikację tak, aby swobodnie zmieniała rozmiar”. (4:32)¹² Na tej podstawie opierają się cztery wzorce opisane w przewodniku i w trzech towarzyszących mu Tech Talkach: kontrolki przenoszą się na bok ekranu i zachowują kolejność od góry do dołu; treść zostaje odsunięta od tych kontrolek, chyba że celowo wypełnia całą szerokość; elementy interaktywne przemieszczają się z dala od zagięcia, a treści przewijane nie; nowy kontener, czyli arrangement, dzieli albo nakłada dwa widoki według reguł. Tech Talki omawiają API stojące za dwoma ostatnimi punktami, a arrangementy pojawiają się wraz z iOS 27.1.³

Apple opublikowało Designing for iPhone Duo w Human Interface Guidelines po południu w dniu keynote’u, razem z trzema Tech Talkami skierowanymi do projektantów: „Design for iPhone Duo”, „Strike a pose with adaptive layouts on iPhone Duo” oraz „Raise the bar with iPhone Duo”.¹²³⁴ Tekst dla programistów na tej stronie przelicza punkty i omawia reguły SDK. Ten tekst dotyczy decyzji projektowych, jakich wymaga przewodnik, cytowanych słowami samego Apple wraz ze znacznikiem czasu w każdym z Tech Talków, a także tego, co zamierzam z nimi zrobić we własnych aplikacjach.

TL;DR: Warto projektować pod dwie klasy rozmiaru i zostawić pozycje systemowi. Paski ustawiają się pionowo z boku ekranu zewnętrznego oraz na ekranie wewnętrznym w orientacji poziomej; jedynie ekran wewnętrzny w orientacji pionowej zachowuje paski poziome.⁴ Elementy z ikoną przechodzą w pion, elementy wyłącznie tekstowe zostają w poziomie, a górę pionowego paska zajmuje Back albo Close, po czym następuje wyróżniona akcja w rodzaju Done.⁴ Treść zostaje odsunięta od paska poprzez poziomy bezpieczny obszar, chyba że jest immersyjna i się nie przewija.² Przy zagięciu w pozycji książki „elementy takie jak alerty przenoszą się na stronę trailing” (4:09), a na stole interaktywne kontrolki schodzą do dolnej połowy; z kolei „treści przewijane w sposób ciągły, takie jak artykuły, kanały, dokumenty i listy, nie przemieszczają się” (3:46).³ Arrangementy to nowy kontener układu, w wariancie split albo overlay, a reguła wyboru podana przez Apple jest dokładnie tą, którą już się stosuje: stos poziomy lub pionowy staje się splitem, a ZStack staje się overlayem.³

Jedna reguła przed wzorcami

Dwa z Tech Talków oraz przewodnik powtarzają to samo zdanie i właśnie od niego należy zacząć projektowanie. Vince z zespołu projektowego Apple: „Ludzie będą używać iPhone’a Duo w wielu różnych pozycjach i zależy nam, żeby aplikacja świetnie wyglądała w każdej z nich. Nie oznacza to jednak projektowania osobnego układu pod każdą pozycję. Zamiast tego skupmy się na dwóch klasach rozmiaru: compact width na ekranie zewnętrznym i regular width na ekranie wewnętrznym. Unikajmy stałych szerokości, punktów granicznych oraz wszelkich miar powiązanych z konkretnym ekranem” (3:50).² Przewodnik mówi to samo w części poświęconej pozycjom.¹ Vince dodaje jeden opcjonalny układ, dla urządzenia postawionego na stole niczym laptop, w którym „media mogą znaleźć się u góry, a kontrolki do dotknięcia spoczywają na stabilnej podstawie na dole” (4:48) — pod warunkiem, że układ ten „ma dokładnie te same kontrolki i tę samą ogólną hierarchię co pozostałe pozycje” (4:57).²

Kadr z transmisji wydarzenia Apple z 9 września 2026, godzina 11:05 czasu pacyficznego: pozycja stojąca. Lista z przewodnika brzmi: „częściowo złożony jak książka, położony na powierzchni lub postawiony na krawędziach”.

Wszystko poniżej zakłada tę właśnie podstawę — tę samą, którą kontroluje lista kontrolna dla skalowalnego iPhone’a i którą wyjaśnia tekst o zmianie rozmiaru na iPadzie. Jeśli układ zbudowano z klas rozmiaru, marginesów układu i wcięć bezpiecznego obszaru, obietnica Vince’a brzmi: „aplikacja powinna już dostosowywać się do iPhone’a Duo” (4:27).²

Bok ekranu: co się tam przenosi, a co zostaje

Na ekranie zewnętrznym kontrolki, które dotąd znajdowały się u góry i u dołu, „przenoszą się na prawą stronę ekranu, aby zmaksymalizować przestrzeń pionową i ułatwić sięganie do nich prawym kciukiem” (1:18).² Bok mieści pasek kart, paski narzędzi, kontrolki nawigacyjne w rodzaju Back, pasek stanu oraz Dynamic Island, „która rozszerza się pionowo w miarę napływania Live Activities” (1:48).² Na ekranie wewnętrznym paski pozostają pionowe w orientacji poziomej i wracają do poziomu w orientacji pionowej — to „jedyna pozycja, w której zachowaliśmy paski poziome” (5:27), ponieważ „przestrzeni pionowej na treść aplikacji jest pod dostatkiem” (5:32).² W Split View „gdy aplikacja znajduje się po lewej stronie, kontrolki również przenoszą się na lewą krawędź ekranu” (3:11).² Pasek jest przy tym wyrównany do sprzętu, więc „w językach pisanych od prawej do lewej pozostaje po tej samej stronie urządzenia” (4:21).⁴

Kadr z transmisji wydarzenia Apple z 9 września 2026, godzina 10:59 czasu pacyficznego: urządzenie w połowie złożone, ekranem wewnętrznym do przodu, z bocznie umieszczonymi kontrolkami przy prawej krawędzi.

O tym, czy dana kontrolka przejdzie w pion, decydują dwie rzeczy. Pierwszą jest jej kontener. Anna z zespołu UI Frameworks: „upewnijmy się, że korzystamy z pasków dostarczanych przez kontenery nawigacyjne, takie jak TabView czy NavigationStack” (2:19), ponieważ treść pochodząca z własnych instancji UIToolbar, UINavigationBar czy UITabBar „nie zostanie uwzględniona” (2:58).⁴ W widokach podzielonych „uczestniczy wyłącznie kolumna szczegółów” (3:43), a inspektory „nie otrzymują własnego” paska (3:53).⁴ Drugą rzeczą jest zawartość samego elementu. Paski pionowe mają „elastyczną wysokość elementu i stałą szerokość” (6:10), co „czyni je lepiej dopasowanymi do reprezentacji elementów złożonych wyłącznie z symbolu” (6:13).⁴ Dlatego „elementy z ikoną, takie jak przyciski back i share, zmieniają oś na pionową. Elementy wyłącznie tekstowe, takie jak przycisk edit, nadal pozostają na osi poziomej” (7:06).⁴ Wersja Vince’a jest tą projektancką: „Elementy paska narzędzi zbyt szerokie na miejsce po prawej stronie, na przykład przycisk tekstowy albo kontrolka segmentowa, powinny na iPhonie Duo zostać w pasku nawigacji” (6:22).²

Reguła kolejności jest krótka. „Górę należy zarezerwować dla głównych kontrolek nawigacyjnych, takich jak back czy close, a zaraz za nimi umieścić wyróżnione akcje w rodzaju done” (4:47).⁴ W SwiftUI własny Back albo Close korzysta z rozmieszczenia cancellationAction (5:02), a wyróżniona akcja z topBarPinnedTrailing (5:24); w UIKit jest to element leading z leftItemSupplementsBackButton pozostawionym na domyślnej wartości false (5:06) oraz pinnedTrailingGroup dla wyróżnionej akcji (5:27).⁴ Cała reszta zachowuje pierwotne pogrupowanie, przy czym „pionowy element odstępu wizualnie oddziela rozmieszczenia górne od dolnych” (5:34).⁴

Reguły z Tech Talku o paskach, dotyczące pojedynczych elementów, każda ze swoją wskazówką:⁴

• Test dla własnego elementu: „czy jedynie wzmacnia on symbol, czy też niesie samodzielną informację?” (9:36)
• Liczba powinna trafić do plakietki, dzięki czemu element złożony z tekstu i symbolu staje się elementem wyłącznie symbolicznym, który „czuje się jak u siebie w pionowym pasku” (9:23); z kolei „przycisk koszyka pokazujący kwotę” zostaje w poziomie (9:52).
• Element przełączający się między symbolem a tekstem, taki jak Edit, zostaje w poziomie; systemowy przycisk Edit już tak działa, a własny przyjmuje wyłącznie poziome AxisBehavior (8:11, 8:32).
• Widok własny lub złożony domyślnie zostaje w poziomie (8:40); jeśli jednak „obsługuje reprezentację pionową” (8:48), zachowanie osi z preferencją pionu wpuszcza go do paska (8:54).
• Każdemu elementowi trzeba nadać tytuł, nawet gdy wyświetla symbol, ponieważ „system korzysta z niego zawsze, gdy element trafia do menu przepełnienia albo do formy rozwiniętej” (7:44).
• Paski akcesoriów klawiatury „powinny pozostać przypięte do klawiatury, zamiast przenosić się na oś pionową” (10:00).
• Widoki własne odczytują właściwość środowiskową toolbarVerticalEdge, a w UIKit odpowiedni trait, aby ustalić, czy pionowy pasek jest obecny (10:35).

Przepełnienie to miejsce, w którym wyrażają się preferencje projektowe, a Tech Talk podaje pięć reguł:⁴

• „Domyślnie elementy przechodzą do przepełnienia od dołu do góry” (13:23); każdy element może mieć wysoki, niski albo własny priorytet widoczności, przydzielany najpierw „grupami” (13:36), a następnie wewnątrz grupy. API priorytetów i przepełnienia to nowości w paskach narzędzi z WWDC26, omówione w tekście o SwiftUI w iOS 27 na tej stronie; w 13:49 Tech Talk odsyła do sesji Apple z WWDC26 o nowościach w SwiftUI.
• Warto zdecydować, co kompresuje się jako pierwsze: w widokach nastawionych na nawigację „najpierw kompresuje się pasek narzędzi, dzięki czemu główne cele pozostają dostępne” (12:07) i to jest ustawienie domyślne; w widokach zadaniowych „najpierw kompresuje się pasek kart, aby zachować często używane akcje” (12:18), co ustawia się przez toolbarCompressionBehavior (12:22).
• Własne menu przepełnienia aplikacji należy scalić z systemowym, używając ToolbarOverflowMenu w SwiftUI albo additionalOverflowItems w UIKit (12:36, 12:43), a wielokropek zarezerwować wyłącznie dla przepełnienia (12:53).
• „Często używane akcje, takie jak Compose w Mail czy New Note w Notes, powinny należeć do tych, które przechodzą do przepełnienia najpóźniej” (13:59).
• Elementy z plakietką „powinny pozostawać widoczne dłużej, aby zachować czytelność na pierwszy rzut oka” (14:11).

Pionowe paski nie są obowiązkowe. Jednostronicowy układ z ciężarem u dołu, taki jak Calculator, albo arkusz z jednym tylko elementem paska narzędzi w rodzaju Close, może wyłączyć pasek przez toolbarVerticalBehavior lub preferredVerticalBarBehavior (14:28, 14:37, 14:47).⁴

Wyśrodkowane albo odsunięte

Gdy pasek znajduje się z jednej strony, „wiele warstw staje się teraz niesymetrycznych” (6:33).² Vince podaje trzy położenia. Większość treści zostaje odsunięta, żeby nie schować się za kontrolkami, a „jeśli aplikacja wyrównuje się do poziomych wcięć bezpiecznego obszaru, odsunięcie dzieje się automatycznie” (6:58).² Część interfejsu nadal centruje się względem całego ekranu, bez odsunięcia, co „dobrze sprawdza się w immersyjnych, mocno wizualnych interfejsach, które się nie przewijają — o ile mamy pewność, że kontrolki po prawej nie zasłonią elementów interaktywnych” (7:10).² Oba podejścia da się też połączyć: „obraz tła albo nagłówek na pełną szerokość z przewijaną treścią pierwszego planu, która jest wcięta” (7:22), pod warunkiem że „każdy element interaktywny mieści się w tym przewijanym obszarze, więc nic nie zostaje zasłonięte” (7:28).² Uwaga przewodnika o bezpiecznym obszarze dorzuca przypadek Split View: przeciwległa krawędź może nieść kontrolki drugiej aplikacji, więc bezpieczny obszar ma znaczenie po obu stronach.¹

Zagięcie: przemieszczenie

Kadr z transmisji wydarzenia Apple z 9 września 2026, godzina 11:08 czasu pacyficznego: warstwy ekranu. Przy częściowym złożeniu krzywizna biegnąca przez środek to „folding region” z przewodnika.

Maria, Human Interface Designer w zespole systemu projektowego Apple, zaczyna od zasady: „Świetne projektowanie dla iPhone’a Duo opiera się na wiedzy o tym, kiedy należy się dostosować” (2:25).³ Wiele interfejsów „potrafi naturalnie opływać reserved regions” (2:30), a reszta korzysta z przemieszczenia, „które dostosowuje ramkę istniejących elementów w zależności od dostępnej przestrzeni, tak aby ważne treści pozostały widoczne, w zasięgu ręki i niezasłonięte, nawet gdy urządzenie jest częściowo złożone” (2:39).³ Wzorzec ma swój zasięg, „od pojedynczego przycisku po cały kontener albo większe fragmenty układu” (3:03), i towarzyszą mu dwie reguły: „Jeśli element potrafi dostosować się samodzielnie, przesuńmy go osobno. A gdy elementy działają razem, przesuwajmy je razem, aby zachować ich wzajemną relację” (3:17), oraz „miejmy na uwadze nadmiar ruchu” (3:26), ponieważ „przesunięcie elementu daleko od jego źródła osłabia ich relację wizualną” (3:29).³ Jej przykładem jest menu kontekstowe nad wybranym zdjęciem: zamiast centrować menu w obszarze trailing, „oba elementy przesuwają się razem i wyrównują wokół zagięcia” (3:39).³

Wyjątek jest tym, na którym projektanci oprą się najczęściej: „Treści przewijane w sposób ciągły, takie jak artykuły, kanały, dokumenty i listy, nie przemieszczają się. Te doświadczenia dostosowują się już poprzez przewijanie, więc przenoszenie ich między dostępnymi obszarami może przerwać ciągłość” (3:46).³ Vince mówi to samo z drugiej strony: system wypycha elementy interaktywne poza krzywiznę, bo „w przyciski trudno trafić, gdy lądują dokładnie w zagięciu” (9:28); zachowanie to jest wbudowane w „arkusze, alerty, menu, przyciski paska narzędzi i nie tylko” (9:40), a „treść przewijana nie musi unikać tego obszaru” (9:57).²

Orientacja zagięcia wyznacza obszary: w pozycji książki biegnie ono pionowo, a obszarami są lewa i prawa strona; na stole albo w orientacji pionowej biegnie poziomo, a obszarami są góra i dół.²³ To, dokąd trafia przemieszczony element, zależy od pozycji, a najbardziej przydatne są uzasadnienia Marii. W pozycji książki „elementy takie jak alerty przenoszą się na stronę trailing. Dzięki temu znajdują się bliżej miejsca, w którym pojawią się, gdy urządzenie zostanie zamknięte, a doświadczenie będzie kontynuowane na ekranie zewnętrznym” (4:09).³ Przy oparciu na stole „górny obszar dobrze sprawdza się dla treści, którym służy widoczność z dystansu” (4:29), a „dolny obszar dobrze sprawdza się dla kontrolek interaktywnych” (4:39), gdzie „elementy do dotknięcia, takie jak sterowanie odtwarzaniem, mogą się tu przenieść, zapewniając stabilniejszą powierzchnię dla dotyku” (4:43).³ Tech Talk o zasadach mówi to samo: w orientacji pionowej, przy częściowym złożeniu, „elementy interaktywne przenoszą się do dolnej połowy ekranu, co ułatwia sięganie do nich, a jednocześnie pozwala urządzeniu stabilnie leżeć na powierzchni” (2:33).² Gdy pasowałoby kilka obszarów, warto zachować kontekst: pole wyszukiwania „korzysta z dodatkowej przestrzeni” (5:00), gdy urządzenie jest otwarte, a w miarę składania jego „szerokość i położenie dostosowują się tak, aby pozostać nad przeszukiwanym widokiem” (5:04).³

Większość tej pracy wykonuje system. „Arkusze akcji, alerty, menu i popovery to lekkie doświadczenia kontekstowe, które mogą pojawić się nad reserved region” (5:23), a system „automatycznie zmienia położenie komponentów wokół reserved region” (5:34).³ Widok podzielony „utrzymuje obie kolumny widoczne, dostosowując ich szerokość i ustawiając je w równym podziale 50/50” (5:40).³ Siatka to przypadek, za który odpowiada się samodzielnie: w projekcie Fitness autorstwa Marii „mogę zachować zewnętrzne marginesy, jednocześnie zwiększając odstępy wokół zawiasu, dzięki czemu każdy kontener pozostaje w swoim obszarze” (5:56).³ Jej podsumowanie wszystkich przykładów jest zarazem briefem projektowym: „przesuwamy, skalujemy albo reorganizujemy to, co już tam jest. Utrzymujmy dostępność treści, funkcji i układów, aby ludzie mieli dostęp do pełnego doświadczenia niezależnie od tego, jak akurat używają iPhone’a Duo” (6:04).³

Reserved regions, czyli mechanika pod przemieszczeniem

Maria wprowadza to pojęcie w Tech Talku o układach adaptacyjnych: „Nowe cechy sprzętu również współtworzą dostępną przestrzeń. Należą do nich zawias oraz dwie kamery rozmieszczone na ekranie zewnętrznym i wewnętrznym. Nazywamy je reserved regions” (0:37), i radzi traktować je „dokładnie tak jak wszystkie inne obszary, do których układ już się dostosowuje” (0:53), a jej przykładem są kontrolki okna w iPadOS.³ Są trzy takie obszary: kamera zewnętrzna, kamera wewnętrzna w czasie, gdy jest aktywna, oraz zagięcie (1:00, 1:18, 1:32).³ Tekst dla programistów przytacza definicje każdego z nich z przewodnika i odnotowuje moje sprawdzenie, że przewodnik nie linkuje żadnej dokumentacji tych API, dlatego ta część pozostaje przy samej mechanice.¹ Harry, inżynier z zespołu UI Frameworks, opisuje API. „W SwiftUI reserved regions odpytuje się przy użyciu GeometryProxy pochodzącego z GeometryReadera albo z modyfikatora onGeometryChange. Nowa metoda reservedRegion na geometry proxy pozwala pobrać obszary dostępne w danym widoku.” (6:38) W UIKit „korzysta się z metody reservedRegion dostępnej na UIView” (7:03), a „właściwość frame danego reserved region można odpytać i uwzględnić we własnym układzie” (7:07).³

Rodzaje są dwa. Zagięcie „opiera się na reserved region typu division, ponieważ dzieli większy obszar na kilka mniejszych” (6:55), i „jest aktywne wyłącznie wtedy, gdy ktoś złożył urządzenie. Po rozłożeniu na płasko pozostaje nieaktywne i ma zerową szerokość” (7:26).³ Kamera to obszar typu occlusion: takie obszary „nie dzielą powierzchni, lecz ją przesłaniają” (7:54), a sam obszar „jest aktywny, gdy kamera jest aktywna, i nieaktywny, gdy kamera jest nieaktywna” (8:12).³ Obszary nieaktywne można odpytać opcją includeInactive, a powód, dla którego Harry każe na nie spojrzeć, jest decyzją projektową: „w układach siatkowych można preferować parzystą liczbę kolumn, gdy obecny jest obszar typu division, niezależnie od jego stanu aktywności” (7:41).³ Przewodnik powtarza to jako regułę.¹ O godzinie 16:15 czasu pacyficznego w dniu keynote’u przewodnik nie linkował żadnej strony dokumentacji tych API, a strona dla programistów Apple datuje betę Xcode 27.1 na „później w tym miesiącu”.¹⁵

Arrangementy: split albo overlay

Kadr z transmisji wydarzenia Apple z 9 września 2026, godzina 11:00 czasu pacyficznego: ekran wewnętrzny, który Apple określa jako o 80 procent większy — płótno, dla którego powstały arrangementy.

Definicja Harry’ego: „Pomiędzy kontenerami nawigacyjnymi a kontenerami treści znajduje się kontener układu. Takie kontenery układu rozmieszczają dwa widoki według zestawu reguł. Nazywamy je arrangementami” (9:20).³ Reguły przyjmują dane wejściowe: „poziomą i pionową klasę rozmiaru widoku, proporcje szerokości do wysokości widoku oraz informację o tym, czy występują aktywne obszary typu division” (10:37), a wytwarzają wyjścia: „czy w ogóle powinienem pokazać ten widok” (10:52) oraz, jeśli tak, „jaka jest jego ramka” (10:54).³ Następnie data: „w iOS 27.1 można używać arrangementów dostarczanych przez system we własnych aplikacjach” (11:02).³

W SwiftUI ArrangementView przyjmuje widok podstawowy i pomocniczy (11:25), a styl ustawia się przez arrangementViewStyle (11:57); w UIKit UIArrangementViewController przyjmuje podstawowy i pomocniczy kontroler widoku (11:39).³ Styl split, czyli domyślny, „dzieli poziomo, gdy widok jest szerszy niż wyższy” (12:13), a pionowo, gdy jest wyższy; da się go też ograniczyć do jednej osi, a jeśli nie może podzielić widoku na swojej osi głównej, „decyduje się pokazać tylko jeden widok” (12:49).³ Styl overlay „woli umieszczać treści jedna nad drugą lub pod drugą” (13:31), a gdy urządzenie się składa, „woli ustawić widok podstawowy i pomocniczy obok siebie” (13:51), co widok może wykryć poprzez właściwość środowiskową overlayArrangementZIndex i przełączyć się między formą zwiniętą a rozwiniętą (14:01).³

Wybór między nimi to najklarowniejsza rada z tego Tech Talku, a przewodnik ją przejmuje. „Jeśli w częściach aplikacji już realizuje się układ przypominający split przy użyciu komponentów takich jak HStack czy VStack, warto rozważyć split arrangement. Jeśli w częściach aplikacji już realizuje się układ przypominający overlay przy użyciu komponentów takich jak ZStack, warto rozważyć overlay arrangement” (14:44).³ Bez istniejącego wzorca overlay stosuje się wtedy, „gdy między widokami zachodzi wyraźna relacja pierwszego planu i tła” (15:10), jak kontrolki nad czytelną treścią w Accessibility Reader, a split wtedy, „gdy jest to raczej relacja głównego widoku i szczegółów” (15:32), jak podcast i jego transkrypcja, gdzie „ważne jest, by żadne z nich nigdy nie zostało zasłonięte” (15:43).³ Dwa ograniczenia — kontenery nawigacyjne wokół arrangementu, a nie w jego wnętrzu, oraz brak arrangementu wewnątrz List czy ScrollView — znajdują się w Tech Talku w 16:15 i 16:26; przewodnik podaje jedynie pierwsze z nich, w zdaniu cytowanym w tekście dla programistów.¹³

Ekran wewnętrzny: trzy uczciwe układy

„Nie chodzi o zwyczajnie rozciągniętą aplikację z iPhone’a” (7:39).² Vince proponuje trzy formy. Widok podzielony, który pokazuje „kilka poziomów hierarchii aplikacji jednocześnie” (7:46), pod warunkiem że hierarchia ta „nie zmienia się między ekranem zewnętrznym a wewnętrznym” (7:51), ponieważ ludzie „mogą często otwierać i zamykać urządzenie w trakcie korzystania z aplikacji, więc musi ona być przewidywalna i spójna w środku i na zewnątrz” (7:59).² Przepływ na wzór Music, w którym „układ ułożony pionowo” (8:15) staje się „układem dwukolumnowym, gdy pojawia się więcej przestrzeni poziomej” (8:18).² Albo pasek kart pokazany „jako pasek boczny na ekranie wewnętrznym” (8:26), co „najlepiej sprawdza się w aplikacjach o dużej gęstości informacji, jak w tym przykładzie z Health” (8:33).² Przykład Mail z przewodnika to przypadek widoku podzielonego: po złożeniu lista albo wiadomość, po rozłożeniu jedno i drugie obok siebie.¹

Arkusze mają własne reguły. Na ekranie zewnętrznym „kontrolki arkusza również przenoszą się na bok” (8:46), co można wyłączyć dla arkusza z jednym przyciskiem paska narzędzi; wtedy „arkusze zatrzymują się tuż przed przednią kamerą, a pasek stanu sam zmienia swoje położenie” (9:04).² Na ekranie wewnętrznym arkusze domyślnie „korzystają ze standardowych pasków poziomych” (9:13), a przy częściowym złożeniu urządzenia „przesuwają się w bok, aby nie spoczywać w zagięciu” (9:20).² Tech Talk o paskach dorzuca wyjątek dotyczący rozmieszczenia: arkusze na ekranie wewnętrznym są „domyślnie wyśrodkowane, a ich elementy pozostają poziome” (4:03), ale przy użyciu API preferredPlacement „arkusze umieszczone po lewej stronie pozostają bez pionowego paska, a te po prawej go otrzymują” (4:11).⁴

Lista kontrolna

Tech Talk o paskach i Tech Talk o układach adaptacyjnych kończą się listą kontrolną, więc poniżej znajdują się obie połączone w jedną. Lista zamykająca Tech Talk o paskach (15:10): budować na najnowszych SDK, ponieważ pionowe paski włączają się w zależności od SDK (2:06); sprawdzić paski i ich kolejność (4:41) oraz zaktualizować własne elementy tak, aby dało się je ułożyć pionowo; a także przypisać priorytety widoczności, „żeby system mógł się dostosować” (15:26).⁴ Następnie, z Tech Talku o układach adaptacyjnych (16:40): „zacznijmy od przejrzenia wyśrodkowanych układów w aplikacji. Zastanówmy się, czy da się z nich zrobić układ dwukolumnowy albo jaki wzorzec przemieszczenia ma sens w danym zastosowaniu”; korzystać ze standardowych kontenerów i sposobów prezentacji, aby otrzymać zachowanie za darmo (16:49); sięgnąć po ArrangementView przy własnych układach typu split lub overlay; oraz „wskazać w swoich widokach ręcznie rozmieszczone kontrolki o najwyższym priorytecie i rozważyć zastosowanie API ReservedRegions, aby tam, gdzie to potrzebne, wdrożyć własne przemieszczenie” (17:06).³

Co zamierzam z tym zrobić

Trzy z moich aplikacji to aplikacje na iPhone’a i przewodnik porządkuje je bardzo czytelnie. Ten podział to moja interpretacja, nie stanowisko Apple.

• Get Bananas to lista. Listy się nie przemieszczają, pasek kart i pasek narzędzi same przeniosą się na bok, o ile nadal będę korzystał z kontenerów systemowych, a jedyną decyzją projektową jest priorytet widoczności: akcja dodania pozycji jest moim odpowiednikiem Compose, powinna więc trafić do przepełnienia jako ostatnia.
• Reps zapisuje każdą serię jako wiersz z ciężarem, liczbą powtórzeń i akcją zapisu, a w trakcie treningu układa je w siatkę — czyli dokładnie przykład Fitness od Marii. Decyzja: w pozycji książki trzykolumnowy wiersz umieszcza środkową kolumnę na zawiasie, więc siatka przechodzi na dwie sparowane kolumny. W pozycji stołowej akcja zapisu ląduje w dolnej połowie. Kompromisem jest jedno dotknięcie więcej na serię w zamian za cel, który nigdy nie trafia w zagięcie, gdzie — jak mówi Vince — „w przyciski trudno trafić” (9:28).² Minutnik przerwy zostaje u góry, w obszarze, który zdaniem Marii dobrze sprawdza się dla „treści, którym służy widoczność z dystansu” (4:29).³
• Return rysuje wykresy zdrowotne, a te są treścią przewijaną. Tam, gdzie dziś wykres i jego selektor zakresu stoją w pionowym stosie, reguła Harry’ego odwzorowuje ten stos na split arrangement, który utrzymuje oba widoczne, gdy urządzenie się składa; sam wykres nie powinien się nigdy przemieszczać.

Najważniejsze wnioski

Dla projektantów: - Dwie klasy rozmiaru zamiast pozycji: compact width na zewnątrz, regular width w środku.¹ Jedyny opcjonalny dodatek sugerowany przez projektantów Apple to układ stołowy zachowujący te same kontrolki.² - Ikony idą w pion, tekst zostaje w poziomie; górę bocznego paska zajmuje Back albo Close, a potem Done; częste akcje i elementy z plakietką trafiają do przepełnienia na końcu.⁴ - Treści przewijane nigdy się nie przemieszczają; alerty, menu, arkusze i kontrolki owszem, a miejsce docelowe wynika z przeznaczenia: alerty na stronę trailing w pozycji książki i do górnego obszaru na stole, kontrolki dotykowe do dolnej połowy.²³

Dla inżynierów projektowania: - Zagięcie to obszar typu division, aktywny wyłącznie po złożeniu urządzenia i o zerowej szerokości na płasko; kamera wewnętrzna to obszar typu occlusion, aktywny tylko wtedy, gdy działa kamera; oba da się odpytać z GeometryProxy albo z UIView.³ - Arrangementy pojawiają się wraz z iOS 27.1: stos staje się splitem, ZStack staje się overlayem, a kontenery nawigacyjne pozostają na zewnątrz.³ - Należy korzystać z systemowych pasków pochodzących z kontenerów nawigacyjnych, inaczej układ pionowy nigdy nie powstanie.⁴

Często zadawane pytania

Czy potrzebny jest osobny układ na każdą pozycję?

Nie. Apple zaleca projektowanie pod dwie klasy rozmiaru — compact width na ekranie zewnętrznym i regular width na wewnętrznym — oraz unikanie stałych szerokości, punktów granicznych i miar powiązanych z konkretnym ekranem.¹² Jedyny opcjonalny dodatek, wskazany w Tech Talku o projektowaniu, to układ dla pozycji stołowej z tymi samymi kontrolkami i tą samą hierarchią.²

Które kontrolki pozostają na iPhonie Duo poziome?

Elementy wyłącznie tekstowe, elementy zbyt szerokie na boczny pasek, takie jak kontrolki segmentowe, elementy przełączające się między symbolem a tekstem, takie jak Edit, paski akcesoriów klawiatury, a także — jeśli taki będzie wybór — cały pasek w jednostronicowej aplikacji z ciężarem u dołu albo w arkuszu z jednym elementem paska narzędzi.²⁴

Czym jest przemieszczenie?

To wzorzec Apple polegający na przesuwaniu, skalowaniu albo reorganizowaniu istniejących elementów, tak aby pozostały widoczne i w zasięgu ręki, gdy urządzenie jest częściowo złożone. Alerty, menu, popovery, arkusze i przyciski paska narzędzi otrzymują je od systemu; treści przewijane są z niego wyłączone.²³

Kiedy pojawią się arrangement views oraz API reserved region?

Tech Talk o układach adaptacyjnych podaje, że arrangementy dostarczane przez system można stosować we własnych aplikacjach w iOS 27.1, a strona dla programistów Apple umieszcza betę Xcode 27.1 w dalszej części września. Przewodnik projektowy nie linkuje jeszcze dokumentacji do żadnego z tych API.¹³⁵

Czy treści przewijane muszą unikać zagięcia?

Nie. Zarówno Tech Talk o projektowaniu, jak i ten o układach adaptacyjnych wyłączają treści przewijane; dostosowują się one już poprzez samo przewijanie.²³

Źródła