Co nowego w Swift (2026): aktualizacja WWDC26

Apple wydało dwie wersje Swift w jednym cyklu WWDC: 6.3 i 6.4 pojawiły się razem, a sesja „What’s new in Swift” omówiła obie jako jeden spójny łuk prac¹. Sposób ujęcia ma znaczenie, ponieważ zmiany dzielą się czytelnie na dwie grupy odbiorców. Większość programistów otrzymuje drobniejszą, codzienną ergonomię (rezygnacja z nawiasów wokół opcjonalnych any, zwinięcie kilkunastu nazw platform @available w jedno anyAppleOS, wyciszenie ostrzeżenia o deprecjacji w dokładnie jednej deklaracji). Mniejsza grupa pisząca kod wrażliwy na wydajność otrzymuje owoc wieloletnich prac: system własności sięga teraz pętli for, właściwości obliczanych oraz samej biblioteki standardowej.

Swift w 2026 roku jest też wyraźnie projektem wieloplatformowym i wielojęzykowym. Apple ogłosiło oficjalne Swift SDK dla Androida, dystrybuowane przez swift.org⁶, szybsze mostkowanie do JavaScriptu dzięki WebAssembly, możliwość eksportu funkcji Swift z powrotem do C dzięki nowemu atrybutowi @C, oraz backend Swift Build, który teraz domyślnie napędza Swift Package Manager¹. Ten wpis przechodzi przez cztery sesje definiujące historię Swift w roku 2026: aktualizacje języka i biblioteki (262), ścieżkę migracji do Swift Testing (267), usługi czasu rzeczywistego z gRPC (265) oraz obliczenia numeryczne z MLX Swift (328).

TL;DR

• Swift 6.3 i 6.4 ukazały się razem na WWDC26. Codzienna ergonomia: opcjonalne any/some bez nawiasów, dostępność anyAppleOS, atrybut @diagnose do sterowania ostrzeżeniami w pojedynczej deklaracji oraz selektory modułów (::) przy kolizjach nazw¹.
• System własności sięgnął zwykłego kodu: nowy protokół Iterable pozwala pętlom for pożyczać elementy zamiast je kopiować, a akcesory borrow/mutate zastępują get/set, aby unikać kopiowania dużych wartości we właściwościach obliczanych¹.
• Nowe typy biblioteki standardowej dostarczają bezpieczne wersje dawnych niebezpiecznych wzorców: UniqueArray, UniqueBox, jednorazowo wznawiana Continuation oraz Ref/MutableRef do przechowywania pożyczki lub mutacji w zmiennej¹.
• Swift Testing współpracuje teraz z XCTest w obu kierunkach, w czterech trybach (limited, complete, strict, none); Xcode 27 włącza interoperacyjność domyślnie². Powierzchnia @Test, @Suite, #expect i #require jest udokumentowana w dokumentacji Swift Testing od Apple⁵.
• gRPC Swift osiągnęło punkt, w którym generuje się typowanego klienta z pliku .proto i otrzymuje unarne oraz dwukierunkowe strumieniowe RPC, wdrażalne do kontenerów Linux w chmurze³.
• MLX Swift wnosi do Swift obliczenia tablicowe w stylu NumPy, z automatycznym wykonaniem na GPU i automatycznym różniczkowaniem grad, dzieląc jeden silnik między frontendami Swift, Python, C++ i C⁴.

Ergonomia języka: drobne uciążliwości znikają

Sesja otwiera się zmianami, których „prawie nie zauważysz — poza tym, że małe uciążliwości znikają”¹. Warto je wymienić, bo usuwają tarcia narosłe przez dekadę istnienia języka.

Becca i Evan z zespołu Swift przechodzą przez Swift 6.3 i 6.4. Część poświęcona językowi zaczyna się około 0:45.

Można teraz zapisać any P? bez owijania w nawiasy. Pojawia się ostrzeżenie, gdy zadanie Swift Concurrency po cichu porzuca rzucony błąd, co skłania do obsłużenia go w zadaniu albo zapisania zadania i sprawdzenia później. Dawne ograniczenie wywoływania funkcji async z bloku defer zniknęło, więc asynchroniczne sprzątanie przebiega tak samo, jak zawsze przebiegało odroczone synchroniczne sprzątanie (SE-0493, Swift 6.4)⁷. Klasa, która potrzebowała @unchecked Sendable jedynie z powodu właściwości weak var, może zmienić tę właściwość na weak let i kwalifikować się do prawidłowego sprawdzania Sendable. Typ, który nie powinien być Sendable, może powiedzieć to wprost dzięki nowej składni ~Sendable, co nie powstrzymuje podklas przed byciem Sendable¹.

Dwie zmiany na pewno zostaną zauważone. Pierwsza to dostępność: Apple ujednoliciło w zeszłym roku numery wersji swoich systemów, a Swift idzie dalej, pozwalając skondensować każdą nazwę platformy w jedną — anyAppleOS. Gdy dostępność pokrywa się na interesujących platformach, podaje się je wszystkie naraz; gdy są wyjątki, ustawia się anyAppleOS jako wartość domyślną i dodaje atrybuty specyficzne dla platformy dla wyjątków. Ta sama nazwa działa w warunkach #if os(...)¹.

Druga to atrybut @diagnose, który zmienia zachowanie konkretnych ostrzeżeń wewnątrz pojedynczej deklaracji. Można powiedzieć Swiftowi, by ignorował grupę ostrzeżeń deprecated declaration w jednej funkcji podczas migracji do nowego API, bez wyciszania jej w całym projekcie. Da się też zadziałać w drugą stronę: włączyć ścisłe bezpieczeństwo pamięci wewnątrz funkcji krytycznej dla bezpieczeństwa albo od razu podnieść przyszłe ostrzeżenie do rangi błędu¹. Holly Borla, kierowniczka inżynierii w zespole Swift, wskazała ten atrybut jako swój wyróżnik, zamykając WWDC26: „Jedną z moich ulubionych nowych funkcji jest atrybut @Diagnose, który pozwala kontrolować zachowanie ostrzeżeń w kodzie; pozwala robić takie rzeczy jak tłumienie deprecjacji, ale pozwala też włączać ścisłe bezpieczeństwo pamięci lub ścisłe diagnostyki współbieżności na bardziej granularnym poziomie, co pomaga na przykład w migracji do trybu języka Swift 6.”⁸ Całe wydanie 6.4 ujęła tak samo: aktualizacje „usuwają rzeczy będące punktami tarcia”, aby programiści mogli skupić się na wyrażaniu swoich pomysłów w czytelnym, pięknym kodzie⁸.

Są też selektory modułów. Gdy dwa importowane moduły deklarują typ o nazwie View, dawnym rozwiązaniem była składnia z kropką (Rocket.SaturnV), która zawodzi, gdy moduł o nazwie Rocket zawiera też typ o nazwie Rocket, ponieważ Swift preferuje typ, a następnie nie znajduje składowej. Swift 6.3 wprowadza ::, gdzie nazwa po lewej stronie jest zawsze nazwą modułu, więc Rocket::SaturnV trafia prosto do modułu. Selektor działa też na nazwach metod i właściwości. Wskazówka Apple jest stanowcza: używać go przy konfliktach między modułami, których się nie kontroluje, oraz obronnie w kodzie generowanym przez makra, ale nie projektować API, które celowo kolidują, a potem polegają na selektorach do rozróżnienia¹.

Biblioteka standardowa i Foundation

Biblioteka standardowa zyskała celowane dodatki. Tarcza anulowania zadania (withTaskCancellationShield, SE-0504, Swift 6.4) uruchamia krótki obszar, w którym sprawdzenia anulowania zawsze zwracają false, więc asynchroniczne sprzątanie, takie jak dokończenie zapisu na dysk, nadal się wykonuje po anulowaniu otaczającego zadania⁷. mapKeyedValues przekazuje do domknięcia mapującego zarówno klucz, jak i starą wartość, zastępując ręczną rekonstrukcję słownika, którą wymuszał mapValues, gdy potrzebny był klucz. Nowy typ ścieżki pliku, oparty na tym ze Swift System, obsługuje różnice platformowe w reprezentacji ścieżek¹.

Foundation kontynuowało swoją wieloletnią migrację z Objective-C na Swift. Apple zmodernizowało więcej Data (szybszy dostęp do span, sprawdzanie równości, iteracja i mutacja) oraz zunifikowało NSURL i CFURL w jedną implementację Swift, która działa szybciej i zużywa mniej pamięci. ProgressManager to nowy typ raportowania postępu zbudowany pod async/await, a pakiet Subprocess osiągnął wersję 1.0 z uproszczonym typem wykonania, strumieniowanym wyjściem jako AsyncBufferSequence oraz metodą strings(), która czyta wyjście wiersz po wierszu, respektując granice klastrów grafemów¹.

Własność sięga zwykłego kodu

Historię wydajności warto czytać uważnie, bo reprezentuje moment, w którym wieloletni projekt kompilatora staje się czymś używalnym w codziennych typach. Sednem problemu jest kopiowanie: dane są w jednym miejscu, potrzeba ich w innym, więc program je kopiuje. Gdy magazyn pozostaje zaalokowany, a obie strony przestrzegają reguł wyłączności Swift, kopia jest zbędna. Pożyczka (borrow) przyznaje dostęp do odczytu istniejącego magazynu bez kopiowania go; mutacja (mutate) przyznaje wyłączny dostęp do zapisu. Kompilator weryfikuje obie podczas kompilacji, co właśnie czyni tę technikę bezpieczną tam, gdzie surowy UnsafePointer nie był¹.

Część o własności i strojeniu wydajności zaczyna się około 19:55 i obejmuje kontrolę inliningu, specjalizację oraz nowe akcesory.

Kilka protokołów działa teraz bez kopiowania. Equatable, Comparable i Hashable można stosować na typach niekopiowalnych, a Equatable i Comparable rozszerzają się na typy niewymykające się (non-escapable). Typy powiązane mogą być teraz niekopiowalne lub niewymykające się, co umożliwia funkcję będącą gwoździem programu: nowy protokół Iterable, który pętle for wspierają bezpośrednio¹.

Protokół Sequence, który wszyscy znają, kopiuje elementy na zewnątrz podczas iteracji. Iterable pozwala pętli zamiast tego je pożyczać, co oznacza, że działa z elementami niekopiowalnymi i pomija zliczanie referencji na obiektach oraz typach copy-on-write. Może rzucać podczas iteracji, tak jak potrafi AsyncSequence. Ponieważ pożyczanie zabrania mutacji, sprawdzanie wyłączności powstrzymuje od mutowania kolekcji podczas pętli (częsta pułapka wydajnościowa przy Sequence). Pętla for preferuje Sequence, gdy jest dostępny, i wraca do Iterable, a iterator Iterable zwraca elementy w partiach span zamiast po jednym, co czyni pętlę wymiernie wydajniejszą dla typów potrafiących oddać wszystko w jednym span¹.

Akcesory dostały to samo traktowanie. Przykładem Apple jest UniqueBox przechowujący InlineArray 256 wartości Int, dwukilobajtowa struktura na urządzeniu 64-bitowym. Przy get/set zmiana jednego elementu kopiuje całą tablicę na zewnątrz i z powrotem. Przełączenie właściwości obliczanej na akcesor borrow (dostęp tylko do odczytu bez kopiowania) oraz akcesor mutate (wyłączna modyfikacja w miejscu) pozwala Swiftowi zmienić jeden element w miejscu oraz pozwala typowi przechowywać wartości niekopiowalne¹.

Kilka nowych typów biblioteki standardowej dostarcza bezpieczne zamienniki wzorców, które wcześniej wymagały niebezpiecznego kodu:

• UniqueArray zachowuje się jak Array, ale jest niekopiowalny, więc przechowuje elementy niekopiowalne i unika narzutu zliczania referencji bez zobowiązywania się do stałego rozmiaru.
• UniqueBox to prawdziwy typ biblioteki standardowej korzystający z nowych akcesorów.
• Continuation sprawdza podczas kompilacji, że wznawia się ją dokładnie raz, co czyni ją bezpieczniejszą niż CheckedContinuation i tak samo wydajną jak UnsafeContinuation.
• Ref i MutableRef działają jak Span dla pojedynczej wartości: kontener na pożyczkę lub mutację, który można przechować w zmiennej, przekazać, zwrócić i użyć w typach generycznych. MutableRef buduje się z dostępu do zapisu poprzedzonego prefiksem &, a ponieważ referencje są niewymykające się, Swift wie, że dostęp kończy się, gdy zmienna opuszcza zakres¹.

UniqueArray oraz RigidArray o stałej pojemności mieszczą się w nowym module Containers (SE-0527, przyjęty co do zasady), a obu można używać już dziś poprzez swift-collections 1.3, zanim trafią na stałe do biblioteki standardowej⁷.

Dla kontroli optymalizatora Swift 6.4 dodaje @inline(always), dopełniając wieloletni @inline(never) (warto łączyć go z final na metodach klas, bo metoda nadpisywalna i tak może się nie zainline’ować), a Swift 6.3 dodaje @specialized, gdzie klauzula where mówi kompilatorowi, by z góry wygenerował wyspecjalizowaną wersję funkcji generycznej dla najczęściej używanych typów konkretnych¹. Rzadko będą potrzebne. Gdy już będą, jak ujmuje to sesja, „będziesz zadowolony, że je masz”¹.

Swift Testing: migracja jest teraz dwukierunkowa

Swift Testing pojawiło się w Xcode 16 jako nowoczesna, oparta na makrach, równoległa domyślnie biblioteka testowa². Historia roku 2026 to migracja, a kluczowym dodatkiem jest interoperacyjność frameworków testowych: możliwość wywoływania API jednego frameworku wewnątrz ciała testu z drugiego, w obu kierunkach².

Jerry z zespołu Swift Testing pokazuje wywoływanie pomocników XCTest z testów Swift Testing. Omówienie interoperacyjności zaczyna się około 5:48.

Strategia migracji rekomendowana przez Apple nie zmieniła się: pozostawić większość testów XCTest na miejscu, pisać nowe testy w Swift Testing i migrować te, które dotyka się najczęściej. Oba frameworki już współistnieją w jednym targecie. Nowością jest możliwość ponownego wykorzystania kodu pomocniczego zbudowanego na XCTest. Gdy test Swift Testing wywołuje pomocnika assertUnique, który opakowuje XCTFail, daje to międzyframeworkowy problem (cross-framework issue), a Xcode obsługuje go teraz w czterech trybach²:

• Limited: międzyframeworkowe problemy z XCTest są ostrzeżeniami. Plany testów utworzone przed Xcode 27 dziedziczą ten tryb, a pakiety Swift na swift-tools-version: 6.3 mają go domyślnie.
• Complete: te same problemy pozostają błędami. Xcode 27 używa trybu complete dla nowych projektów; pakiety Swift włączają go, podnosząc do swift-tools-version: 6.4 lub nowszej.
• Strict: międzyframeworkowe problemy z XCTest zatrzymują test błędem krytycznym, wskazując każde miejsce do zastąpienia API XCTest.
• None: całkowita rezygnacja (używać tylko tymczasowo, bo te problemy mogą sygnalizować prawdziwe błędy).

Międzyframeworkowe problemy ze Swift Testing pozostają błędami w każdym trybie, więc można bezpiecznie wywoływać #expect i #require z wnętrza XCTestCase. Wartość domyślną w pakiecie nadpisuje się zmienną środowiskową SWIFT_TESTING_XCTEST_INTEROP_MODE (nazwa trybu małymi literami)². Sesja 262 o XCTest potwierdza odpowiadającą stronę biblioteki standardowej: niepowodzenia asercji XCTest wypływają teraz jako problemy testowe, gdy są wywoływane z poziomu Swift Testing, więc migruje się bez cichej utraty pokrycia¹.

Książka kucharska migracji obejmuje typowe wzorce. XCTSkip staje się Test.cancel (albo, lepiej, cechą .enabled/.disabled, która przenosi logikę włączania poza ciało testu). continueAfterFailure = false staje się #require, które rzuca przy niepowodzeniu i zatrzymuje test, pozwalając wybrać dla każdego oczekiwania, które niepowodzenia zatrzymują wykonanie². Interoperacyjność wspiera ograniczony, lecz praktyczny zestaw API: wszystkie asercje XCTest, oba makra oczekiwań (#expect i #require), API znanych problemów do oznaczania niepowodzeń XCTest jako znanych oraz Test.cancel do pomijania przypadków XCTest².

Co do samej powierzchni API (makra, słownik cech, co pozostaje w XCTest), towarzyszący wpis Swift Testing vs. XCTest omawia model mentalny. Dwie uwagi przenoszą się stamtąd dalej: automatyzacja UI i testy wydajności pozostają wyłącznie w XCTest, a kod rzucający wyjątki Objective-C musi pozostać w testach XCTest napisanych w Objective-C, ponieważ kod Swift nie potrafi bezpiecznie obsłużyć tych wyjątków². Po migracji otrzymuje się testy parametryzowane (każdy argument to osobny przypadek, wszystkie działające równolegle) oraz testy zakończenia (exit tests), które uruchamiają kod mający się zawiesić w procesie potomnym, by zweryfikować zakończenie, dostępne na macOS, Linux, FreeBSD i Windows².

gRPC Swift: typowane usługi czasu rzeczywistego

Historia serwerowa to najjaśniejsza demonstracja, że Swift obejmuje teraz klienta i backend jednym językiem. Sesja o gRPC buduje aplikację iOS rozmawiającą z serwerem Swift, wygenerowaną w całości ze specyfikacji .proto³.

George z zespołu Swift Server objaśnia cztery typy RPC. Część o strumieniowaniu, w tym strumieniowanie dwukierunkowe, zaczyna się około 11:06.

gRPC to projekt Cloud Native Computing Foundation, w którym API definiuje się jako funkcje z typowanymi wejściami i wyjściami, zamiast endpointów HTTP, a kod klienta generuje się ze specyfikacji³. Przepływ pracy: zdefiniować usługę w pliku .proto, dodać grpc-swift-nio-transport (sieć na SwiftNIO) oraz grpc-swift-protobuf (wtyczka budowania) jako zależności pakietu, dołączyć wtyczkę run-build-tool GRPCProtobufGenerator i przekompilować, aby wygenerować typowanego klienta.

Unarne RPC, takie jak ListRaces, wysyła jedno żądanie i otrzymuje jedną odpowiedź. Demo z gokartami z sesji wpina je w widok SwiftUI dzięki withGRPCClient, następnie refaktoryzuje, by współdzielić jednego klienta przez środowisko SwiftUI, tak by widoki współużytkowały połączenia, i rozłącza, gdy scena przechodzi w tło³. Protobuf serializuje wiadomości do postaci binarnej, kluczowanej numerem pola zamiast nazwą pola, co czyni wiadomość „mniej więcej o połowę mniejszą od równoważnej wiadomości JSON”³ — realna korzyść w słabych sieciach mobilnych. Apple zauważa, że ta sama wydajność napędza jego własną infrastrukturę: gRPC Swift napędza komunikację międzyprocesową w otwartoźródłowym frameworku Containerization i stanowi podstawę Private Cloud Compute, iCloud Keychain i Photos oraz udostępniania plików w SharePlay³.

Wsparcie strumieniowania jest tym, co umożliwia czas rzeczywisty. Poza unarnymi RPC istnieją strumieniowanie klienta (wiele żądań, jedna odpowiedź), strumieniowanie serwera (jedno żądanie, wiele odpowiedzi, jak strumień komentarza na żywo) oraz strumieniowanie dwukierunkowe. Demo używa strumieniowania dwukierunkowego do aktualizacji wyścigu na żywo: klient strumieniuje, jakich typów zdarzeń chce, podczas gdy serwer strumieniuje pasujące zdarzenia. Po stronie serwera staje się to funkcją async, której parametr żądania jest AsyncSequence wiadomości, a parametr odpowiedzi jest pisarzem (writer), obsługiwaną grupą zadań i chronionym muteksem zbiorem subskrybowanych typów zdarzeń³. Wdrożenie to wieloetapowy Containerfile (budowa z swift:latest, skopiowanie binarki release do swift:slim), uruchamiany na Google Cloud Run z HTTP/2, po czym klient przełącza zabezpieczenie transportu z plaintext na TLS³.

MLX Swift: obliczenia numeryczne, które czyta się jak matematykę

Sesja o MLX celuje w zupełnie innego programistę: w każdego, kto pisze symulacje, przetwarzanie sygnałów, rendering lub trening modeli. MLX Swift używa tablic n-wymiarowych jako swojej centralnej abstrakcji, tak jak robi to NumPy, więc „większość kodu NumPy można przełożyć na MLX Swift przy minimalnych zmianach”⁴.

David Koski przechodzi przez przykład Mandelbrota. Porównanie obliczeń tablicowych ze zwykłym Swift zaczyna się około 4:28.

MLX stoi obok istniejącego stosu numerycznego Apple, a nie zastępuje go: Accelerate dla ręcznie strojonych wektorowych prymitywów CPU, BNNS dla bloków budulcowych sieci neuronowych, Metal Performance Shaders dla bezpośrednich jąder GPU oraz Swift Numerics dla typu Complex. Po MLX Swift sięga się, gdy celem jest „pisanie kodu matematycznego z myślą o wydajności” i chce się, by kod wyglądał jak matematyka⁴.

Umożliwiają to dwie cechy. Leniwa ewaluacja buduje graf obliczeń w miarę pisania operacji tablicowych i nie uruchamia niczego, dopóki nie wywoła się eval albo nie odczyta wartości, dlatego pętla wywołuje eval na każdym kroku, by utrzymać graf małym. Leniwa ewaluacja napędza też automatyczne wykonanie na GPU oraz automatyczne różniczkowanie poprzez transformację funkcji grad⁴. Przykład Mandelbrota zwija skalarną pętlę po pikselach w dwie linie (z = z * z + c zastosowane do całej siatki, a następnie zliczenie iteracji ograniczonych), działa domyślnie na GPU, a sesja zauważa, że „10x szybciej jest z pewnością możliwe”⁴. Solver rozkładu ciepła wyraża iterację Jacobiego jako pojedyncze wywołanie conv2d. Przykład dopasowania krzywej używa grad do obliczenia dokładnych gradientów bez ręcznie pisanych pochodnych — to ta sama idea, która stoi za treningiem każdego modelu ML⁴.

MLX Swift jest otwartoźródłowy na licencji MIT, instalowalny przez Swift Package Manager i jednym z czterech frontendów (Swift, Python, C++ i C) dzielących te same operacje oraz model leniwej ewaluacji, więc można „prototypować w Pythonie i wdrażać w Swift”⁴. Ekosystem obejmuje mlx-swift (rdzeń frameworku), mlx-swift-lm (implementacje modeli językowych) oraz mlx-swift-examples (uruchamialne przykłady LLM, dyfuzji i treningu)⁴. Po kontekst dotyczący ML na urządzeniu wokół tego zob. MLX on-device ML on Apple Silicon.

Co przyjąć najpierw

Uporządkuj pracę według tego, kim jesteś.

Jeśli wydajesz aplikacje i rzadko sięgasz po pokrętła wydajności kompilatora, przyjmij ergonomię już teraz i zignoruj system własności. Zastąp piętrzące się linie @available przez anyAppleOS tam, gdzie platformy się pokrywają, użyj @diagnose, by wyciszyć ostrzeżenia o deprecjacji dokładnie tam, gdzie jesteś w trakcie migracji, i sięgnij po selektory modułów (::), gdy następnym razem zależność skoliduje ze SwiftUI na nazwie takiej jak View¹.

Jeśli utrzymujesz duży zestaw testów XCTest, włącz interoperacyjność i zacznij pisać nowe testy w Swift Testing już dziś. Przenieś istniejące plany testów do trybu complete, by międzyframeworkowe problemy były błędami nie do przeoczenia, ponownie wykorzystuj pomocników XCTest przez interoperacyjność, zamiast przepisywać je z góry, i migruj pliki, które dotykasz najczęściej. Pozostaw automatyzację UI, testy wydajności i testy wyjątków Objective-C w XCTest¹².

Jeśli piszesz kod wrażliwy na wydajność, dodatki dotyczące własności są gwoździem programu. Przeaudytuj gorące właściwości obliczane przechowujące duże wartości i przełącz je z get/set na borrow/mutate. Tam, gdzie wcześniej schodziłeś do UnsafePointer, spójrz na Ref/MutableRef, UniqueArray oraz jednorazowo wznawianą Continuation. Zmierz, zanim sięgniesz po @inline(always) lub @specialized, bo optymalizator zwykle ma rację, a wymuszanie na nim może uczynić binarkę większą i wolniejszą¹.

Jeśli twoja praca jest serwerowa lub numeryczna, nowe pakiety to gotowe na produkcję punkty wejścia: gRPC Swift daje typowanego klienta i strumieniowanie dwukierunkowe z pliku .proto, a MLX Swift daje obliczenia tablicowe akcelerowane przez GPU i automatyczne różniczkowanie, które czyta się jak matematykę³⁴.

FAQ

Jaka jest różnica między Swift 6.3 a Swift 6.4?

Apple opracowało i wydało obie w tym samym cyklu WWDC26 i przedstawiło je razem. Z grubsza, Swift 6.3 wprowadził selektory modułów (::) oraz atrybut @specialized, a także dostarczył pierwsze oficjalne Swift SDK dla Androida. Swift 6.4 dodał dostępność anyAppleOS, opcjonalne any/some bez nawiasów, protokół Iterable dla pętli for, akcesory borrow/mutate, @inline(always), atrybut @C do eksportu funkcji Swift do C oraz usprawnienia debugowania embedded-Swift. Sesja omawia obie jako jeden ciągły zbiór prac¹.

Czy muszę migrować z XCTest do Swift Testing?

Nie. XCTest nadal jest wydawany i nadal działa, a rekomendacja Apple jest stopniowa: pisać nowe testy w Swift Testing i migrować stare w miarę dotykania ich. Interoperacyjność frameworków testowych pozwala obu współistnieć w jednym targecie i wywoływać nawzajem swoje API, więc można ponownie wykorzystać pomocników XCTest z testów Swift Testing. Automatyzacja UI, testy wydajności oraz kod rzucający wyjątki Objective-C pozostają w XCTest¹².

Co nowy protokół Iterable robi takiego, czego nie robi Sequence?

Sequence kopiuje elementy na zewnątrz podczas iteracji. Iterable pozwala pętli for zamiast tego pożyczać elementy, więc działa z elementami niekopiowalnymi i pomija zliczanie referencji na obiektach oraz typach copy-on-write. Zwraca elementy w partiach span zamiast po jednym, co jest wydajniejsze, i może rzucać podczas iteracji. Ponieważ pożyczanie zabrania mutacji, nie można mutować kolekcji podczas pętli. Pętla for preferuje Sequence, gdy jest dostępny, i wraca do Iterable¹.

Kiedy używać MLX Swift zamiast Accelerate lub Metal Performance Shaders?

Używaj MLX Swift, gdy głównym celem jest pisanie kodu matematycznego z myślą o wydajności i chcesz, by kod czytał się jak matematyka, z automatycznym wykonaniem na GPU i automatycznym różniczkowaniem przez grad. Accelerate pozostaje wyborem dla ręcznie strojonych wektorowych prymitywów CPU, BNNS dla bloków budulcowych sieci neuronowych, a Metal Performance Shaders dla bezpośredniego dostępu do jąder GPU. MLX stoi obok nich, a nie zastępuje ich⁴.

Czy gRPC Swift jest tylko dla usług backendowych?

Nie. Sesja WWDC buduje aplikację iOS jako klienta gRPC, generując typowanego klienta z pliku .proto, i pokazuje unarne oraz dwukierunkowe strumieniowe RPC napędzające aktualizacje UI na żywo. Binarne kodowanie Protobuf produkuje wiadomości mniej więcej o połowę mniejsze od równoważnego JSON, co pomaga w słabych sieciach mobilnych. Apple używa też gRPC Swift do komunikacji międzyprocesowej oraz w usługach takich jak Private Cloud Compute, iCloud Keychain i Photos oraz udostępnianie plików w SharePlay³.

Klaster Apple Ecosystem

Aktualizacja Swift z 2026 roku przeplata się z resztą serii Apple Ecosystem: rozbiór modelu testowania w Swift Testing vs. XCTest, Observable internals in SwiftUI, których dotykają zmiany w współbieżności, what SwiftUI is made of na poziomie frameworku oraz MLX on-device ML on Apple Silicon dla kontekstu obliczeń numerycznych. Węzłem łączącym to wszystko jest seria Apple Ecosystem. Po budowanie aplikacji iOS z agentami AI w pętli zob. przewodnik iOS Agent Development.

Bibliografia