Trzy powierzchnie: człowiek, Apple Intelligence, agent

Każda znacząca funkcja w aplikacji iOS na iOS 26+ staje obecnie wobec maksymalnie trzech powierzchni, z których może zostać wywołana. Ta sama funkcja Swift, która rejestruje wypitą szklankę wody, może zostać uruchomiona przez człowieka stukającego w przycisk, przez Apple Intelligence kierujące żądanie do Siri lub przez zewnętrznego agenta (Claude Code, Cursor, ChatGPT) wywołującego narzędzie MCP. Trzech różnych wywołujących, trzy różne obowiązki, trzy różne powierzchnie renderowania. Funkcja jest ta sama; powierzchnie nie.

Wiele błędów architektonicznych w iOS bierze się z projektowania pod jedną powierzchnię, a następnie wpychania funkcji na siłę w pozostałe. Przepływy interfejsu wyciekają do odpowiedzi Siri; narzędzia agenta poprawne dla programisty stają się zagrożeniem dla użytkowników końcowych; funkcje LLM działające na urządzeniu zakładają posiadanie kontekstu na poziomie chmury. W ramach klastra mapowano te powierzchnie w poszczególnych wpisach. Niniejszy wpis jest syntezą: trzy powierzchnie, ich różnice, reguła routingu oraz to, jak musi wyglądać warstwa domenowa aplikacji, by obsłużyć wszystkie trzy bez kompromisów po którejkolwiek stronie.

Model myślowy: można wybrać dowolną funkcję domenową. Należy zapytać, która z trzech powierzchni powinna móc ją wywołać. Należy zapytać, która może. Należy zapytać, czego każda powierzchnia potrzebuje od tej funkcji i co funkcja jej oddaje. Odpowiedzi kształtują architekturę.

TL;DR

• Trzy powierzchnie: człowiek (widoki SwiftUI, stuknięcia, gesty, ekran), Apple Intelligence (App Intents, Siri, Shortcuts, Spotlight), agent (serwery MCP, zewnętrzne hosty LLM).
• Każda powierzchnia ma odmienne obowiązki: poziom zaufania, budżet opóźnień, lokalizację renderowania, semantykę trwałości, obsługę błędów, wymagania dostępności.
• Właściwa architektura to warstwa domenowa pod powierzchniami. Każda powierzchnia jest cienkim adapterem nad tymi samymi funkcjami Swift; funkcja przyjmuje typowany argument Caller, dzięki czemu może rozgałęziać się na regułach przekrojowych (limity wywołań, audyt, potwierdzenia), nie znając szczegółów protokołu danej powierzchni.
• Nie każda funkcja obsługuje wszystkie trzy powierzchnie. Decyzja o tym, którą powierzchnię obsłużyć, jest wyborem projektowym. Ukrywanie funkcji przed powierzchniami, które nie powinny ich mieć, jest tak samo decyzją produktową, jak udostępnianie ich powierzchniom, które powinny je mieć.

Powierzchnia pierwsza: człowiek

Powierzchnia człowieka to ekran. Użytkownik patrzy na aplikację, stuka, przewija, przeciąga, przesuwa palcem, pisze. Frameworkiem jest SwiftUI (lub UIKit, a w przypadku niektórych zastosowań RealityKit na visionOS). Renderowanie odbywa się na urządzeniu użytkownika, w procesie aplikacji, zgodnie z wybranym przez użytkownika schematem kolorów, rozmiarem Dynamic Type i ustawieniami dostępności.¹

Czego powierzchnia człowieka potrzebuje od funkcji:

• Widoczny element interakcji. Przycisk, wiersz listy, gest przeciągnięcia, menu kontekstowe. Funkcja musi być odkrywalna poprzez nawigację aplikacji i stylizowana spójnie z resztą interfejsu.
• Sprzężenie zwrotne w czasie rzeczywistym. Każda interakcja wymaga natychmiastowej widocznej reakcji. Przycisk uruchamiający długotrwałą operację musi pokazać wskaźnik postępu, stan włączenia/wyłączenia, animację.
• Dostępność. Etykiety VoiceOver, obsługa Dynamic Type, kontrast kolorów, alternatywy dla osób z ograniczoną kontrolą motoryczną. Powierzchnia człowieka ma najbardziej wymagające wymagania dostępności, ponieważ użytkownik wchodzi w bezpośrednią interakcję z renderowaniem.
• Widoczność błędów. Błędy trafiają do widoku użytkownika. Nieudany zapis pokazuje alert; przekroczony limit czasu sieci pokazuje opcję ponowienia; odmowa uprawnień pokazuje link do ustawień.

Co powierzchnia człowieka oddaje funkcji:

• Jednoznaczną intencję użytkownika. Użytkownik stuknął konkretny przycisk; funkcja wie dokładnie, o co poproszono. Nie ma warstwy wnioskowania.
• Ciasny budżet opóźnień. Stuknięcie, na które reakcja zajmuje więcej niż kilkaset milisekund, sprawia wrażenie zepsutego. Funkcja musi być albo szybka, albo zaprojektowana tak, by natychmiast pokazać postęp.
• Brak zewnętrznej władzy. Użytkownik znajduje się w aplikacji; użytkownik jest agentem w najluźniejszym sensie (to człowiek napędza akcję). Brak zewnętrznego LLM, brak agenta systemowego, jedynie ręce użytkownika.

Powierzchnia człowieka jest najdłużej istniejącą z trzech. Każdy framework iOS, każdy wzorzec projektowy i reguła dostępności, jakie platforma zgromadziła od czasu iOS 7, służy tej powierzchni. Pozostałe dwie są na tyle nowe, że wzorce wciąż się ustalają.

Powierzchnia druga: Apple Intelligence

Powierzchnia Apple Intelligence to agent systemowy. Siri, Shortcuts, Spotlight, stos sugestii systemowych. Użytkownik mówi, wpisuje coś w Spotlight lub łańcuchowo wykonuje akcję w Shortcuts; system kieruje żądanie przez framework App Intents, znajduje pasujący AppIntent, rozwiązuje parametry i uruchamia ciało perform() intencji. Frameworkiem jest App Intents.²

Czego powierzchnia Apple Intelligence potrzebuje od funkcji:

• Typowanego schematu. Typy AppIntent deklarują właściwości @Parameter; typy AppEntity zapewniają trwałą tożsamość obiektom, o których system może mówić; typy AppEnum nazywają zamknięte zbiory opcji. System odczytuje schemat w czasie instalacji.
• Tożsamości, która przetrwa proces aplikacji. Wpis o wodzie, który użytkownik zarejestrował przez Siri wczoraj, powinien być dostępny przez Siri dzisiaj. Model AppEntity daje systemowi stabilny sposób mówienia o obiektach między sesjami.
• Cichej obsługi błędów. Błędy nie trafiają do widoku użytkownika; trafiają do odpowiedzi Siri, danych wyjściowych Shortcuts lub wyniku Spotlight. Format błędu, jakiego oczekuje system, jest strukturalny (Apple AppIntentError plus rzucenia zgodne z LocalizedError), nie wizualny.
• Idempotentności przy ponownych wywołaniach. System może ponownie wywołać intencję podczas łańcucha Shortcut lub po częściowej awarii. Funkcje, które mutują stan, muszą być bezpieczne przy powtórnych wywołaniach lub muszą zwrócić jasną semantykę „już wykonane”.

Co powierzchnia Apple Intelligence oddaje funkcji:

• Faktyczną tożsamość użytkownika. System wie, kim jest użytkownik, uwierzytelnił go przez OS i uruchamia intencję w jego kontekście. Funkcja nie musi weryfikować tożsamości poza tym, co zapewnia OS.
• Renderowanie na poziomie systemu. Wynik zwracany przez intencję jest formatowany przez system w odpowiednią obudowę (baner ekranu blokady, karta odpowiedzi Siri, dane wyjściowe Shortcuts). Aplikacja nie kontroluje sposobu prezentacji odpowiedzi.
• Odkrywalność bez uruchomionego kodu. App Intents można wywołać, gdy aplikacja nie jest uruchomiona. System odczytuje schemat i proaktywnie wystawia funkcję.

Poziom zaufania: Apple Intelligence to własny agent Apple jako pierwszej strony. Użytkownik go nie konfigurował; system to zrobił. Użytkownik ufa OS; OS ufa schematowi App Intents, jaki aplikacja przesłała przez recenzję. Łańcuch zaufania to OS → aplikacja. App Intents wspierają requestConfirmation(...) oraz potwierdzenia w trybie pierwszoplanowym, więc funkcje wymagające „czy na pewno?” mogą tam technicznie istnieć; to osąd produktowy, a nie ograniczenie platformy, decyduje, czy potwierdzenia operacji wysokiego ryzyka należą do tury Siri, czy do własnego ekranu aplikacji. Wszystko nieodwracalne (usunięcie konta, destrukcyjne zbiorcze edycje, płatność) jest zwykle bezpieczniejsze na powierzchni człowieka, choć App Intents potrafią poprosić o potwierdzenie.³

Powierzchnia trzecia: agent

Powierzchnia agenta to każdy inny system napędzany LLM, który chce operować domeną aplikacji. Claude Desktop, Claude Code, Cursor, aplikacja desktopowa ChatGPT, Codex CLI, własne uprzęże agentowe. Frameworkiem jest Model Context Protocol: serwer MCP wystawia domenę aplikacji przez metody tools/call zgodne z JSON-RPC; host LLM odkrywa narzędzia na początku sesji i wywołuje je po nazwie, przekazując ładunek JSON.⁴

Czego powierzchnia agenta potrzebuje od funkcji:

• Kontraktu JSON-RPC. Nazwa narzędzia, opis, inputSchema, opcjonalnie outputSchema. Agent czyta opis, by zdecydować, czy wywołać; podąża za schematem, by sformatować argumenty.
• Użytecznego opisu. Model decyduje o użyciu narzędzia na podstawie jego opisu. Należy traktować opis jak docstring, który ma odczytać inny programista (model). Niejasne opisy prowadzą do niewłaściwego wyboru narzędzi.
• Błędów o dwóch kształtach. Błędy wykonania narzędzia zwracane są jako blok treści plus isError: true w wyniku narzędzia, który czyta model. Błędy na poziomie protokołu (źle sformułowane żądanie, brakujące narzędzie, awaria transportu) zwracane są jako standardowe odpowiedzi error JSON-RPC obsługiwane przez hosta. Autor narzędzia odpowiada za pierwsze; protokół za drugie.
• Bezstanowej lub jawnie stanowej semantyki. MCP jest stanowy na warstwie protokołu (cykl życia sesji, identyfikatory sesji w Streamable HTTP), ale trwała tożsamość domenowa to odpowiedzialność po stronie serwera, a nie gwarancja na poziomie protokołu. Jeśli ten sam identyfikator ma oznaczać to samo między sesjami, serwer musi to wymusić.

Co powierzchnia agenta oddaje funkcji:

• Uwierzytelnienie hosta, a nie użytkownika. Zaufanie pochodzi od tego, kto wdrożył serwer MCP. Lokalne stdio programisty: uprawnienia własnego systemu plików programisty. Dostępne z internetu HTTP: cokolwiek wymusza serwer. Funkcja musi zakładać, że deklaracja tożsamości jest taka, jaką podał serwer.
• Tolerancję na zmienne opóźnienia. Host może czekać dłużej niż powierzchnia człowieka czy powierzchnia Apple Intelligence. Wywołanie narzędzia trwające trzydzieści sekund jest akceptowalne na powierzchni agenta i nieakceptowalne na pozostałych.
• Brak powierzchni renderowania. Wynikiem jest tekst lub dane strukturalne, które interpretuje model. Bez obudowy, bez UI, bez formatowania systemowego.

Poziom zaufania: serwer MCP to kontrakt programisty dotyczący tego, kto może go wywołać. Dwa wdrożenia tego samego serwera (lokalne stdio do rozwoju, HTTP w internecie dla użytkowników końcowych) mają bardzo różne poziomy zaufania i wymagają bardzo różnych zabezpieczeń. Protokół jest ten sam; wdrożenie jest architekturą. Omówiono to szczegółowo w App Intents vs MCP: pytanie o routing oraz Kiedy LLM żyje w aplikacji, a kiedy w narzędziach.⁵

Sześć osi, na których powierzchnie się różnią

Zestawienie trzech powierzchni w tabeli porównawczej sprawia, że decyzje architektoniczne stają się konkretne:

Różnice się sumują. Funkcja zaprojektowana pod powierzchnię człowieka zakłada ciasne opóźnienia, bogate renderowanie, błędy zarządzane przez aplikację. Wpychanie jej na siłę przez Apple Intelligence powoduje utratę kontroli nad renderowaniem i dodaje tożsamość pośredniczoną przez OS. Wpychanie jej na siłę przez powierzchnię agenta powoduje całkowitą utratę renderowania i przesuwa granicę zaufania na tego, kto wdrożył serwer. Funkcję trzeba przeformować, a nie tylko opakować na nowo.

Reguła architektoniczna: warstwa domenowa pod powierzchniami

Wzorzec, który przeżywa wszystkie trzy powierzchnie, to warstwa domenowa pod nimi. Warstwa domenowa to zwykłe funkcje Swift: typowane wejścia, typowane wyjścia, brak założeń protokołu. Każda powierzchnia jest cienkim adapterem nad domeną. Ta sama funkcja logWater(amount:caller:) stoi za przyciskiem SwiftUI, za perform() z App Intent oraz za uchwytem narzędzia MCP.

Szkic (rzeczywista produkcja sprawiłaby, że WaterEntry byłby zgodny z AppEntity jako wynik App Intent, wstrzyknęłaby domain jako zależność, a nie odniesienie globalne, oraz dodałaby wymagane static var title w intencji):

// Domain layer (the actual capability)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter A: human surface (SwiftUI button)
Button("Log 250ml") {
    Task {
        let entry = try await domain.logWater(
            amount: .init(value: 250, unit: .milliliters),
            at: .now,
            caller: .human
        )
        // Update view state, show confirmation animation, etc.
    }
}

// Adapter B: Apple Intelligence surface (AppIntent)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>
    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)  // WaterEntry conforms to AppEntity
    }
}

// Adapter C: agent surface (MCP tool handler)
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Trzech wywołujących. Jedna funkcja domenowa. Funkcja domenowa przyjmuje parametr Caller, dzięki czemu może wymuszać różne reguły dla każdej powierzchni (limity wywołań, logowanie audytowe, wymagania potwierdzenia) bez konieczności ich ponownej implementacji w każdej powierzchni. Adaptery są głupie; domena jest mądra.

Kształt ten uogólnia wzorzec dwóch adapterów z App Intents vs MCP; dodanie powierzchni człowieka jako trzeciej klasy wywołujących to naturalne rozszerzenie. LLM Foundation Models działający na urządzeniu, używany wewnątrz aplikacji, znajduje się na powierzchni człowieka (użytkownik wywołał wewnątrzaplikacyjną funkcję, która akurat wywołuje model); LLM runtime nie jest czwartą powierzchnią — jest sposobem wykonywania funkcji, które już należą do powierzchni człowieka.⁶

Nie każda funkcja obsługuje wszystkie trzy powierzchnie

Równa ekspozycja nie jest celem. Różne funkcje należą do różnych powierzchni.

Funkcje, które zwykle powinny wymagać obecności człowieka na pierwszym planie. Robienie zdjęć, uwierzytelnianie biometryczne, wprowadzanie wrażliwych PII, potwierdzanie płatności, usuwanie konta. Człowiek musi patrzeć na ekran, musi wyrazić zgodę, musi się uwierzytelnić. Apple Intelligence może technicznie przenieść aplikację na pierwszy plan i poprosić o potwierdzenie; powierzchnia agenta nie ma równoważnej gwarancji obecności. Osąd produktowy mówi, że funkcje te powinny działać jako pierwszoplanowe UI z jawnym, zamierzonym działaniem, a nie jako ciche wywołanie Siri lub narzędzia w tle.

Funkcje, które powinny żyć na powierzchniach człowieka + Apple Intelligence. Większość akcji skierowanych do użytkownika. Zarejestruj wodę, rozpocznij medytację, dodaj pozycję do listy, pokaż mi wpisy z wtorku. Użytkownik może stuknąć w przycisk lub powiedzieć „Hej Siri”. Obie powierzchnie są poprawne; obie powinny sięgać do tej samej funkcji domenowej.

Funkcje, które powinny żyć na wszystkich trzech powierzchniach. Integracje między procesami. Lista zakupów współdzielona między iPhonem użytkownika a sesją Claude Code, która importuje przepisy. Powierzchnia człowieka odpowiada za codzienne użycie; powierzchnia Apple Intelligence odpowiada za zasięg Siri/Spotlight; powierzchnia agenta odpowiada za zewnętrzny przepływ pracy napędzany przez programistę lub użytkownika.

Funkcje, które powinny żyć tylko na powierzchni agenta. Zbiorcze importy programisty lub administratora bez przepływu recenzji użytkownika końcowego, integracje z systemami zewnętrznymi, przepływy pracy orkiestrowane przez agenta, które nie mają wyrażenia w Siri ani w aplikacji. Zbiorczy import 500 historycznych wpisów z pliku CSV programisty podczas jednorazowego uzupełnienia danych. Importy plików użytkownika końcowego często mają przepływ na powierzchni człowieka (Shortcuts mogą przekazywać pliki; importer w aplikacji może dzielić postęp na fragmenty); przypadek wyłącznie agentowy to przepływ, który naprawdę nie ma miejsca w żadnej z dwóch pozostałych powierzchni.

Decyzja jest projektem. Wymienienie powierzchni, których funkcja nie obsługuje, jest tak samo ważne, jak wymienienie tych, które obsługuje.

Co zbudowałbym inaczej

Dwa wzorce, które aplikacje klastra albo wdrażają, albo żałują, że ich nie wdrożono.

Należy uczynić Caller typem pierwszej kategorii w warstwie domenowej. Każda publiczna funkcja domenowa przyjmuje argument Caller. Typ koduje, która powierzchnia wywołała wywołanie (.human, .siri, .mcp(host:)). Logika domenowa rozgałęzia się na nim dla zapytań o potwierdzenie, limitów wywołań, logowania audytowego i bramek dla wrażliwych akcji. Alternatywa (każda powierzchnia ponownie implementuje reguły) ulega rozjazdowi; wersja scentralizowana pozostaje spójna.

Należy traktować pokrycie powierzchni jako jawną listę kontrolną. Przy dodawaniu funkcji dokument projektowy wymienia, która z trzech powierzchni powinna ją wystawiać, a która powinna jej odmawiać. Lista odmów nie jest domyślną; jest świadomym wyborem. Odmówiono: powierzchnia Apple Intelligence, ponieważ funkcja wymaga dowodu uwagi użytkownika, którego Siri nie może zapewnić. Uzasadnienie zostaje zarejestrowane; audyt później wychwyci rozjazdy.

Co wzorzec oznacza dla aplikacji wysyłanych na iOS 26+

Trzy wnioski.

1. Trzy powierzchnie, trzy poziomy zaufania. Człowiek, Apple Intelligence, agent. Każda ma obowiązki, których nie mają pozostałe. Projektowanie pod jedną i wpychanie na siłę w pozostałe daje złą architekturę na każdej powierzchni.

2. Domena pod spodem; adaptery na górze. Jedna funkcja Swift na funkcję; cienkie adaptery na powierzchnię; funkcja przyjmuje parametr Caller, dzięki czemu może wymuszać reguły specyficzne dla powierzchni w jednym miejscu.

3. Nie każda funkcja obsługuje wszystkie trzy. Ukrywanie funkcji przed powierzchniami, które nie powinny jej mieć, jest tak samo decyzją projektową, jak jej wystawianie. Lista odmów zasługuje na swoje miejsce.

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 wewnątrz powierzchni człowieka; rozróżnienie między LLM runtime a narzędziowym; Live Activities dla maszyny stanu ekranu blokady iOS; kontrakt runtime watchOS na Apple Watch; wewnętrzności SwiftUI dla podłoża powierzchni człowieka; przestrzenny model myślowy RealityKit dla scen visionOS; dyscyplina schematu SwiftData dla trwałości między powierzchniami; wzorce Liquid Glass dla wizualnej warstwy człowieka; wysyłka wieloplatformowa dla zasięgu między urządzeniami. Hub znajduje się na stronie Apple Ecosystem Series. Szerszy kontekst iOS z agentami AI można znaleźć w przewodniku iOS Agent Development.

FAQ

Jakie są trzy powierzchnie aplikacji iOS?

Powierzchnia człowieka (widoki SwiftUI, stuknięcia, gesty, ekran), powierzchnia Apple Intelligence (App Intents, Siri, Shortcuts, Spotlight) oraz powierzchnia agenta (serwery MCP wystawione na zewnętrzne hosty LLM, takie jak Claude Code, Cursor, ChatGPT). Każda ma własną tożsamość wywołującego, budżet opóźnień, lokalizację renderowania, semantykę trwałości i poziom zaufania. Funkcja, która ma obsługiwać więcej niż jedną powierzchnię, powinna leżeć na warstwie domenowej pod cienkimi adapterami przypisanymi do każdej powierzchni.

Czy każda funkcja powinna być wystawiona na wszystkie trzy powierzchnie?

Nie. Niektóre funkcje są poprawnie ograniczone do jednej lub dwóch powierzchni. Robienie zdjęć, uwierzytelnianie biometryczne i potwierdzanie wrażliwych akcji najlepiej sprawdzają się jako pierwszoplanowe przepływy powierzchni człowieka, ponieważ to tam najpewniej obecne są sygnały zaufania (uwaga użytkownika, zamierzone działanie). Operacje zbiorcze napędzane przez programistę należą wyłącznie do powierzchni agenta, gdy nie istnieje przepływ recenzji użytkownika końcowego. Decyzja projektowa to to, które powierzchnie funkcja obsługuje, a którym odmawia.

Czym różni się powierzchnia Apple Intelligence od powierzchni agenta?

Apple Intelligence to agent Apple jako pierwszej strony: użytkownik wywołuje Siri, Shortcuts lub Spotlight; system kieruje przez App Intents. Zaufanie pochodzi z OS. Powierzchnia agenta to każdy inny host LLM: programiści uruchamiają Claude Code lub Cursor, użytkownicy końcowi uruchamiają Claude Desktop lub ChatGPT. Zaufanie pochodzi od tego, kto wdrożył serwer MCP. App Intents są powierzchnią protokołu dla pierwszej; MCP jest powierzchnią protokołu dla drugiej.

Gdzie pasuje LLM Foundation Models działający na urządzeniu?

Wewnątrz powierzchni człowieka. Gdy użytkownik wywołuje funkcję wewnątrzaplikacyjną, która wywołuje Foundation Models, LLM runtime jest implementacją funkcji powierzchni człowieka, a nie czwartą powierzchnią. LLM runtime nie ma własnego wywołującego z Siri ani zewnętrznego hosta. Narzędzia Foundation Models są sposobem, w jaki model na urządzeniu czyta/zapisuje stan domeny aplikacji; to użytkownik napędza wywołanie.

W jaki sposób wzorzec warstwy domenowej upraszcza kod wielopowierzchniowy?

Poprzez centralizację reguł. Jedna funkcja Swift przyjmuje argument Caller i wymusza zachowanie specyficzne dla powierzchni (zapytania o potwierdzenie, limity wywołań, logowanie audytowe) w jednym miejscu. Każda powierzchnia jest cienkim adapterem (wiązanie SwiftUI, AppIntent.perform, uchwyt MCP), który tłumaczy protokół powierzchni na funkcję domenową. Rozjazdy między powierzchniami stają się niemożliwe, ponieważ istnieje jedno źródło prawdy.

Bibliografia