Macierz platform Apple: które cele zasługują na którą aplikację

Apple oferuje sześć konsumenckich platform obliczeniowych, na które programista może kierować pojedynczy kod źródłowy w Swift: iPhone, iPad, Mac, Watch, Vision i TV. SwiftUI wraz z zestawem narzędzi iOS 26 sprawiają, że dodanie któregokolwiek z nich to operacja zaznaczenia pola w Xcode. Owo zaznaczenie pola jest pułapką. Każdy dodatkowy cel jest zobowiązaniem, a nie funkcją: każdy z nich rozszerza powierzchnię projektowania, testowania, dostępności, modelu wykonawczego i bieżącego utrzymania. Właściwa liczba celów dla aplikacji to mniej, niż na to pozwala framework.

Aplikacje w klastrze działają w różnych konfiguracjach. Return jest dostępne na sześciu platformach (iPhone, iPad, Mac, Watch, Vision, TV). Get Bananas jest dostępne na czterech (iPhone, iPad, Mac, Watch). Reps i Water są w fazie przedpremierowej z wieloma skompilowanymi celami, które aplikacje zawężą przed premierą. Ace Citizenship i Tappy Color są dostępne wyłącznie na iPhone’ie. Ten sam programista, ten sam zestaw narzędzi, sześć różnych decyzji platformowych. Decyzje opierają się na regułach; reguły zasługują na wspólną mapę.

Każda platforma zasługuje na włączenie poprzez konkretną wartość dla użytkownika, którą rzeczywiście dodaje, a nie poprzez to, że “się kompiluje”. Macierz, która przetrwa wydanie, to to, co pozostaje, gdy każdy cel albo się uzasadnia, albo zostaje wycięty.

TL;DR

• Sześć platform, sześć różnych zobowiązań: iPhone (domyślny), iPad (adaptacja klas rozmiaru), Mac (idiomy okien/menu/klawiatury), Watch (kontrakt wykonawczy), Vision (przestrzenny model mentalny), TV (silnik fokusu).
• Każdy dodatkowy cel zwiększa powierzchnię testową, pracę projektową, dostępność i bieżącą koordynację wydań. Pole wyboru “dodaj platformę” w Xcode ukrywa ten koszt.
• Właściwe testy to testy wartości dla użytkownika, a nie testy techniczne: czy użytkownik rzeczywiście odnosi korzyść z uruchamiania tej aplikacji na tej platformie? Jeśli odpowiedź brzmi “ona też tam działa”, należy ją wyciąć.
• Większość aplikacji powinna trafiać na jedną do trzech platform. Cztery do sześciu jest nietypowe i zasługuje na miejsce tylko wtedy, gdy każda platforma rzeczywiście dodaje wartość dla użytkownika, której inne nie mogą dostarczyć.

iPhone jest domyślny

Każda aplikacja Apple zaczyna się na iPhonie albo wcale się nie zaczyna. iPhone ma największą bazę zainstalowaną, najbardziej dopracowaną powierzchnię dostępności, najsilniejszą ścieżkę dystrybucji przez App Store oraz kanoniczny język projektowania SwiftUI. Każda aplikacja klastrowa, którą wydałem, działa na iPhonie. Żadna nie została wydana z projektem zorientowanym najpierw na coś innego niż iPhone.

Test wartości dla użytkownika dla iPhone’a: czy użytkownik otworzyłby tę aplikację na telefonie? W przypadku niemal każdej kategorii konsumenckiej — tak. Aplikacje zdrowotne i fitness żyją na telefonie. Narzędzia produktywności żyją na telefonie. Gry żyją na telefonie. Narzędzia komunikacyjne żyją na telefonie. Domyślny jest iPhone, ponieważ telefon jest tam, gdzie znajduje się użytkownik.

Wyjątkiem są narzędzia deweloperskie (Xcode, Terminal) oraz narzędzia kreatywne, które potrzebują przestrzeni roboczej (Final Cut, Logic). Te zaczynają na Macu i zasługują na towarzysza w postaci iPhone’a tylko wtedy, gdy istnieje wyraźny handoff (tętno z Apple Watch podczas treningu, dla którego telefon pokazuje wykres, Camera Continuity). W przypadku oprogramowania konsumenckiego priorytet iPhone’a nie podlega dyskusji.

iPad to nie iPhone z większą liczbą pikseli

Uniwersalne pliki binarne i klasy rozmiaru umożliwiły wydanie aplikacji UIKit dla iPhone’a na iPadzie z punktami granicznymi klas rozmiaru. SwiftUI uczynił to samo łatwiejszym dzięki @Environment(\.horizontalSizeClass) i NavigationSplitView.¹ Koszt techniczny “wydania na iPada” jest niski. Koszt produktowy to pytanie, czy aplikacja rzeczywiście zasługuje na większą powierzchnię iPada.

Trzy sygnały na “tak” dla iPada:

Aplikacja czyta lub tworzy treści, dla których użytkownik chce więcej ekranu. Aplikacje do czytania (Książki, wiadomości, komiksy, długie dokumenty). Aplikacje do rysowania/malowania (Procreate). Sporządzanie notatek za pomocą Apple Pencil (Notability, GoodNotes). Get Bananas zasługuje na miejsce na iPadzie, ponieważ lista zakupów z sekcjami jest bardziej użyteczna na szerszej powierzchni niż na wąskiej; projekt na iPada adaptuje tę samą listę sekcji do większego obszaru.

Aplikacja ma wartość handoff z iPhonem lub Makiem. Apple Notes, Reminders i Mail wszystkie zasługują na miejsce na iPadzie, ponieważ użytkownik oczekuje ciągłości. Historia medytacji Return na iPadzie zasługuje na miejsce z tego samego powodu: użytkownik zaczyna na iPhonie, zerka na iPada, gdy działa minutnik.

Aplikacja ma natywną dla iPada możliwość wprowadzania danych. Apple Pencil do szkicowania/pisania ręcznego. Gesty wielopalcowe na większej powierzchni. Przepływy pracy Stage Manager, które korzystają z układu opartego na kafelkach. Jeśli dana możliwość nie istnieje na iPhonie, cel iPad zasługuje na swoje miejsce.

Sygnały na “nie” dla iPada:

Treść jednokolumnowa bez dodatkowej wartości w skali. Główny widok minutnika do medytacji to liczba i przycisk. iPad powiększa oba; to nie jest funkcja. Tracker nawodnienia z szybkim logowaniem działa tak samo; szerszy ekran nie zmienia tego, co użytkownik robi podczas pięciosekundowej sesji logowania.

Aplikacje, które zależą od sprzętu specyficznego dla iPhone’a (Dynamic Island, niektóre formaty kamery wyłącznie dla wersji Pro, ergonomia uchwytu w kształcie iPhone’a). Te założenia projektowe źle się przekładają; albo trzeba przebudować projekt, albo pominąć cel.

Aplikacje, w których użytkownik ma już lepsze miejsce docelowe na Macu. Edytor kodu na iPadzie bez obsługi klawiatury jest okaleczoną wersją aplikacji na Maca. Pomiń cel, chyba że projekt zasługuje na miejsce dzięki specyficznemu dla iPada modelowi wprowadzania danych.

Mac to idiomy okna, paska menu i klawiatury

Aplikacja SwiftUI wydana na Maca przez natywny cel macOS lub “Designed for iPad” (Mac Catalyst to ścieżka odpowiadająca UIKit, która przenosi kod UIKit na Maca) działa na macOS bez tworzenia prawdziwej aplikacji dla Maca.² Prawdziwa aplikacja dla Maca honoruje semantykę zmiany rozmiaru okna, pasek menu (modyfikator Scene .commands { } z konstruktorami CommandMenu i CommandGroup w SwiftUI), skróty klawiszowe, narzędzie do wyboru plików macOS, przeciąganie i upuszczanie z Finderem oraz natywne dla Maca udostępnianie.³ Pominięcie któregokolwiek z nich tworzy doświadczenie typu aplikacja-na-iPada-w-oknie, które użytkownicy Maca zauważają i oceniają.

Sygnały na “tak” dla Maca:

Użytkownik spędza czas w aplikacji i odniósłby korzyść, gdyby było to prawdziwe okno na pulpicie. Get Bananas na Macu zasługuje na miejsce, ponieważ użytkownicy edytujący długą listę zakupów przy biurku korzystają z prawdziwego okna z nawigacją klawiaturową. Return na Macu zasługuje na miejsce, ponieważ użytkownicy, którzy chcą uruchamiać minutnik medytacyjny na swojej maszynie roboczej, korzystają z prawdziwej aplikacji w pasku menu lub okna przypiętego do określonego rogu.

Przepływy pracy z wieloma oknami lub wieloma dokumentami. Edytor kodu z podzielonymi panelami. Edytor zdjęć z obrazami referencyjnymi obok siebie. Arkusz kalkulacyjny. Żaden z nich nie przetrwa we właściwej formie na iPadzie ani iPhonie; Mac jest właściwą platformą.

Interakcja sterowana klawiaturą. Aplikacja SwiftUI na Macu, która ignoruje klawiaturę, jest aplikacją na Maca tylko z nazwy. Cmd+N dla nowego, Cmd+W dla zamknięcia, Tab dla przechodzenia fokusem, klawisze strzałek dla wyboru. Koszt jest na aplikację: każdy cel Mac potrzebuje przemyślanej powierzchni klawiaturowej.

Sygnały na “nie” dla Maca:

Aplikacja jest małym narzędziem do pojedynczego zadania, które nie korzysta z okna. Poranny minutnik, który użytkownik uruchamia raz dziennie na pięć minut, nie potrzebuje celu Mac. Użytkownik może uruchomić go na iPhonie obok Maca.

Aplikacje, w których interfejs w kształcie iPhone’a fundamentalnie się nie przekłada. Aplikacje aparatu. Aplikacje towarzyszące Apple Watch. Aplikacje, w których model wprowadzania danych jest oparty na dotyku, a odpowiednik klawiatury/myszy byłby gorszy niż dotykanie telefonu.

Zespół nie może zobowiązać się do bieżącej konserwacji specyficznej dla Maca. Wydania dla Maca są analizowane inaczej niż wydania dla iPhone’a. Cykle aktualizacji macOS, podpisywanie dla Gatekeepera, notaryzacja, recenzja App Store specjalnie dla Maca — każdy z nich dodaje pracę cyklu wydawniczego, którą zespół musi uwzględnić w budżecie. Jeśli zespół tego nie uwzględni, należy pominąć cel.

Apple Watch to kontrakt wykonawczy

Watch jest platformą, na której “wyślij na nią” jest aktywnie mylącą instrukcją. Model wykonawczy Watcha, omówiony szczegółowo w Środowisko wykonawcze watchOS to kontrakt, a nie zadanie w tle, fundamentalnie różni się od iOS: nadgarstek opada, system zawiesza aplikację i tylko określone typy sesji (self-care, mindfulness, physical-therapy, alarm dla WKExtendedRuntimeSession, plus workout-processing dla HKWorkoutSession i underwater-depth dla sesji nurkowych) mogą działać po zawieszeniu.⁴ Cel Watch bez historii wykonawczej jest zepsuty przy drugim użyciu.

Sygnały na “tak” dla Watcha:

Aplikacja ma kształt sesji, który model wykonawczy watchOS rozpoznaje. Minutniki medytacyjne (sesja mindfulness). Aplikacje fitness (HKWorkoutSession z trybem działania w tle workout-processing). Inteligentne alarmy (alarm). Aplikacje rehabilitacyjne i wellness (pasujące typy sesji). Return jest dostępne na Watchu, ponieważ medytacja czysto mapuje się na mindfulness; aplikacja na Watcha utrzymuje minutnik działający przez opadnięcie nadgarstka, ponieważ kontrakt wykonawczy na to pozwala.

Użytkownik rzeczywiście chce, aby nadgarstek był powierzchnią wprowadzania danych. Podgląd tętna podczas ćwiczeń. Minutnik, który użytkownik uruchamia bez wyciągania telefonu. Komplikacja, która eksponuje informacje na pierwszy rzut oka. Get Bananas jest dostępne na Watchu jako szybka powierzchnia do sprawdzania listy w połączeniu z kanonicznym sklepem na iPhonie; aplikacja treningowa taka jak Reps zasługuje na cel Watch z tego samego powodu, ponieważ logowanie serii na nadgarstku jest szybsze niż wyławianie telefonu z kieszeni.

Wartość aplikacji towarzyszącej jest realna. Niektóre aplikacje Watch istnieją głównie jako wyświetlacze danych sterowanych z iPhone’a (np. minutnik kulinarny, w którym iPhone uruchamia minutnik, a Watch pokazuje pozostały czas). Te zasługują na miejsce tylko wtedy, gdy synchronizacja między urządzeniami jest zbudowana uczciwie (omówione w Pojedyncze źródło prawdy: SwiftData + MCP + iCloud) i widok Watcha wykonuje prawdziwą pracę wykraczającą poza powielanie.

Sygnały na “nie” dla Watcha:

Aplikacja nie ma typu sesji, do którego mogłaby się odwołać. Aplikacja do czytania na Watchu jest aplikacją Watch tylko z nazwy. Użytkownik nie może czytać książki na nadgarstku; model wykonawczy nie rozszerza sesji. Pomiń.

Zespół nie może zobowiązać się do debugowania specyficznego dla watchOS. Debugowanie Watcha jest wyjątkowo bolesne: zachowanie symulatora odbiega od zachowania prawdziwego urządzenia w sposób, który ujawnia się tylko na prawdziwym Apple Watchu w warunkach opadnięcia nadgarstka. Jeśli zespół nie ma sprzętu i chęci do testowania na nim, cel Watch zostanie wydany jako zepsuty.

Model danych nie pasuje do kopert synchronizacji między urządzeniami. Synchronizacja między urządzeniami z iPhone’a na Watcha to zazwyczaj WatchConnectivity dla stanu na żywo i NSUbiquitousKeyValueStore dla małego utrwalonego stanu (Return używa tego ostatniego do synchronizacji historii sesji; omówione w poście o wydawaniu wieloplatformowym). Magazyn ma limit 1 MB na wszystkie klucze z maksymalną liczbą 1024 kluczy.⁵ Jeśli stan sesji aplikacji nie mieści się w tej kopercie, cel Watch potrzebuje innej architektury synchronizacji, co stanowi prawdziwą inwestycję inżynierską.

Vision to przestrzenny model mentalny

Vision Pro kusi aplikacje, by były wydane jako płaski panel unoszący się w przestrzeni 3D. Ten panel jest oknem SwiftUI, a SwiftUI na visionOS sprawia, że jego wydanie to operacja jednego kliknięcia. Panel jest gorszym iPadem. Prawdziwa wartość platformy pochodzi z przestrzennego modelu mentalnego, omówionego w RealityKit i przestrzenny model mentalny, gdzie treść żyje w pokoju, a nie na panelu.

Sygnały na “tak” dla Vision:

Aplikacja ma treść 3D, która zyskuje dzięki znajdowaniu się w pokoju. Wirtualna rzeźba, wokół której użytkownik może chodzić. Miarka, która kładzie się na prawdziwej ścianie. Trener treningowy, który projektuje wskazówki dotyczące formy na obraz lustrzany ciała użytkownika. Większość aplikacji klastrowych, które pojawiają się na visionOS, robi to przez kompatybilność “Designed for iPad”, a nie przez natywny cel visionOS; ta kompatybilność jest w porządku dla użytkownika, ale nie czyni aplikacji doświadczeniem natywnym dla Vision. Post o przestrzennym modelu mentalnym RealityKit argumentuje, że zasłużenie na platformę oznacza więcej niż uruchamianie się na niej.

Śledzenie dłoni jest właściwym modelem wprowadzania danych. Szczypanie do chwytania, dwuręczne skalowanie, rysowanie w powietrzu. visionOS daje możliwość wprowadzania danych, której nie ma żadna inna platforma; aplikacje, które zasługują na miejsce w visionOS, opierają się na tym.

Aplikacja obsługuje powierzchnie specyficzne dla przestrzeni (odpowiedniki ekranu blokady, immersyjne przestrzenie, ozdoby). Aplikacje produktywności, które po prostu unoszą swój interfejs iPhone’a na Vision, są widocznym hałasem pierwszego dnia użytkownika z urządzeniem. Aplikacje, które sprawiają, że użytkownik wraca, to te, które wykorzystują przestrzenną powierzchnię.

Sygnały na “nie” dla Vision:

Aplikacja jest fundamentalnie w kształcie panelu i wcale nie korzysta z głębi. Aplikacja do sporządzania notatek, aplikacja do czatu, narzędzie ustawień. visionOS je uruchomi; użytkownik nie ma powodu, by używać ich na visionOS zamiast na iPadzie. Pomiń.

Zespół deweloperski nie ma testów specyficznych dla visionOS. visionOS to platforma o najmniejszej bazie zainstalowanej i najbardziej kruchych wzorcach; testowanie celu Vision bez prawdziwego urządzenia jest wyjątkowo trudne, bardziej niż w przypadku watchOS.

Dominują obawy dotyczące prywatności i obecności. Aplikacje ujawniające stan zdrowia. Wrażliwe narzędzia miejsca pracy. Urządzenie visionOS jest dzielone między członków gospodarstwa domowego w sposób, w jaki iPhone nie jest; aplikacja, która eksponuje prywatne informacje, potrzebuje tam innej postawy niż na iPhonie.

Apple TV to silnik fokusu

Aplikacje TV są sterowane silnikiem fokusu pilota Siri Remote: użytkownik przesuwa wyróżnienie fokusu pilotem, naciska, aby wybrać, i nigdy nie widzi interakcji dotykowej. SwiftUI na tvOS obsługuje to przez modyfikator .focusable(...), opakowanie właściwości @FocusState i .focused(...) do wiązania stanu, ale każda aplikacja TV potrzebuje projektu fokusu od podstaw.⁶ Model dotknij i przewiń z iPhone’a się nie przekłada.

Sygnały na “tak” dla TV:

Aplikacja służy do konsumpcji treści z odległości oglądania telewizji. Streaming wideo (Apple TV+, Netflix). Pokazy slajdów ze zdjęciami. Aplikacje gier rodzinnych, które użytkownik kontroluje pilotem. Użytkownik jest na kanapie, ekran jest daleko, wprowadzanie danych jest skąpe — TV jest właściwą platformą.

Aplikacja ma przypadek użycia “odchyl się do tyłu”, którego iPhone nie ma. Filmy treningowe, za którymi użytkownik podąża. Aplikacje kulinarne, do których użytkownik się odwołuje, stojąc przy kuchence. Bajki na dobranoc, których użytkownik słucha podczas snu. Żaden z nich nie jest dobrze obsługiwany przez telefon postawiony na stoliku kawowym.

Model interakcji pasuje do skąpej, sterowanej fokusem nawigacji. Lista elementów, z których użytkownik wybiera po jednym na raz. Siatka opcji. Liniowy przepływ odtwarzania. Wszystko bardziej skomplikowanego niż to — gesty wielodotykowe, drobnoziarniste wprowadzanie tekstu, przeciąganie i upuszczanie — nie działa na tvOS i oznacza, że cel jest zły.

Sygnały na “nie” dla TV:

Aplikacja potrzebuje wprowadzania tekstu. Wprowadzanie tekstu na TV przez pilota jest jednym z najgorszych modeli wprowadzania danych na każdej platformie Apple. Jeśli aplikacja potrzebuje czegoś więcej niż pole wyszukiwania, pomiń TV.

Wartość aplikacji zależy od tego, że ręce użytkownika są wolne do innych zadań. Śledzenie kondycji. Monitorowanie zdrowia. Współpraca w czasie rzeczywistym. TV to ekran, a nie urządzenie noszone.

Koszt utrzymania jest zbyt wysoki w stosunku do bazy zainstalowanej. tvOS ma małą bazę zainstalowaną w stosunku do iOS. Koszt rozwoju jest realny (projekt fokusu, oddzielne testowanie, recenzja App Store dla tvOS). Dla większości aplikacji matematyka nie uzasadnia miejsca. Aplikacja medytacyjna zasługuje na miejsce na Apple TV tylko z prawdziwym trybem “zostaw to na ekranie z niską jasnością, gdy siedzę na kanapie”, który przypadek użycia rzeczywiście wynagradza; bez tego trybu nawet aplikacja, której minutnik czysto mapuje się na wzorzec leżenia w TV, nie zasługuje na rachunek za utrzymanie.

Macierz w praktyce

Rzeczywista macierz każdej aplikacji klastrowej:

Wzorzec: każdy wiersz jest świadomym wycięciem w równym stopniu, jak świadomym dodaniem. Return sięga sześciu platform, ponieważ każda z nich jest uzasadniona przez konkretny test wartości dla użytkownika; aplikacje wyłącznie na iPhone’a tam pozostają, ponieważ nic innego się nie kwalifikuje. Ten sam zestaw narzędzi, różne produkty, różne macierze.

Trzy decyzje architektoniczne, które czynią macierz zrównoważoną

Trzy wzorce, które chronią aplikacje wieloplatformowe przed zapadnięciem się pod własnym ciężarem:

Wspólny rdzeń używa #if os(iOS), #if os(macOS), #if os(watchOS) (i podobnych), aby bramkować powierzchnie specyficzne dla platformy.⁷ Logika domeny rdzeniowej (modele danych, reguły biznesowe, synchronizacja) kompiluje się wszędzie. Interfejs specyficzny dla platformy żyje za warunkami kompilacji. @available(iOS 26.0, macOS 26.0, ...) w SwiftUI obejmuje różnice wersji systemu operacyjnego; powierzchnie, które rzeczywiście rozchodzą się między platformami (pasek menu Maca, który nie ma odpowiednika na iPhonie, komplikacja Watcha, która nie ma odpowiednika na iPadzie), otrzymują własne pliki w grupach specyficznych dla celu za bramami #if os(...).

Synchronizacja między urządzeniami przechodzi przez jeden substrat, wybrany na domenę. NSUbiquitousKeyValueStore dla małego stanu na poziomie sesji między urządzeniami (Return używa tego dla stanu minutnika między urządzeniami). Pliki JSON iCloud Drive dla mostów między procesami (Get Bananas używa tego ze swoim serwerem MCP, omówione w Pojedyncze źródło prawdy). SwiftData dla stanu w procesie. Mieszanie substratów na domenę jest w porządku; używanie dwóch substratów dla tej samej domeny jest trybem awarii, który powoduje dryft.

Każda platforma ma jawne wzorce odmowy udokumentowane na aplikację. “Nie wydamy na TV, dopóki przypadek użycia nie ma trybu odchylenia do tyłu”. “Nie wydamy na Vision, chyba że aplikacja używa RealityKit, a nie panelu”. “Nie wydamy na Watcha bez typu sesji”. Odmowy są decyzjami projektowymi rejestrowanymi na aplikację i konsekwentnie stosowanymi, w duchu O czym odmawiam pisać.

Kiedy dodawanie platform jest błędem

Trzy przypadki, w których łatwiejsza ścieżka jest błędna.

Zespół dodaje cel, ponieważ zestaw narzędzi to ułatwia. Kreator “duplikuj cel” w Xcode sprawia, że dodanie celu Mac lub visionOS jest operacją czterech kliknięć. Te cztery kliknięcia nie obejmują przeglądu projektu, audytu dostępności, tworzenia zrzutów ekranu App Store, bieżącej koordynacji wydań ani testowania na każdej platformie. Cele wydane z kreatora bez tej pracy idącej z nimi są zepsute pierwszego dnia.

Zespół traktuje liczbę celów jako sygnał statusu. “Wydajemy na pięciu platformach Apple” brzmi imponująco w tweecie premierowym. Tweet premierowy nie działa na urządzeniach użytkowników; aplikacje tak. Aplikacja dwuplatformowa, która ma obie zrobione perfekcyjnie, jest lepszym produktem niż aplikacja pięcioplatformowa, która jest rozciągnięta.

Zespół niedoszacowuje bieżącej konserwacji. Każda platforma Apple wydaje główne aktualizacje systemu operacyjnego co roku. Aplikacja pięcioplatformowa ma pięć zestawów notatek do wydania, na które trzeba zareagować, pięć zestawów zmian zachowania do przetestowania, pięć zestawów metadanych App Store do utrzymania w aktualności. Koszt się kumuluje; zespoły, które wydają na wszystkich pięciu bez zdolności do ich utrzymania, produkują wolno rozkładające się produkty na trzech z tych platform.

Co ten wzorzec oznacza dla aplikacji wydawanych na iOS 26+

Trzy wnioski.

1. Włączenie platformy jest decyzją produktową, zanim stanie się decyzją inżynierską. Pole wyboru w Xcode jest stroną inżynierską; test wartości dla użytkownika jest stroną produktową. Bez jasnej odpowiedzi na “czy użytkownik rzeczywiście odnosi korzyść z uruchamiania tej aplikacji na tej platformie” cel zostaje wycięty.

2. Każda platforma niesie konkretne zobowiązania: klasa rozmiaru (iPad), okno/menu/klawiatura (Mac), kontrakt wykonawczy (Watch), model przestrzenny (Vision), silnik fokusu (TV). Pomijanie zobowiązań tworzy aplikację-iPada-na-Macu, aplikację-telefonu-na-Vision, aplikację-iPhone’a-na-Watchu — wszystkie widoczne porażki, które rzeczywiści użytkownicy platformy zauważają.

3. Większość aplikacji powinna trafiać na jedną do trzech platform. Cztery do sześciu jest nietypowe i zasłużone tylko wtedy, gdy każda platforma rzeczywiście dodaje wartość dla użytkownika. Aplikacje klastrowe obejmują od jednej do sześciu; przypadek sześcioplatformowy (Return) jest rzadkim punktem końcowym, a każda dodatkowa platforma była tam oddzielną decyzją produktową z własnym testem wartości dla użytkownika.

Pełny klaster Apple Ecosystem: typowane App Intents dla powierzchni Apple Intelligence; serwery MCP dla powierzchni agenta; pytanie o routing między nimi; Foundation Models dla funkcji LLM na urządzeniu w aplikacji; rozróżnienie środowisko wykonawcze vs narzędzia LLM; synteza trzech powierzchni; wzorzec pojedynczego źródła prawdy; Dwa serwery MCP dla integracji z Xcode; hooks dla rozwoju Apple; Live Activities; kontrakt środowiska wykonawczego watchOS; wnętrzności SwiftUI; przestrzenny model mentalny RealityKit; dyscyplina schematu SwiftData; wzorce Liquid Glass; wieloplatformowe wydawanie; o czym odmawiam pisać. Hub znajduje się w Serii Apple Ecosystem. Aby uzyskać szerszy kontekst iOS-z-agentami-AI, zobacz przewodnik iOS Agent Development.

FAQ

Jak zdecydować, czy dodać cel platformy Apple?

Należy zapytać, czy użytkownik rzeczywiście odnosi korzyść z uruchamiania aplikacji na tej platformie, a nie czy zestaw narzędzi na to pozwala. Pole wyboru w Xcode jest stroną techniczną; test wartości dla użytkownika jest stroną produktową. Każda platforma niesie konkretne zobowiązania (klasa rozmiaru, okno/menu, kontrakt wykonawczy, model przestrzenny, silnik fokusu) i konkretny koszt utrzymania. Jeśli odpowiedź brzmi “ona też tam działa”, właściwą decyzją jest zazwyczaj pominięcie celu.

Czy powinienem wydawać na wszystkie sześć platform Apple?

Zazwyczaj nie. Większość aplikacji korzysta z jednej do trzech platform. Cztery do sześciu jest nietypowe i zasłużone tylko wtedy, gdy każda platforma rzeczywiście dodaje wartość dla użytkownika (Return sięga wszystkich sześciu, ponieważ sesja mindfulness pasuje do Watcha, minutnik pasuje do iPada i Maca jako towarzyszy biurka, visionOS pasuje do trybu immersyjnego, a TV pasuje do kanapowego przypadku użycia “odchyl się do tyłu”). W przypadku większości aplikacji model interakcji tvOS i wymagania przestrzenne visionOS nie pasują, a właściwą decyzją jest pominięcie tych celów.

Jaki jest najczęstszy błąd przy dodawaniu celu iPad?

Traktowanie iPada jako “iPhone’a z większą liczbą pikseli”. Aplikacja SwiftUI dla iPhone’a upuszczona na iPada bez adaptacji klasy rozmiaru tworzy rozciągnięty jednokolumnowy interfejs, który użytkownicy iPada natychmiast oceniają jako półrobotę. Właściwym wzorcem jest odczytanie @Environment(\.horizontalSizeClass), dostosowanie układu do większej powierzchni (dwie kolumny tam, gdzie ma to sens, przez NavigationSplitView, w przeciwnym razie pojedyncza lista z wygodnym odstępem) i rozważenie Apple Pencil oraz możliwości wielopalcowych jako wartości specyficznej dla iPada.

Dlaczego Apple Watch tak bardzo różni się od innych platform?

watchOS nie ma modelu wykonywania w tle iOS. Nadgarstek opada, system zawiesza aplikację i tylko określone typy sesji (self-care, mindfulness, physical-therapy, alarm dla WKExtendedRuntimeSession, plus workout-processing dla HKWorkoutSession) mogą działać po zawieszeniu.⁴ Aplikacje bez czystego typu sesji tworzą doświadczenia zepsute przy drugim użyciu. Post klastra o środowisku wykonawczym watchOS szczegółowo omawia kontrakt.

Jak działa synchronizacja między urządzeniami w macierzy platform?

Trzy substraty: NSUbiquitousKeyValueStore dla małego stanu klucz-wartość (ustawienia, ostatnio wybrana karta, stan minutnika między urządzeniami),⁵ pliki iCloud Drive dla mostów między procesami (wzorzec Get Bananas + serwer MCP), SwiftData dla stanu w procesie. Wybierz jeden substrat na domenę; mieszanie dwóch dla tej samej domeny powoduje dryft. Post klastra o pojedynczym źródle prawdy prowadzi przez macierz decyzji.

Bibliografia