Xcode 27 porzuca Intela: co się kończy, a co nadal da się wydać

Zmianę dotyczącą Intela, która z największym prawdopodobieństwem zmieni już wydawany plik binarny, Apple umieściło w sekcji New Features, a nie Deprecations. Informacje o wydaniu Xcode 27 zawierają sekcję zatytułowaną Intel Deprecation z dokładnie dwoma wpisami, a ten, przez który aplikacja macOS przestaje domyślnie budować się jako Universal, znalazł się po stronie New Features.¹²

TL;DR

• Za nagłówkiem kryją się trzy odrębne zmiany, a zdania samego Apple wyraźnie je rozdzielają. Xcode 27 instaluje się i działa wyłącznie na Macach z Apple silicon.² SDK macOS 27 nadal pozwala wydawać aplikacje Universal wstecz, na macOS 12 i nowsze.² A ARCHS_STANDARD przestaje zawierać x86_64, gdy deployment target macOS lub DriverKit danego targetu osiąga 27.0.¹
• Tylko trzecia z nich zmienia to, co trafia do użytkowników — i robi to bez żadnego komunikatu. Rozwiązanie Apple podaje w tym samym wpisie: „Architekturę x86_64 można dodać do ustawienia kompilacji ARCHS, jeśli jest to potrzebne.”¹
• Xcode 26.6 nie pozwala podejrzeć nowego zachowania. Wymusiłem MACOSX_DEPLOYMENT_TARGET=27.0 w projekcie przeznaczonym wyłącznie na macOS, a ARCHS_STANDARD nadal rozwiązywało się do arm64 x86_64.¹³
• Dwa nawyki przy audycie produkują błędne odpowiedzi. Po podaniu -sdk macosx projekt tworzony wyłącznie na iOS raportował SUPPORTED_PLATFORMS = macosx i ARCHS_STANDARD = arm64 x86_64, a rozwiązywanie ustawień na poziomie projektu ukryło dwa targety macOS w projekcie, którego domyślny target to iOS.¹⁴
• W 11 moich projektach Xcode, obejmujących 44 targety: 21 buduje się dla macOS, najwyższy deployment target macOS wśród nich to 26.5, a żaden nie ustawia ARCHS ani EXCLUDED_ARCHS.¹⁴ Wszystkie 51 archiwów macOS na dysku to x86_64 arm64.¹⁴
• Koniec oprogramowania dla Intela przypada na macOS 28, a nie na Xcode 27, a zdanie Apple zawiera wyjątek, który warto przeczytać: „Żadne oprogramowanie oparte na Intelu nie będzie już zgodne z macOS 28.0, z wyłączeniem starszych gier.”¹⁰

Wszystko powyższe Apple publikuje jako tekst bety — w informacjach o wydaniu Xcode 27 beta 4 oraz macOS 27 beta 4.³⁶

Trzy zdania, trzy różne zmiany

Sekcja Intel Deprecation zawiera dwa wpisy. Odczytanie ich jako jednej tezy prowadzi do błędnej decyzji w obie strony.

Wpis o wycofaniu dotyczy maszyny stojącej na biurku i nie zostawia furtki: „Xcode 27 będzie się instalować i działać wyłącznie na Macach z Apple silicon.”² Żadne ustawienie kompilacji tego nie zmieni. Mac z procesorem Intela przestaje być maszyną, na której działa aktualny Xcode, a tabela zgodności Apple dokłada do wymogu sprzętowego również programowy, wskazując macOS Tahoe 26.4 lub nowszy jako wymaganie dla Xcode 27 beta 4.⁴

Ten sam wpis chroni następnie to, co powstaje na wyjściu: „SDK macOS 27 obsługuje wsteczne wdrażanie aplikacji Universal (Intel i Apple Silicon) na macOS 12 i nowsze.”² Tabela zgodności Apple to potwierdza: dla Xcode 27 beta 4 pokazuje zakres wdrożeniowy macOS od 12 do 27, wobec 11–26.5 dla Xcode 26.6.⁴ Dolna granica przesunęła się dokładnie o jedno wydanie. Binaria Universal przetrwały.

Wpis zamyka się zaś zachowaniem samego przepływu pracy: „Programowanie pod Intela jest nadal możliwe na wersjach macOS, które obsługują Rosettę, takich jak macOS 27.”²

Pozostaje wpis z New Features — ten, który jest w stanie zmienić produkt już wydawany:

Targety, których minimalny deployment target ustawiono na macOS 27.0 lub DriverKit 27.0, nie będą domyślnie budowane jako Universal. Ustawienie kompilacji ARCHS_STANDARD przestanie zawierać x86_64, gdy MACOSX_DEPLOYMENT_TARGET lub DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. Architekturę x86_64 można dodać do ustawienia kompilacji ARCHS, jeśli jest to potrzebne.¹

Warto rozdzielić cztery szczegóły. Apple wymienia dwa ustawienia i żadnych innych, więc IPHONEOS_DEPLOYMENT_TARGET i jego odpowiedniki pozostają poza tą regułą. Apple podaje próg, a nie wersję toolchainu, więc wyzwalaczem jest przekroczenie 27.0 przez własny deployment target. Apple pisze „nie będą domyślnie budowane jako Universal”, co opisuje wartość domyślną, a nie zakaz. I w tym samym oddechu Apple podaje furtkę, wskazując ARCHS jako miejsce, w którym można przywrócić x86_64.

Wartość domyślna, która zmienia się bez błędu

Mechanizm jest zwyczajny — i właśnie dlatego przechodzi bez echa. Dokumentacja ustawień kompilacji Apple opisuje ARCHS jako „listę architektur, dla których produkt zostanie zbudowany. Zwykle ustawia się je na predefiniowane ustawienie kompilacji dostarczone przez platformę. Jeśli podano więcej niż jedną architekturę, powstanie plik binarny universal.”⁵ Tym predefiniowanym ustawieniem jest ARCHS_STANDARD, a Apple potwierdza tę zależność w innym miejscu tej samej dokumentacji, zaznaczając przy uwierzytelnianiu wskaźników, że „nie ma ono efektu, jeśli ARCHS nadpisano tak, aby nie opierało się na ARCHS_STANDARD.”⁵

Target, który nigdy nie wspomina o ARCHS, dziedziczy więc to, co poda mu platforma. Wystarczy zmienić to, co podaje platforma, a produkt zmienia kształt bez edycji jakiegokolwiek pliku w kontroli wersji.

Nic w tej zmianie nie kończy się niepowodzeniem. Kompilator działa, linker działa, archiwum przechodzi walidację. Nic w toolchainie nie traktuje kompilacji macOS z jedną architekturą arm64 jako błędu, bo błędem nie jest. Powstaje poprawna, podpisana aplikacja macOS z jedną architekturą tam, gdzie wcześniej miała dwie. Na Macu z Apple silicon — czyli na maszynie, z której z konieczności korzysta teraz każdy programista Xcode 27 — kompilacja wyłącznie arm64 uruchamia się i zachowuje identycznie. Regresja ujawnia się na sprzęcie, którego w budynku już nie ma.

Nazwanie tego trybu awarii cichym to mój opis, nie Apple; Apple opisuje wartość domyślną i na tym kończy. Apple mówi natomiast, że poprawka polega na dodaniu, a to sformułowanie ma znaczenie przy planowaniu: x86_64 „można dodać do ustawienia kompilacji ARCHS, jeśli jest to potrzebne.”¹ Ocenę samej potrzeby Apple zostawia czytelnikowi.

Co Xcode 26.6 powie, a czego nie powie

Na moim komputerze działa Xcode 26.6 (build 17F113) na macOS 26.5.2, więc w tym artykule nie pojawia się nigdzie zachowanie Xcode 27.¹³ Pożyteczne pytanie, na które potrafi odpowiedzieć poprzedni toolchain, brzmi: czy już zachowuje się po nowemu. Nie zachowuje się.

Skierowanie xcodebuild na projekt przeznaczony wyłącznie na macOS i nadpisanie deployment targetu ponad próg wskazany przez Apple nie rusza listy architektur:¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

Pierwszy wiersz to xcodebuild odbijający nadpisanie z powrotem; reszta to wartości rozwiązane. To samo polecenie przy 26.0 zwraca identyczne wiersze z architekturami.¹³ Xcode 26.6 nie implementuje progu, więc nikt nie przećwiczy tej zmiany na obecnym toolchainie; każde porównanie „przed i po” czeka na Xcode 27 na Macu z Apple silicon.

Zakres platformowy da się natomiast odtworzyć już dziś. Ten sam projekt rozwiązany względem SDK dla iOS zwraca ARCHS_STANDARD = arm64, gdzie nie ma czego stracić, podczas gdy SDK dla macOS zwraca arm64 x86_64.¹³ Wpis Apple wymienia wyłącznie deployment targety macOS i DriverKit, a iOS-owa strona projektu wieloplatformowego niczym nie ryzykuje.

Jak zbadać własną ekspozycję, nie wymyślając jej

Dwa nawyki dają pewne siebie, błędne odpowiedzi. Wpadłem w oba.

Pierwszy to podawanie -sdk macosx, żeby sprawdzić, czy projekt buduje się dla macOS. Flaga nadpisuje własny SDK projektu, więc Xcode odpowiada na pytanie o flagę, a nie o projekt. Zapytany bez nadpisania, mój projekt przeglądarki tworzony wyłącznie na iOS podaje swoją prawdziwą platformę; zapytany z -sdk macosx, ten sam projekt raportuje SUPPORTED_PLATFORMS = macosx i ARCHS_STANDARD = arm64 x86_64, co jest czystym artefaktem.¹⁴ Proszę zacząć w ogóle bez -sdk:

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

W przypadku mojej jedynej aplikacji przeznaczonej wyłącznie na macOS wracają dwa wiersze:¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

Czytać trzeba oba wiersze, nigdy jeden. Ten projekt deklaruje SDKROOT = macosx i nie ma w ogóle wiersza SUPPORTED_PLATFORMS, więc tekstowe przeszukanie plików projektu pod kątem SUPPORTED_PLATFORMS daje mu zero punktów i pomija jedyną moją aplikację przeznaczoną wyłącznie na macOS.¹⁴ Rozwiązane ustawienia uzupełniają tę lukę z SDK; grep tego nie potrafi. Na tym etapie warto zignorować MACOSX_DEPLOYMENT_TARGET, bo Xcode dostarcza go niezależnie od wszystkiego: trzy moje projekty przeznaczone wyłącznie na iOS i tak raportują deployment target macOS — dwa 26.5, jeden 26.2.¹⁴

Drugi nawyk to rozwiązywanie ustawień na poziomie projektu. xcodebuild -showBuildSettings bez -target odpowiada dla jednego targetu, a projekt mieszany chowa resztę. Mój projekt rozszerzenia do Safari rozwiązał się do SUPPORTED_PLATFORMS = iphoneos iphonesimulator i ARCHS_STANDARD = arm64, co czyta się jak projekt wyłącznie iOS-owy, bez żadnej ekspozycji na Intela. Wyliczenie jego targetów pokazało cztery, w tym dwa dla macOS, oba rozwiązujące się do arm64 x86_64:¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

Jedna osobliwość, której należy się spodziewać: target z SDKROOT = auto nie rozwiązuje ARCHS_STANDARD, dopóki nie wskaże się SDK, więc 15 z moich 21 targetów macOS nie drukuje w tym wierszu niczego, dopóki polecenie nie doda -sdk macosx — wtedy ich projekty rozwiązują się do arm64 x86_64.¹⁴ Pusto znaczy „nierozwiązane”, a nie „puste”.

Potem trzeba przestać ufać ustawieniom i przeczytać plik binarny. Ustawienia kompilacji opisują zamiar; lipo opisuje artefakt, który faktycznie trafił do użytkowników:

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

Lepiej sięgnąć po lipo niż po metadane samego archiwum. Dwa moje archiwa nie zawierają w Info.plist żadnej listy architektur ApplicationProperties, więc zapytanie plutil do archiwum nie zwraca nic, podczas gdy lipo na binarce w środku zwraca x86_64 arm64.¹⁴ Brak w metadanych oznacza, że archiwum zapisano inaczej, a nie że aplikacja straciła architekturę.

Co naprawdę zawiera 11 projektów

Audyt objął 11 projektów Xcode z 44 targetami. Osiem projektów zawiera co najmniej jeden target macOS, 21 targetów buduje się dla macOS, a ekspozycja na nową wartość domyślną wynosi dziś zero.¹⁴

Najwyższy deployment target macOS w całej flocie to 26.5, najniższy 13.0 — w rozszerzeniu do Safari, do którego od dawna nikt nie wracał. Żaden target nie przekracza 27.0, więc żaden nie wchodzi w reżim zmienionej wartości domyślnej, dopóki ktoś ręcznie nie podniesie liczby. Zero targetów ustawia ARCHS, zero ustawia EXCLUDED_ARCHS, a we flocie nie ma ani jednego pliku .xcconfig, więc każda decyzja o architekturze we wszystkich 44 targetach pochodzi z ARCHS_STANDARD.¹⁴

Dowód z archiwów jest mocniejszy niż dowód z ustawień, bo archiwa zapisują to, co faktycznie zostało wydane. Na moim komputerze leży 79 archiwów zbudowanych między kwietniem a lipcem 2026 roku. Wszystkie 51 archiwów macOS, obejmujących siedem różnych produktów, raportuje x86_64 arm64. Wszystkie 28 archiwów z rodziny iOS raportuje arm64.¹⁴ W żadnym z tych projektów nikt nigdy nie wybrał Universal; za każdym razem tworzyła je wartość domyślna. To właśnie na tej populacji działa zmiana Apple — i dokładnie dlatego nikt jej nie zauważy.

Jedna uczciwa luka: podniesienie deployment targetu do 27.0 jest aktem świadomym, a żaden z moich projektów nie ma jeszcze powodu, żeby to zrobić. Czysty wynik floty mierzy chwilę, nie politykę.

Gdzie naprawdę kończy się oprogramowanie dla Intela

Zmiana w Xcode dotyczy architektur w kompilacji. Koniec oprogramowania dla Intela jako kategorii przypada na macOS 28 i Apple zapisało to zarówno w dokumentacji Rosetty, jak i w informacjach o wydaniu macOS 27 — oba źródła są ze sobą zgodne.

Dokumentacja Rosetty stawia ramy czasowe wprost. Rosetta „została zaprojektowana, aby ułatwić przejście na Apple silicon, i będzie dostępna do macOS 27 włącznie” jako narzędzie ogólnego przeznaczenia dla aplikacji intelowskich, a „poza tym horyzontem zachowamy podzbiór funkcji Rosetty nastawiony na wspieranie starszych, nierozwijanych tytułów gier, które opierają się na frameworkach intelowskich.”⁷ Informacje o wydaniu macOS 27 podają konsekwencję z tym samym wyjątkiem: „Żadne oprogramowanie oparte na Intelu nie będzie już zgodne z macOS 28.0, z wyłączeniem starszych gier.”¹⁰ Dostępne tylko w becie polecenie w innym miejscu tych samych informacji nadaje temu wyjątkowi kształt: sudo game-test-tool enable włącza obsługę starszych gier intelowskich, a Apple ostrzega, że „włączenie obsługi starszych gier wyłącza Rosettę.”¹⁵

macOS 27 spędza ten okres na nazywaniu tego, co nie przetrwa. Sekcja Deprecation Information informuje, że „aplikacje oparte na Intelu, które przestaną działać w macOS 28.0, mają teraz odpowiednie oznaczenie w oknie Informacje”, a osobny wpis dodaje, że „Ustawienia > Ogólne wymieniają teraz aplikacje intelowskie, które będą niezgodne z macOS 28.0”, w tym „nieużywane oprogramowanie intelowskie wykryte w systemie.”⁸⁹

Dla każdego, kto wydaje produkt na Maca, ważniejsze są trzy cichsze wpisy.

Sama Rosetta przestaje się utrzymywać: „Jeśli Rosetta była wcześniej zainstalowana, nie zostaje automatycznie przywrócona po aktualizacji do macOS 27.0.”¹¹ Kontekst dopowiada dokumentacja Apple, zaznaczając, że macOS 27 „bezpośrednio integruje obsługę translacji binariów intelowskich, bez potrzeby instalowania Rosetty”, z myślą o intelowskich binariach Linuksa w maszynach wirtualnych ARM oraz intelowskich kontenerach Linuksa.⁷ Zmieniają się też aplikacje przypięte przez użytkownika: programy ustawione wcześniej na „Otwórz przy użyciu Rosetty” teraz „uruchamiają się natywnie”, a Apple radzi, żeby „wszelkie dawne problemy ze zgodnością, które wymagały Rosetty, ocenić ponownie na macOS 27.”¹²

Instalatory zmieniają wartości domyślne: „Pakiety instalacyjne, które nie określają hostArchitecture, będą teraz domyślnie używać arm64”, a Apple prosi, aby „upewnić się, że skrypty pre- i post-install zachowują się zgodnie z oczekiwaniami pod arm64.”¹¹ Każdy produkt na Maca dystrybuowany poza App Store dziedziczy tę zmianę niezależnie od tego, czy jego aplikacja jest Universal.

Najostrzejszą krawędź niosą hosty wtyczek. Apple ostrzega, że „wtyczki i loadery oparte na Intelu mogą nie pojawiać się w Ustawieniach ani nie wywoływać powiadomień o swojej niezgodności”, i wskazuje katalogi do ręcznego sprawdzenia, w tym ~/Library/Audio/Plug-Ins/, ~/Library/Printers/ i ~/Library/ColorPickers/.¹⁰ Powód, dla którego wtyczka potrafi unieruchomić skądinąd natywną aplikację, znajduje się w dokumentacji Rosetty: „System uniemożliwia mieszanie kodu arm64 i kodu x86_64 w tym samym procesie. Translacja Rosetty obejmuje cały proces, łącznie ze wszystkimi modułami kodu, które proces ładuje dynamicznie.”⁷ Intelowska wtyczka wymusza więc translację całego hosta, zamieniając jeden nierozwijany komponent w zależność całej aplikacji od mechanizmu, którego ograniczenie Apple ma już zaplanowane.

Universal istnieje po to, by dosięgnąć Maców z Intelem na macOS od 12 do 27 — to zakres, który tabela zgodności Apple publikuje dla Xcode 27.⁴ Apple wyznaczyło koniec oprogramowania intelowskiego na macOS 28, a zakresu wdrożeniowego nie ruszyło, więc prawdziwe pytanie zespołu pracującego nad macOS brzmi: ilu jego użytkowników wciąż pracuje na Macu, który tej architektury potrzebuje.

Dwie rzeczy sprawdziłem i nie znalazłem ich śladu: ani informacje o wydaniu Xcode 27, ani te dla macOS 27 nie mówią nic o zmianie wymagań Universal Purchase w Mac App Store, i żadne z nich nie podaje kalendarzowej daty macOS 28.³⁶ Każdą napotkaną datę należy traktować jako domysł.

FAQ

Czy Xcode 27 uniemożliwia wydawanie aplikacji dla Intela?

Nie, a Apple mówi wręcz przeciwnie w tym samym wpisie, w którym uznaje Maki z Intelem za wycofywane maszyny deweloperskie: „SDK macOS 27 obsługuje wsteczne wdrażanie aplikacji Universal (Intel i Apple Silicon) na macOS 12 i nowsze.”² Tabela zgodności Apple potwierdza zakres, wskazując macOS od 12 do 27 jako deployment targety dla Xcode 27 beta 4.⁴ Zmienia się wartość domyślna. Target, którego deployment target macOS sięga 27.0, przestaje otrzymywać x86_64 z ARCHS_STANDARD, a podane przez Apple rozwiązanie polega na samodzielnym dodaniu x86_64 do ARCHS.¹ Wydawanie wersji dla Intela staje się wyborem, który trzeba zadeklarować, a nie takim, który się dziedziczy.

Czy kompilacja się nie powiedzie, jeśli ARCHS_STANDARD porzuci x86_64?

Nic we wpisie Apple nie opisuje błędu, ostrzeżenia ani jakiejkolwiek diagnostyki. Apple opisuje zmianę wartości domyślnej: targety na macOS lub DriverKit 27.0 i wyżej „nie będą domyślnie budowane jako Universal.”¹ Kompilacja, która kompiluje się, linkuje i podpisuje z jedną architekturą zamiast dwóch, jest kompilacją poprawną, a na Macu z Apple silicon, którego Xcode 27 wymaga, różnica pozostaje w czasie działania niewidoczna.² Apple podaje wartość domyślną i zostawia konsekwencję niedopowiedzianą, więc słowo „cicha” jest moje, nie Apple. Zamiast czekać, aż temat podniesie log kompilacji, warto sprawdzić lipo -archs na zarchiwizowanej binarce.

Czy nowe zachowanie da się przetestować na Xcode 26?

Nie. Sprawdziłem to bezpośrednio na Xcode 26.6 (build 17F113): nadpisanie MACOSX_DEPLOYMENT_TARGET na 27.0 w projekcie przeznaczonym wyłącznie na macOS nadal rozwiązuje ARCHS_STANDARD = arm64 x86_64, identycznie jak to samo polecenie przy 26.0.¹³ Poprzedni toolchain nie implementuje progu, więc żadne eksperymenty z ustawieniami kompilacji na Xcode 26 nie pokażą tej zmiany z wyprzedzeniem. Xcode 26.6 odtwarza natomiast sam zakres: ten sam projekt rozwiązuje ARCHS_STANDARD = arm64 względem SDK dla iOS i arm64 x86_64 względem SDK dla macOS, co pasuje do wpisu wymieniającego deployment targety macOS i DriverKit i nic poza nimi.¹¹³

Czy potrzebny jest teraz Mac z Apple silicon?

Do uruchomienia Xcode 27 tak, bez żadnych zastrzeżeń: „Xcode 27 będzie się instalować i działać wyłącznie na Macach z Apple silicon.”² Apple dokłada do wymogu sprzętowego programowy, wymagając macOS Tahoe 26.4 lub nowszego dla Xcode 27 beta 4.⁴ Programowanie pod Intela przetrwa na starszych toolchainach — tak formułuje to Apple: „Programowanie pod Intela jest nadal możliwe na wersjach macOS, które obsługują Rosettę, takich jak macOS 27.”² Dokumentacja Rosetty stawia tej drodze granicę, stwierdzając, że Rosetta „będzie dostępna do macOS 27 włącznie” jako narzędzie ogólnego przeznaczenia, a później w ograniczonym podzbiorze nastawionym na starsze, nierozwijane gry.⁷

Najważniejsze wnioski

Dla twórców aplikacji na macOS: - Audyt należy zacząć bez flagi -sdk, czytać SUPPORTED_PLATFORMS i SDKROOT razem, a MACOSX_DEPLOYMENT_TARGET zignorować przy pytaniu, czy target w ogóle buduje się dla macOS. Xcode wpisuje deployment target macOS także do projektów przeznaczonych wyłącznie na iOS: trzy moje go raportują (26.5, 26.5 i 26.2), nie budując się na żadnego Maca.¹⁴ - Targety trzeba wyliczyć poleceniem xcodebuild -list, zanim rozwiąże się ustawienia. Zapytanie na poziomie projektu w moim rozszerzeniu do Safari pokazało projekt wyłącznie iOS-owy i ukryło dwa targety macOS.¹⁴

Dla zespołów, wśród których użytkowników są Maki z Intelem: - O x86_64 warto decydować jawnie, zamiast je dziedziczyć. Podnosząc deployment target macOS do 27.0, należy ustawić ARCHS, bo wpis Apple oferuje dokładnie takie rozwiązanie i żadnego ostrzeżenia, gdy się je pominie.¹ - Weryfikować trzeba poleceniem lipo -archs na zarchiwizowanej binarce — nie na ustawieniach kompilacji i nie na pliku Info.plist archiwum. Dwa moje archiwa nie mają w ogóle metadanych o architekturze, choć ich binarki są Universal.¹⁴

Dla osób odpowiedzialnych za wydania: - Termin sprzętowy trzeba oddzielić od terminu wydawniczego. Xcode 27 wymaga Maca z Apple silicon od pierwszego dnia; wynik Universal nadal sięga macOS 12 i nowszych, a Apple nie opublikowało kalendarzowej daty macOS 28.²⁴ - Inwentaryzacja powinna objąć intelowskie wtyczki i pakiety instalacyjne, nie tylko aplikacje. Apple ostrzega, że wtyczki intelowskie „mogą nie pojawiać się w Ustawieniach”, a taka wtyczka wymusza translację całego procesu hosta.⁷¹⁰

Cykl 27 wciąż ukrywa doniosłe zmiany w miejscach niepozornych. Usunięcie linkera i reguła nazw modułów łamią kompilacje wprost przy aktualizacji toolchainu, makro @State łamie je na poziomie kodu źródłowego, a klucz ekranu startowego blokuje wysyłkę aplikacji. Domyślna zmiana dotycząca Intela nie łamie niczego, a mimo to zmienia produkt — i właśnie dlatego warto ją zbadać przed aktualizacją, a nie po niej. Całość zbiera Seria o ekosystemie Apple.

Źródła