Apple Foundation Models: framework LLM na urządzeniu — wyjaśnienie

Framework Foundation Models daje aplikacji bezpośredni, darmowy i działający offline dostęp do tego samego dużego modelu językowego na urządzeniu, który napędza Apple Intelligence¹. Bez klucza API, bez rachunku za tokeny, bez ruchu sieciowego, bez danych opuszczających urządzenie. Cała klasa funkcji, która kiedyś oznaczała LLM w chmurze i przegląd prywatności, kosztuje dziś praktycznie zero. Ceną jest zakres możliwości: model na urządzeniu jest mały, okno kontekstowe skończone, a framework wyznacza twarde granice tego, co zrobi, a czego nie. Znajomość tych granic to sedno całej sprawy.

Ten tekst jest przewodnikiem po samym frameworku: typy, które faktycznie się wywołuje, jedna funkcja przesądzająca o jego wartości oraz moment, w którym trzeba się zatrzymać i sięgnąć po coś większego.

TL;DR

• LanguageModelSession to punkt wejścia. Wystarczy utworzyć sesję, wywołać respond(to:) i odebrać tekst. Kontekst wielu tur pozostaje w sesji; zadania jednorazowe dostają za każdym razem świeżą sesję².
• Generowanie sterowane jest powodem, dla którego w ogóle warto sięgnąć po ten framework. Wystarczy oznaczyć typ Swift adnotacją @Generable, a model zwróci właśnie ten typ — wypełniony i z kontrolą typów — zamiast łańcucha znaków do samodzielnego parsowania³.
• Protokół Tool pozwala modelowi w trakcie generowania wywołać kod aplikacji, żeby pobrać dane albo wykonać akcję, a następnie wpleść wynik w odpowiedź⁴.
• Przed czymkolwiek innym należy sprawdzić SystemLanguageModel.default.availability. Modelu nie ma na urządzeniach, które go nie obsługują, przy wyłączonym Apple Intelligence oraz w trakcie pobierania⁵.
• Okno kontekstowe jest realne i małe. SystemLanguageModel.default.contextSize podaje budżet tokenów dzielony między zapytanie a odpowiedź⁶. Na urządzeniu budżet wynosi 4K tokenów; model na Private Cloud Compute podnosi go do 32K¹⁴. Trzeba to zaplanować, inaczej sesja rzuci wyjątek.
• Wymagany jest iOS 26 i urządzenie obsługujące Apple Intelligence. Poniżej tej granicy framework po prostu nie istnieje. Wersje beta iOS 27 rozszerzają to samo API o obrazy na wejściu, sterowanie wywoływaniem narzędzi per żądanie oraz model serwerowy na Private Cloud Compute¹²¹³¹⁴.

Czym ten framework jest, a czym nie jest

Foundation Models nie jest nakładką na chmurowy endpoint. Model znajduje się na urządzeniu, jest dostarczany razem z systemem operacyjnym i pracuje na Neural Engine. Ten jeden fakt determinuje każdą decyzję projektową w API i każdą decyzję podejmowaną przy jego użyciu.

Do dyspozycji są: generowanie tekstu, streszczanie, klasyfikacja, ekstrakcja, krótkie przeredagowania oraz ustrukturyzowane wyjście — wszystko lokalnie i wszystko za darmo. Czego nie ma: modelu z najwyższej półki. Apple zbudowało model na urządzeniu do skoncentrowanych zadań językowych wewnątrz aplikacji, a nie do otwartego rozumowania, analizy długich dokumentów czy wiedzy o świecie, którą dałoby się odpytywać. Apple mówi to wprost, a to ujęcie ma znaczenie, bo ustawia oczekiwania, które API w przeciwnym razie pozwoli naruszyć¹.

Model myślowy, który chroni przed kłopotami: warto traktować model na urządzeniu jak szybkiego, prywatnego i darmowego stażystę, który świetnie nadaje tekstowi kształt, a fatalnie radzi sobie z faktami. Należy dać mu materiał i jasne zadanie. Nie należy zadawać pytań, na które nie ma on jak odpowiedzieć.

LanguageModelSession: punkt wejścia

Każda interakcja zaczyna się od sesji.

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Summarize this review in one sentence: \(reviewText)")
print(response.content)

Sesja przechowuje stan rozmowy. Każde wywołanie respond(to:) dopisuje treść do bieżącego zapisu rozmowy, więc utrzymywana sesja pamięta wszystko, co było wcześniej. W funkcji czatu dokładnie o to chodzi. Przy niezależnych zadaniach jednorazowych (streść to, sklasyfikuj tamto) lepiej tworzyć świeżą sesję na każde wywołanie, żeby stary kontekst nie przeciekał i nie zjadał budżetu tokenów².

respond(to:) jest async throws. Zawiesza wykonanie na czas pracy modelu i rzuca wyjątek, gdy żądanie przekroczy okno kontekstowe, gdy model jest niedostępny albo gdy mechanizmy zabezpieczające odrzucą treść. Każdy z tych przypadków to realna gałąź do obsłużenia, a nie skrajny przypadek do zignorowania.

Dla responsywnego UI lepiej strumieniować, niż czekać. streamResponse(to:) oddaje częściowe wyjście w miarę, jak model je wytwarza, więc trzysekundowy zastój zmienia się w tekst pojawiający się na oczach użytkownika⁷.

Generowanie sterowane: funkcja, dla której ten framework się opłaca

Oto część warta ceny biletu. Większość integracji z LLM przeznacza jedną trzecią kodu na wyduszanie z modelu poprawnej struktury JSON, a pozostałe dwie trzecie na obronę przed sytuacjami, w których i tak się to nie udaje. Foundation Models kasuje tę robotę.

Wystarczy oznaczyć typ Swift adnotacją @Generable i poprosić sesję o jego wygenerowanie — model zwróci instancję tego typu, wypełnioną i bezpieczną pod względem typów³:

@Generable
struct Recipe {
    @Guide(description: "The dish name")
    let title: String

    @Guide(description: "Ingredients, each as 'quantity item'")
    let ingredients: [String]

    @Guide(description: "Total minutes, start to finish", .range(5...240))
    let minutes: Int
}

let session = LanguageModelSession()
let response = try await session.respond(
    to: "A weeknight pasta for two.",
    generating: Recipe.self
)
let recipe = response.content   // a Recipe, not a String

Żadnego parsowania. Żadnego JSONDecoder. Żadnej pętli ponowień przy zniekształconym wyjściu. Makro @Guide ogranicza poszczególne pola: opis, który model czyta jako instrukcję, oraz opcjonalne limity, takie jak zakres liczbowy czy wyrażenie regularne, do którego wyjście musi pasować⁸. Framework nie prosi modelu grzecznie o liczbę z przedziału od 5 do 240 — ogranicza dekodowanie tak, że pole nie może wrócić inaczej.

Prawdziwą wartością jest dyscyplina, którą to wymusza. Najpierw projektuje się typ wyjściowy, w Swifcie, pod kontrolą kompilatora. Model wypełnia zdefiniowany kontrakt, zamiast zwracać prozę do inżynierii wstecznej. Przy ekstrakcji, wypełnianiu formularzy i każdej funkcji zamieniającej język na dane generowanie sterowane jest różnicą między wersją demo a kodem, który idzie na produkcję.

Jedno ustawienie warto znać: respond(to:generating:) domyślnie ustawia includeSchemaInPrompt na true, czyli wstrzykuje kształt typu do zapytania, żeby nakierować na niego model. Lepiej zostawić to włączone, chyba że model zna już format z treningu albo z wcześniejszych tur sesji; wyłączanie tej opcji dla oszczędności tokenów przy formacie, którego model nigdy nie widział, to prosta droga do śmieci na wyjściu⁹.

Wywoływanie narzędzi: model sięga po kod aplikacji

Generowanie sterowane kształtuje to, co wychodzi. Wywoływanie narzędzi zmienia to, co wchodzi. Narzędzie to fragment kodu aplikacji, który model może uruchomić w trakcie generowania, żeby zdobyć informacje, których nie ma, albo wykonać akcję, a potem dokończyć odpowiedź na podstawie wyniku⁴.

Narzędzie realizuje protokół Tool: name, description, który model czyta, żeby zdecydować, kiedy je wywołać, typ Arguments oznaczony @Generable oraz metodę call(arguments:) wykonującą właściwą pracę⁴:

struct FindContacts: Tool {
    let name = "findContacts"
    let description = "Find a specific number of contacts from the address book"

    @Generable
    struct Arguments {
        @Guide(description: "How many contacts to return", .range(1...10))
        let count: Int
    }

    func call(arguments: Arguments) async throws -> [String] {
        // Fetch contacts, return formatted names.
    }
}

let session = LanguageModelSession(tools: [FindContacts()])
let response = try await session.respond(to: "Draft a dinner invite to three of my contacts.")

Przebieg wygląda tak: model uznaje, że potrzebuje kontaktów, wywołuje narzędzie ze zwalidowanym count, aplikacja zwraca dane, a model pisze zaproszenie z prawdziwymi imionami. Argumenty przychodzą z kontrolą typów, przez tę samą maszynerię generowania sterowanego, więc nigdy nie trzeba wyłuskiwać intencji modelu z wolnego tekstu. Opis narzędzia jest jedyną dźwignią decydującą o tym, kiedy model po nie sięgnie — warto więc pisać go jak dokumentację funkcji, którą inny inżynier, pozbawiony jakiegokolwiek dodatkowego kontekstu, musi przeczytać i poprawnie zastosować.

To także miejsce styku, w którym Foundation Models spotyka się z resztą opowieści o agentach. Narzędzie wywoływane przez model na urządzeniu i App Intent¹¹ wywoływany przez Apple Intelligence to różne powierzchnie o tym samym kształcie: nazwana, opisana i otypowana zdolność. Wystarczy zaprojektować ją raz, żeby wystawić ją w obu miejscach.

Dostępność: sprawdzenie, którego nie wolno pominąć

Model nie zawsze jest na miejscu. Nie ma go na urządzeniach, które nie obsługują Apple Intelligence, przy funkcji wyłączonej przez użytkownika oraz w oknie czasu, w którym system wciąż pobiera zasoby modelu. Kod zakładający, że model istnieje, będzie się wywalał, po cichu degradował albo zawieszał u tej części użytkowników, której nigdy się nie testowało.

Należy sprawdzić SystemLanguageModel.default.availability i rozgałęzić kod w zależności od przyczyny⁵:

switch SystemLanguageModel.default.availability {
case .available:
    // Show the intelligence feature.
case .unavailable(.deviceNotEligible):
    // Hide it. This device will never have the model.
case .unavailable(.appleIntelligenceNotEnabled):
    // Prompt the user to turn on Apple Intelligence.
case .unavailable(.modelNotReady):
    // Downloading or otherwise not ready yet. Try again later.
case .unavailable(let other):
    // Unknown reason. Fail closed.
}

Trzy przyczyny wymagają trzech różnych reakcji produktowych, a ich mieszanie to najczęstszy powód, dla którego takie funkcje sprawiają wrażenie zepsutych. deviceNotEligible jest trwały: funkcję trzeba ukryć i nie zawracać nią głowy. appleIntelligenceNotEnabled to ustawienie kontrolowane przez użytkownika: jednorazowa zachęta jest w porządku. modelNotReady jest tymczasowy: należy ponowić próbę, a nie pokazywać błąd. Ścieżkę niedostępności warto zbudować z taką samą starannością jak scenariusz optymistyczny, bo dla realnej części urządzeń jest ona jedyną ścieżką.

Gdy model jest dostępny i wiadomo, że żądanie zaraz nadejdzie, prewarm() na sesji rozgrzewa model, dzięki czemu pierwsza realna odpowiedź przychodzi szybciej¹⁰. Warto na ekranie, na którym użytkownik zaraz coś zrobi; marnotrawstwo, jeśli wywołuje się je spekulacyjnie.

Praktyka: kompletna funkcja w jednym pliku

Powyższe elementy składają się na realną funkcję przy mniejszej ilości kodu, niż większość warstw sieciowych potrzebuje na jeden endpoint. Poniższy przykład to kompletny, kompilowalny ekran SwiftUI, który zamienia swobodne notatki ze spotkania w ustrukturyzowaną listę zadań: sprawdzenie dostępności, typ wyjściowy @Generable, jedno wywołanie generowania sterowanego i obsłużone trzy gałęzie niedostępności. Każdy symbol pochodzi z opisanej wyżej powierzchni frameworka²³⁵⁸.

import SwiftUI
import FoundationModels

@Generable
struct ActionItems {
    @Guide(description: "One-sentence summary of the meeting")
    let summary: String

    @Guide(description: "Concrete follow-up tasks, each starting with a verb")
    let tasks: [String]

    @Guide(description: "How urgent the follow-ups are overall", .anyOf(["low", "medium", "high"]))
    let urgency: String
}

struct MeetingNotesView: View {
    @State private var notes = ""
    @State private var result: ActionItems?
    @State private var errorMessage: String?

    var body: some View {
        Form {
            TextField("Paste meeting notes", text: $notes, axis: .vertical)
                .lineLimit(6...12)

            Button("Extract action items") {
                Task { await extract() }
            }
            .disabled(notes.isEmpty)

            if let result {
                Section(result.summary) {
                    ForEach(result.tasks, id: \.self) { Text($0) }
                    Text("Urgency: \(result.urgency)")
                }
            }

            if let errorMessage {
                Text(errorMessage).foregroundStyle(.secondary)
            }
        }
    }

    private func extract() async {
        switch SystemLanguageModel.default.availability {
        case .available:
            do {
                let session = LanguageModelSession()
                let response = try await session.respond(
                    to: "Extract the action items from these notes: \(notes)",
                    generating: ActionItems.self
                )
                result = response.content
            } catch {
                errorMessage = "The model could not process these notes."
            }
        case .unavailable(.appleIntelligenceNotEnabled):
            errorMessage = "Turn on Apple Intelligence in Settings to use this feature."
        case .unavailable(.modelNotReady):
            errorMessage = "The model is still downloading. Try again shortly."
        case .unavailable:
            errorMessage = "This feature needs an Apple Intelligence-capable device."
        }
    }
}

W tak małej próbce warto zauważyć trzy szczegóły. Typ wyjściowy jest tutaj API: ActionItems definiuje dokładnie to, co funkcja produkuje, a ograniczenie @Guide na polu urgency sprawia, że łańcuch znaków nie może przyjąć wartości spoza trzech dozwolonych⁸. Sesja powstaje przy każdym wywołaniu, bo każda ekstrakcja jest niezależna; utrzymywana sesja wciągałaby wcześniejsze notatki do budżetu tokenów². Gałęzie niedostępności dają zaś trzy różne doświadczenia użytkownika, a nie jeden ogólny błąd — i to jest różnica między funkcją, która degraduje się uczciwie, a taką, która wygląda na zepsutą. Wystarczy wkleić plik do projektu na iOS 26 i uruchomić go na urządzeniu obsługującym Apple Intelligence, żeby zadziałał.

Okno kontekstowe i moment, w którym przestaje wystarczać

SystemLanguageModel.default.contextSize podaje budżet tokenów, w którym mieści się praca modelu, a budżet ten jest wspólny: zapytanie i odpowiedź razem muszą się zmieścić⁶. Liczba jest mała w porównaniu z modelem chmurowym i przy realnych danych czuć to bardzo szybko. Długi dokument, pełna historia czatu, opasły wynik narzędzia — każde z nich może wysadzić budżet i sprawić, że respond rzuci wyjątek.

Wynikają z tego dwa tryby awarii i obu trzeba zapobiec samodzielnie. Pierwszy to powolne pełzanie: sesja z wieloma turami gromadzi zapis rozmowy, aż kolejna tura przepełni budżet. Zapobiega się temu, otwierając świeże sesje do niepowiązanych zadań i utrzymując oszczędne wejście w każdej turze. Drugi to pojedyncze przerośnięte żądanie: 20-stronicowy PDF się nie zmieści, kropka. Trzeba podzielić go na fragmenty, streścić fragmenty, a potem wnioskować na streszczeniach (klasyczne map-reduce, dobrze znane inżynierom pracującym z LLM) albo przyjąć do wiadomości, że zadanie ma zły kształt dla modelu na urządzeniu.

Okno kontekstowe jest najczystszym sygnałem dla decyzji, która przy tym frameworku naprawdę się liczy: kiedy zostać na urządzeniu, a kiedy je opuścić. Liczby są już jawne: model na urządzeniu pracuje w budżecie 4K tokenów, a serwerowy model na Private Cloud Compute podnosi go do 32K¹⁴. Wszystko, co dotyczy dzielenia na fragmenty, obowiązuje z tymi wartościami w tle.

Co dokładają wersje beta iOS 27

Wszystko powyżej opisuje framework w postaci, w jakiej trafił do iOS 26, i wszystko to nadal obowiązuje. Wersje beta iOS 27 rozszerzają tę samą powierzchnię w czterech kierunkach i żaden z nich nie łamie modelu myślowego z iOS 26¹².

Zapytanie przyjmuje obrazy. Model na urządzeniu zyskuje możliwości Vision: do zapytania wstawia się załącznik z obrazem obok tekstu, a model odpowiada na podstawie obu. Nowe typy to Attachment, ImageAttachmentContent i ImageReference, a załączniki przyjmują UIImage, NSImage, CGImage, typy Core Image, bufory pikseli CoreVideo oraz adresy URL plików¹²¹³. Obrazy działają w dowolnym rozmiarze i dowolnych proporcjach, ale czerpią z tego samego budżetu tokenów co tekst, więc okno 4K na urządzeniu bardzo szybko staje się ograniczeniem projektowym¹³. Pełne omówienie znajduje się w tekście obrazy na wejściu w Foundation Models w iOS 27.

Wywoływanie narzędzi dostaje regulator. GenerationOptions zyskuje toolCallingMode ustawiane per żądanie, które kontroluje sposób interakcji modelu z dołączonymi narzędziami, a framework Vision dostarcza gotowe implementacje OCRTool i BarcodeReaderTool — wystarczy podpiąć je do sesji zamiast pisać własny kod rozpoznawania¹⁵. Szczegóły zachowania opisuje tekst sterowanie wywoływaniem narzędzi w iOS 27.

Większy model o jedną linię dalej. PrivateCloudComputeLanguageModel uruchamia to samo API na serwerowym modelu Apple w Private Cloud Compute, po uzyskaniu uprawnienia (entitlement), z oknem kontekstowym 32K i rozumowaniem, którego model na urządzeniu nie ma¹²¹⁴. Generowanie sterowane i narzędzia działają bez zmian; przełączenie modelu to argument model sesji.

Sesje dostają więcej sterowania. Wersje beta dokładają ContextOptions, TranscriptErrorHandlingPolicy, profile dynamiczne (DynamicInstructions, LanguageModelSession.DynamicProfile) oraz protokół własnego dostawcy modelu językowego (LanguageModel, LanguageModelExecutor), dzięki któremu sesja może napędzać model dostarczony przez aplikację zamiast systemowego¹². Do listy platform dołącza też watchOS w wersji 27.0¹².

Ujęcie, które warto zapamiętać: kod z iOS 26 kompiluje się i zachowuje tak samo na iOS 27. Wersje beta poszerzają to, co może nieść zapytanie, i to, gdzie model może działać; nie zmieniają tego, czym ten framework jest.

Kiedy nie używać Foundation Models

Framework jest darmowy, prywatny i działa offline, więc kusi, żeby sięgać po niego wszędzie. Warto się powstrzymać. Po coś innego należy sięgnąć, gdy:

• Potrzebne jest prawdziwe rozumowanie albo szeroka wiedza o świecie. Model na urządzeniu jest mały z założenia. Otwarte rozumowanie, generowanie kodu i głęboka analiza należą do czołowego modelu w chmurze. Proszenie o nie modelu na urządzeniu kończy się odpowiedziami pewnymi siebie i błędnymi.
• Wejście nie mieści się w oknie kontekstowym, a dzielenie na fragmenty zniszczyłoby sens. Niektóre zadania muszą widzieć całość naraz.
• Potrzebny jest model pod własną kontrolą: konkretny checkpoint, dostrojenie, własne wagi, deterministyczne wersjonowanie niezależne od aktualizacji systemu. Apple wydaje i aktualizuje model według własnego harmonogramu, nie według harmonogramu aplikacji.
• Pracuje się poniżej iOS 26 albo na urządzeniu bez wsparcia. Frameworka po prostu nie ma, a sprawdzenie dostępności powie to przy każdym uruchomieniu.

Dla przypadków lokalnych, których framework nie obejmuje (własny model, własne wagi, trenowanie na urządzeniu), warstwami niżej są Core ML przy stałym, przekonwertowanym modelu, MLX przy modelach o otwartych wagach i własnych dostrojeniach oraz Core AI z iOS 27, gdy potrzebna jest jawna kontrola nad specjalizacją i szeregowaniem zadań. Tam, gdzie naprawdę potrzeba skali, uczciwą odpowiedzią pozostaje Private Cloud Compute albo LLM w chmurze za granicą prywatności. Foundation Models nie zastępuje żadnego z nich. Jest właściwym pierwszym wyborem do skoncentrowanej pracy z językiem na tekście, który już się posiada, i niewłaściwym do wszystkiego innego.

Umiejętnością, którą ten framework nagradza, nie jest rzemiosło układania zapytań. Jest nią wyczucie zakresu: karmienie modelu zadaniami, w których jest dobry, projektowanie typów @Generable obejmujących dokładnie to, co potrzebne, i rozpoznanie chwili, w której praca przerasta urządzenie. Z takimi instynktami model na urządzeniu wykonuje zaskakująco dużo realnej pracy za darmo. Bez nich powstaje funkcja, która psuje się u każdego użytkownika, którego wejście okazało się dłuższe o jeden token.

FAQ

Czy framework Foundation Models od Apple jest darmowy?

Tak. Framework daje aplikacji bezpośredni, darmowy i działający offline dostęp do tego samego modelu na urządzeniu, który napędza Apple Intelligence. Nie ma klucza API, nie ma rachunku za tokeny, nie ma ruchu sieciowego¹.

Jakich urządzeń i jakiej wersji iOS wymaga Foundation Models?

Wymagany jest iOS 26 i urządzenie obsługujące Apple Intelligence. Poniżej tej granicy framework nie istnieje, a nawet na wspieranym systemie modelu nie ma na urządzeniach, które go nie obsługują, przy wyłączonym Apple Intelligence oraz w trakcie pobierania modelu. Przed użyciem należy zawsze sprawdzić SystemLanguageModel.default.availability⁵.

Jak uzyskać ustrukturyzowane wyjście z kontrolą typów zamiast łańcucha znaków?

Wystarczy oznaczyć typ Swift adnotacją @Generable, a model zwróci ten typ — wypełniony i z kontrolą typów — zamiast łańcucha znaków do samodzielnego parsowania. To generowanie sterowane jest jedyną funkcją, która przesądza o sensie sięgania po ten framework³.

Jakie okno kontekstowe ma model Apple działający na urządzeniu?

SystemLanguageModel.default.contextSize podaje budżet tokenów, dzielony między zapytanie a wygenerowaną odpowiedź⁶. Model na urządzeniu oferuje 4K tokenów, a model na Private Cloud Compute — 32K¹⁴. Długie dokumenty i długie historie wielu tur przekroczą budżet lokalny, więc trzeba planować pod ten limit, inaczej sesja rzuci wyjątek.

Czy Foundation Models działa offline i czy wysyła dane do Apple?

Działa w całości na urządzeniu, na Neural Engine. Żadne dane nie opuszczają urządzenia i nie jest potrzebna żadna komunikacja z serwerem — właśnie dlatego framework nadaje się do funkcji, które kiedyś wymagały LLM w chmurze i przeglądu prywatności¹.

Czy model na urządzeniu może wywołać mój kod w trakcie generowania?

Tak. Protokół Tool pozwala modelowi uruchomić kod aplikacji, żeby w trakcie generowania pobrać dane albo wykonać akcję, a potem wpleść wynik w odpowiedź⁴.

Kiedy nie należy używać Foundation Models?

Po coś innego trzeba sięgnąć wtedy, gdy potrzebny jest model z najwyższej półki: otwarte rozumowanie, generowanie kodu, analiza długich dokumentów albo wiedza o świecie. Apple zbudowało model na urządzeniu do skoncentrowanych zadań językowych wewnątrz aplikacji, więc oczekiwanie od niego inteligencji ogólnej kończy się odpowiedziami pewnymi siebie i błędnymi¹.

Co iOS 27 dokłada do Foundation Models?

Wersje beta iOS 27 dodają obrazy na wejściu (załączniki w zapytaniu, tworzone m.in. z UIImage, CGImage czy buforów pikseli), sterowanie wywoływaniem narzędzi per żądanie przez GenerationOptions, gotowe narzędzia Vision OCRTool i BarcodeReaderTool oraz PrivateCloudComputeLanguageModel do uruchamiania tego samego API na serwerowym modelu Apple z kontekstem 32K^12131415. Kod z iOS 26 działa bez zmian.