Writing Tools API: Jak aplikacje integrują się z warstwą pisania Apple Intelligence

Warstwa pisania Apple Intelligence, oferowana pod nazwą Writing Tools, jest dostępna na każdym urządzeniu z iOS 18+ z włączoną funkcją Apple Intelligence. Użytkownik zaznacza tekst, dotyka menu Writing Tools i otrzymuje korektę, przepisanie (przyjazne, profesjonalne, zwięzłe), streszczenie, generowanie list i tabel oraz (od iOS 18.2) generatywne komponowanie¹. Funkcjonalność znajduje się na poziomie systemu, a nie w pojedynczej aplikacji, a użytkownik oczekuje, że będzie działać w każdym polu wprowadzania tekstu.

Aplikacje korzystające z UITextView, NSTextView lub WKWebView otrzymują integrację bez pisania kodu, pod warunkiem że widok tekstu działa na TextKit 2². Aplikacje z niestandardowymi silnikami tekstowymi potrzebują API UIWritingToolsCoordinator, aby podpiąć swoją pamięć tekstową i renderowanie do doświadczenia Writing Tools. Niniejszy wpis przechodzi przez powierzchnię API w odniesieniu do dokumentacji Apple, nazywa trzy poziomy adopcji i omawia, kiedy zrezygnować (ponieważ nie każde pole tekstowe powinno akceptować generatywne przepisywanie).

TL;DR

• Standardowe widoki tekstu (UITextView, NSTextView, WKWebView) na TextKit 2 otrzymują Writing Tools za darmo, z pełnym doświadczeniem inline-rewrite-with-animation².
• Niestandardowe widoki tekstu wykorzystują UITextInteraction, aby uzyskać integrację z menu kontekstowym/wywoływanym bez dodatkowego kodu; pełna integracja inline wymaga API UIWritingToolsCoordinator³.
• UIWritingToolsBehavior to pojedyncza właściwość typu enum, która kontroluje poziom doświadczenia: .complete, .limited lub .none⁴. Wartość .default to żądanie, które system rozstrzyga w czasie wykonania na jedną z tych trzech; nie jest to czwarty poziom. Dla wrażliwego tekstu (hasła, edytory kodu źródłowego, pola czatu, których użytkownicy nie chcą przepisywać) należy ustawić .none.
• allowedWritingToolsResultOptions pozwala aplikacjom zadeklarować, które kształty wyjściowe akceptują (zwykły tekst, sformatowany tekst, listy, tabele lub .presentationIntent w iOS 26), tak aby Writing Tools nie zwracały treści, których aplikacja nie może wyrenderować⁵.
• Powiązanie z agent-workflow: Writing Tools to powierzchnia Apple Intelligence, podobnie jak App Intents i Foundation Models, ale działa na warstwie wprowadzania tekstu, a nie na warstwie akcji.

Co Writing Tools faktycznie robi

Menu Writing Tools w iOS 18+ udostępnia zestaw operacji na zaznaczonym tekście. Bieżący publiczny zestaw, zgodnie z dokumentacją deweloperską Apple oraz wprowadzeniem na WWDC 2024⁶:

Korekta. Poprawia gramatykę, ortografię, interpunkcję i dobór słów. Zwraca diff, który użytkownik może zaakceptować, odrzucić lub przejść krok po kroku.

Przepisanie. Trzy zdefiniowane tony (przyjazny, profesjonalny, zwięzły) plus niestandardowy prompt „opisz swoją zmianę”. Model przepisuje zaznaczony tekst w wybranym tonie.

Streszczenie. Długi tekst staje się krótki. Warianty obejmują „streszczenie”, „kluczowe punkty”, „lista”, „tabela”. Użytkownik wybiera kształt.

Komponowanie. Generatywne pisanie z promptu (iOS 18.2+). Użytkownik opisuje, czego chce; model generuje nowy tekst, zamiast przepisywać istniejący.

Modelem działającym za Writing Tools jest model bazowy Apple działający na urządzeniu na obsługiwanym sprzęcie, z awaryjnym fallbackiem do prywatnej chmury dla większych żądań¹. Tekst użytkownika nigdy nie trafia do strony trzeciej. Historia prywatności jest częścią propozycji wartości.

Trzy poziomy adopcji

Aplikacje wpadają do jednego z trzech koszyków w zależności od tego, ile integracji z Writing Tools potrzebują.

Poziom 1: Standardowy widok tekstu (zero kodu)

Aplikacje używające UITextView, NSTextView lub WKWebView do wprowadzania tekstu otrzymują Writing Tools bez pisania jakiegokolwiek kodu, pod warunkiem że widok tekstu używa TextKit 2². System obsługuje menu, interfejs przepisywania inline, animację oraz inline’owe podświetlenia korekty. Zadaniem aplikacji jest użycie standardowego widoku tekstu.

let textView = UITextView()
textView.text = "Original content."
textView.isEditable = true
// Writing Tools just works.

Wymóg TextKit 2 ma znaczenie, ponieważ TextKit 1 wykorzystuje inną architekturę układu, która nie obsługuje animacji inline-rewrite. Nowe aplikacje celujące w iOS 18+ powinny domyślnie używać TextKit 2; starsze aplikacje mogą wymagać kroku migracji. UITextView domyślnie używa TextKit 2 na iOS 16+, gdy jest inicjowany przez Interface Builder lub nowoczesny inicjalizator.

Poziom 2: Niestandardowy widok tekstu z UITextInteraction (tylko menu kontekstowe)

Aplikacje z niestandardowymi widokami tekstu mogą wykorzystać UITextInteraction, aby uzyskać Writing Tools w pasku wywołania i menu kontekstowym bez dodatkowego kodu⁷. Użytkownik może wywołać Writing Tools, zobaczyć interfejs panelowy do korekty/przepisania/streszczenia oraz zaakceptować lub odrzucić wynik. Wynik jest dostarczany do aplikacji przez standardowy przepływ wklejenia/zastąpienia.

Integracja jest częściowa: aplikacja nie otrzymuje animacji inline ani inline’owych podświetleń korekty. Te wymagają pełnego koordynatora. Dla większości aplikacji z niestandardowymi widokami tekstu adopcja UITextInteraction jest wystarczająca.

Poziom 3: UIWritingToolsCoordinator (pełne doświadczenie inline)

Aplikacje, które chcą pełnego doświadczenia Writing Tools z niestandardową pamięcią tekstową, wykorzystują UIWritingToolsCoordinator (lub NSWritingToolsCoordinator na macOS)³. Koordynator zarządza dwukierunkową komunikacją między Writing Tools a aplikacją:

• Aplikacja dostarcza koordynatorowi kontekst tekstowy (NSAttributedString reprezentujący bieżący wybór plus opcjonalne otaczające akapity).
• Koordynator zarządza interfejsem panelowym i animacją inline.
• Koordynator wywołuje delegata, aby wstawić, zastąpić lub animować zmiany tekstu w pamięci tekstowej aplikacji.

Kluczowe metody delegata na UIWritingToolsCoordinator.Delegate, zweryfikowane względem nagłówków SDK iOS 26³:

• writingToolsCoordinator(_:requestsContextsForScope:completion:). Metoda pobierania danych. Writing Tools prosi aplikację o odpowiednie konteksty tekstowe (każdy to NSAttributedString plus zakres zaznaczenia) w danym zakresie. Aplikacja buduje konteksty ze swojej pamięci tekstowej i je zwraca.
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:). Metoda robocza dla zmian tekstu. Writing Tools proponuje nowy tekst dla zakresu w obrębie kontekstu; aplikacja stosuje zmianę w swojej pamięci i potwierdza.
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:). Wywoływana, gdy animacja tekstu (przejście morfingu między oryginalnym a przepisanym tekstem) zakończy się dla zakresu. Nie jest to sygnał zakończenia sesji.
• writingToolsCoordinator(_:willChangeToState:completion:). Sygnał cyklu życia sesji. Koordynator przechodzi przez stany (idle, interactive, noninteractive itd.) i powiadamia delegata przed każdym przejściem. To tutaj aplikacja reaguje na „rozpoczęcie sesji” i „zakończenie sesji”.

API koordynatora jest zaprojektowany dla zserializowanych silników tekstowych (w stylu TextKit), edytorów ukształtowanych jak dokumenty oraz edytorów kodu, które chcą częściowej integracji. Sesja Apple „Dive deeper into Writing Tools” na WWDC 2025⁸ przechodzi przez przypadki wieloparagrafowe, wielostylowe. Należy zauważyć, że UIWritingToolsCoordinator po raz pierwszy ukazał się jako publiczne API w iOS 18.2; iOS 26 pogłębia go, a nie wprowadza.

Właściwość zachowania: UIWritingToolsBehavior

Najważniejszą pojedynczą kontrolą włączania/wyłączania jest właściwość writingToolsBehavior na UITextView, UITextField i każdym widoku zgodnym z UITextInputTraits⁴:

textView.writingToolsBehavior = .complete   // full inline experience
textView.writingToolsBehavior = .limited    // panel-only (no inline rewrite)
textView.writingToolsBehavior = .none       // disabled entirely
textView.writingToolsBehavior = .default    // request system default

Trzy wartości to rzeczywiste poziomy doświadczenia; .default to żądanie, które system rozstrzyga na jedną z pozostałych trzech na podstawie cech wejścia tekstowego:

• .complete. Pełne doświadczenie Writing Tools, w tym animacja inline rewrite, inline’owe podświetlenia korekty oraz panel. Najlepsze dla edytorów tekstu długiej formy (kompozytor Mail, Notatki, edytory dokumentów).
• .limited. Doświadczenie tylko panelowe. Użytkownik otrzymuje Writing Tools w menu, ale przepisania odbywają się w panelu, a nie inline. Najlepsze dla krótszych pól tekstowych, gdzie animacja inline byłaby nieproporcjonalna.
• .none. Writing Tools jest wyłączone dla tego wejścia tekstowego. Należy używać dla wrażliwych treści.
• .default. Żądanie, a nie poziom. Nagłówek dokumentuje rozstrzygniętą wartość jako zawsze będącą jedną z .none, .limited lub .complete; właściwość tylko-do-odczytu behavior nigdy nie zwraca .default. Większość aplikacji powinna pozostawić właściwość na .default, chyba że istnieje konkretny powód, aby ją zmienić.

Kiedy zrezygnować

Trzy kategorie wejść tekstowych, gdzie .none jest właściwym wyborem:

Hasła i wrażliwe dane uwierzytelniające. Pole hasła nigdy nie powinno oferować jako opcji „przepisz to przyjaznym tonem”. Użytkownik wprowadza dosłowny tekst, który nie może zostać przekształcony. UITextField Apple z isSecureTextEntry = true już domyślnie wyłącza Writing Tools; jawne .none to dodatkowe zabezpieczenie.

Edytory kodu źródłowego. Edytor kodu SwiftUI lub edytor Markdown dla treści technicznych nie jest ulepszony przez prośbę o przepisanie zaznaczonego kodu w „profesjonalnym” tonie. Ścieżki przepisywania Writing Tools są dostrojone do języka naturalnego, a nie do struktur składniowych. Należy ustawić .none na widokach tekstu, których treść nie jest językiem naturalnym.

Pola czatu, gdzie przepisanie zmienia intencję. Aplikacja do wiadomości lub pole komentarzy, gdzie dokładne słowa użytkownika mają znaczenie (dla tonu, głosu, odpowiedzialności), może chcieć pominąć przepisanie, zachowując korektę. Bieżące API Writing Tools nie pozwala na bramkowanie per-akcja; wartość .none wyłącza całe doświadczenie. Pragmatycznym ruchem jest .limited (tylko panel, który użytkownik musi celowo wywołać) dla pól, gdzie przepisanie jest okazjonalnie odpowiednie, ale nie powinno być inline’owym wyborem domyślnym.

allowedWritingToolsResultOptions deklaruje, co aplikacja może wyrenderować

Subtelniejsza kontrola znajduje się na UITextInputTraits.allowedWritingToolsResultOptions (również udostępniona jako UITextView.allowedWritingToolsResultOptions)⁵. Właściwość jest zestawem opcji UIWritingToolsResultOptions, który deklaruje, jakie kształty treści widok tekstu aplikacji może wyrenderować:

• .plainText. Widok tekstu obsługuje zwykły tekst (bez atrybutów formatowania).
• .richText. Obsługuje sformatowany tekst (pogrubienie, kursywa itd.).
• .list. Obsługuje renderowanie list (punktory, numerowanie).
• .table. Obsługuje renderowanie tabel.
• .presentationIntent (iOS 26+). Obsługuje bogatą semantyczną adnotację intencji (nagłówki, blokowe cytaty, bloki kodu) przy użyciu typów PresentationIntent z frameworku Foundation, co stanowi bogatszą powierzchnię niż zwykły sformatowany tekst.

Po ustawieniu Writing Tools ogranicza swoje wyjście do kształtów akceptowanych przez aplikację. Edytor tylko zwykłego tekstu deklarujący tylko .plainText nie otrzyma sugestii „zrób z tego tabelę”. Edytor sformatowanego tekstu deklarujący .richText i .list, ale nie .table, otrzyma wyjście listy, ale nie wyjście tabeli.

Wartością domyślną jest .default, co pozwala systemowi wybrać na podstawie cech widoku tekstu. Należy ustawić właściwość jawnie, gdy automatyczne wykrywanie produkuje niewłaściwe kształty (widok tekstu, który mógłby wyrenderować sformatowany tekst, ale model danych aplikacji przechowuje tylko zwykły).

Gdzie ląduje wyjście

Dla aplikacji poziomu 1 (standardowe widoki tekstu) wyjście zastępuje zaznaczenie inline poprzez standardową maszynerię widoku tekstu. Żaden kod aplikacji nie jest zaangażowany.

Dla aplikacji poziomu 2 (niestandardowe widoki z UITextInteraction) wyjście dociera przez standardowy przepływ wklejania. Implementacja protokołu UITextInput widoku tekstu jest tym, co przetwarza zmianę. Aplikacje, które poprawnie zaimplementowały UITextInput, otrzymują integrację „za darmo” po dodaniu UITextInteraction.

Dla aplikacji poziomu 3 (pełny koordynator) wyjście przychodzi przez metodę delegata replaceRange:. Aplikacja stosuje zmianę w swojej pamięci tekstowej, zwraca nowe granice tekstu w handlerze zakończenia, a koordynator obsługuje przejście wizualne. Aplikacja pozostaje źródłem prawdy dla pamięci tekstowej.

Co dodało głębsze zanurzenie WWDC 2025

Sesja „Dive deeper into Writing Tools” na WWDC 2025⁸ rozszerzyła API z iOS 18 wzdłuż trzech osi wartych nazwania:

Kontekst wieloparagrafowy. Aplikacje mogą teraz dostarczać więcej otaczającego kontekstu koordynatorowi, pozwalając Writing Tools operować na zaznaczeniach, które zależą od otaczających akapitów (zdanie, którego znaczenie zależy od akapitu powyżej, na przykład).

Niestandardowe prompty przepisywania. Ścieżka „opisz swoją zmianę”, która była w iOS 18.2 w wersji beta, stała się w pełni publiczna, z hakami delegata dla aplikacji, które chcą sprawdzić lub przekształcić prompt użytkownika przed przekazaniem go do modelu.

Lepsza obsługa treści mieszanej. Zaznaczenia tekstu obejmujące wiele stylów lub zawierające osadzone obrazy teraz przepływają przez koordynatora z osadzoną treścią zachowaną jako zakresy nieprzezroczyste. Koordynator nie próbuje przepisać inline’owego obrazu; zachowuje go i przepisuje otaczający tekst.

Delty są rozszerzeniami modelu z iOS 18, a nie zamiennikiem. Aplikacje, które wdrożyły API Writing Tools z iOS 18, nadal działają; iOS 26 odblokowuje głębszą integrację dla aplikacji, które jej potrzebują.

Powiązanie z agent-workflow

Writing Tools to jedna z trzech powierzchni Apple Intelligence, z którymi aplikacja innej firmy może się integrować:

Writing Tools. Warstwa wprowadzania tekstu. Użytkownik zaznacza tekst, prosi system o jego przekształcenie, otrzymuje wynik inline. Aplikacje uczestniczą, udostępniając poprawnie sformułowane widoki tekstu i (opcjonalnie) implementując koordynatora. Użytkownik wywołuje; aplikacja otrzymuje wynik.

App Intents. Warstwa akcji. Użytkownik (lub agent) prosi Apple Intelligence o wykonanie akcji; system kieruje żądanie do zarejestrowanej intencji w aplikacji. Aplikacje uczestniczą, deklarując typy AppIntent, schematy parametrów i typy wyników. Omówione w App Intents to nowe API Apple do Twojej aplikacji.

Foundation Models. Warstwa LLM czasu wykonania. Aplikacje wywołują LLM na urządzeniu bezpośrednio przez framework Foundation Models w celu generowania w aplikacji. Omówione w Foundation Models on-device LLM.

Trzy powierzchnie się komponują. Aplikacja do robienia notatek mogłaby używać Writing Tools (do przepisywania na podstawie zaznaczenia użytkownika), App Intents (do „streść moje notatki z wczoraj”) oraz Foundation Models (do funkcji generatywnej w aplikacji, takiej jak automatyczne tagowanie). Każda warstwa jest odrębną integracją z odrębnym modelem mentalnym użytkownika.

Wpis App Intents vs MCP Tools omawia, kiedy udostępnić akcję przez App Intents (Apple Intelligence), a kiedy przez serwer MCP (ogólne agenty). Writing Tools znajduje się poza tym pytaniem; jest powierzchnią na poziomie systemu, która nie ma odpowiednika w postaci agenta innej firmy w pokryciu klastra.

Co ten wzorzec oznacza dla aplikacji iOS 26+

Trzy wnioski.

1. Domyślnie używaj standardowych widoków tekstu i TextKit 2. Większość aplikacji nie potrzebuje API koordynatora. Jeśli wprowadzanie tekstu w aplikacji to UITextView lub WKWebView, Writing Tools działa bez kodu; praca polega na migracji do TextKit 2, jeśli aplikacja nadal działa na TextKit 1.

2. Świadomie ustawiaj writingToolsBehavior = .none dla wrażliwych pól. Hasła, edytory kodu, pola dokładnego tekstu. Wartość domyślna stara się robić właściwą rzecz, ale jawne ustawienie to dająca się obronić decyzja produktowa, którą zespół potrafi uzasadnić.

3. Sięgaj po UIWritingToolsCoordinator tylko wtedy, gdy silnik tekstowy aplikacji jest naprawdę niestandardowy. Edytory Markdown, edytory kodu, aplikacje dokumentowe z niestandardowym renderowaniem, widoki tekstu w stylu terminala. Koordynator to realna inwestycja inżynierska; poziom 2 (UITextInteraction) jest wystarczający dla większości niestandardowych widoków.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie LLM czasu wykonania vs narzędziowego; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; Dwa serwery MCP; hooki dla rozwoju Apple; Live Activities; runtime watchOS; wnętrzności SwiftUI; przestrzenny model mentalny RealityKit; dyscyplina schematów SwiftData; wzorce Liquid Glass; wieloplatformowe wydawanie; macierz platform; framework Vision; Symbol Effects; inferencja Core ML; o czym odmawiam pisać. Hub znajduje się w serii Apple Ecosystem. Dla szerszego kontekstu iOS-with-AI-agents, zobacz przewodnik iOS Agent Development.

FAQ

Czy potrzebuję Apple Intelligence, aby testować Writing Tools w mojej aplikacji?

Aby przetestować pełne doświadczenie użytkownika, tak. Menu Writing Tools widoczne dla użytkownika pojawia się tylko na urządzeniach z włączonym Apple Intelligence (iPhone 15 Pro lub nowszy, M1 Mac lub nowszy, z iOS 18+ / macOS 15+). W celach deweloperskich można testować integrację API na każdym symulatorze lub urządzeniu z iOS 18+, sprawdzając, czy widok tekstu udostępnia isWritingToolsActive i czy metody delegata są poprawnie podpięte; menu systemowe po prostu się nie pojawi bez dostępnego Apple Intelligence.

Co się stanie, jeśli nic nie zrobię w sprawie Writing Tools w mojej aplikacji iOS 18+?

Dla standardowych widoków tekstu (UITextView, WKWebView) Writing Tools pojawia się automatycznie. Dla niestandardowych widoków tekstu bez UITextInteraction Writing Tools nie pojawia się w menu, a użytkownicy nie mogą go wywołać na tekście w Twojej aplikacji. Nicnierobienie jest dającym się obronić wyborem domyślnym dla widoków, w których Writing Tools byłoby nieodpowiednie (pola haseł, edytory kodu); dla ogólnego wprowadzania tekstu nicnierobienie oznacza pominięcie funkcji systemowej, której użytkownicy będą szukać.

Jaka jest różnica między .complete a .limited?

.complete uruchamia przepisania Writing Tools inline z animacją, która morfuje oryginalny tekst w przepisanie, plus inline’owe podświetlenia korekty. .limited uruchamia Writing Tools przez interfejs panelowy; użytkownik widzi przepisanie na osobnej powierzchni i decyduje, czy je zastosować. Należy używać .complete dla edytorów tekstu długiej formy, gdzie animacja inline wzmacnia przepływ edycji; .limited dla krótszych pól tekstowych, gdzie panel sprawia właściwe wrażenie.

Czy mogę dostosować prompty lub zachowanie modelu Writing Tools?

Model i prompty są kontrolowane przez system. Aplikacje nie mogą wstrzykiwać niestandardowych zachowań przepisywania do menu Writing Tools. Dla funkcji generatywnego pisania specyficznych dla aplikacji należy używać frameworku Foundation Models bezpośrednio (omówione w Foundation Models on-device LLM) i udostępniać funkcję przez własny interfejs.

Jak Writing Tools obsługuje mieszane zaznaczenia (tekst + obraz)?

Zgodnie z „Dive deeper into Writing Tools” z WWDC 2025⁸, mieszane zaznaczenia obejmujące osadzoną treść (obrazy, załączniki) przepływają przez koordynatora z osadzoną treścią zachowaną jako zakresy nieprzezroczyste. Writing Tools przepisuje otaczający tekst, ale nie próbuje przekształcić osadzonej treści. Dla aplikacji używających koordynatora delegat otrzymuje ładunki proponowanego tekstu, w których zakres osadzonej treści jest oznaczony jako niezmieniony.

Bibliografia