App Intents 2.0 w iOS 26: Visual Intelligence, interaktywne snippety i właściwości odroczone

App Intents pojawił się w iOS 16 jako autorskie API Apple do strukturalnych akcji w Shortcuts, Siri i Spotlight; iOS 17 rozszerzył go o widżety oparte na App Intents; iOS 18 uczynił z niego kontrakt dla powierzchni działań Apple Intelligence. iOS 26 rozszerza App Intents o Visual Intelligence (wyniki wyszukiwania obrazów z aplikacji firm trzecich), interaktywne snippety (małe wyskakujące okienka UI komponowane w kontekstach systemowych), adnotacje widoków encji (sposób renderowania encji w trybie inline) oraz @DeferredProperty (właściwości encji obliczane asynchronicznie)¹. Te rozszerzenia nie zmieniają podstawowego modelu App Intents; dodają nowe powierzchnie uczestnictwa, które aplikacja może adoptować.

Niniejszy wpis omawia dodatki iOS 26 w oparciu o dokumentację Apple. Ramą jest „jakie nowe powierzchnie zyskuje istniejąca adopcja App Intents po dodaniu zgodności z iOS 26”, ponieważ większość aplikacji z App Intents ma już wdrożone fundamentalne typy, a praca w iOS 26 polega na rozszerzeniu tych typów na nowe konteksty.

TL;DR

• IntentValueQuery to nowy protokół do integracji z Visual Intelligence. Zapytanie przyjmuje SemanticContentDescriptor (kontekst wizualny użytkownika) i zwraca tablicę instancji AppEntity, które aplikacja uznaje za istotne².
• @DeferredProperty deklaruje właściwość encji, której wartość jest obliczana asynchronicznie. Właściwość ładuje się dopiero wtedy, gdy system rzeczywiście jej potrzebuje, eliminując początkowy koszt dla encji z wieloma tanimi w wyświetleniu i kilkoma kosztownymi w obliczeniu polami.
• Interaktywne snippety App Intents pozwalają aplikacji zaprezentować małe wyskakujące okienko (z przyciskami, tekstem, kontrolkami) w kontekstach systemowych takich jak Spotlight, Visual Intelligence czy powierzchnia odpowiedzi Siri. Snippet jest widokiem SwiftUI związanym z wynikiem App Intent.
• Adnotacje widoków encji pozwalają aplikacji zadeklarować, jak AppEntity powinno być renderowane w różnych kontekstach systemowych (kompaktowy wiersz w Spotlight, karta hero w Visual Intelligence, widżet w stylu Live Activity).
• Wpis App Intents z tego klastra omawiał model fundamentalny; ten wpis rozszerza go o nowe powierzchnie uczestnictwa w iOS 26. Wpis App Intents vs narzędzia MCP z klastra omawia kwestię routingu między powierzchnią intencji Apple Intelligence a narzędziami MCP ogólnych agentów.

Visual Intelligence: IntentValueQuery i SemanticContentDescriptor

Sztandarowym dodatkiem App Intents w iOS 26 jest integracja z Visual Intelligence². Przepływ:

1. Użytkownik robi zdjęcie, wykonuje zrzut ekranu lub kieruje aparat na obiekt.
2. Systemowa warstwa Visual Intelligence wydobywa kontekst wizualny + semantyczny (co znajduje się na obrazie, czego użytkownik może o nim chcieć).
3. System wysyła zapytanie do każdej aplikacji, która zarejestrowała IntentValueQuery z tym kontekstem semantycznym.
4. Każda aplikacja zwraca odpowiednie instancje AppEntity; system agreguje je i prezentuje w interfejsie Visual Intelligence.
5. Użytkownik dotyka encji, aby wejść do aplikacji źródłowej w odpowiednim kontekście.

Powierzchnią deweloperską jest struktura zgodna z IntentValueQuery posiadająca metodę values(for:), która przyjmuje SemanticContentDescriptor:

import AppIntents

struct ProductLookupQuery: IntentValueQuery {
    func values(for descriptor: SemanticContentDescriptor) async throws -> [Product] {
        // descriptor.labels: detected category and content labels
        // descriptor.pixelBuffer: the visual content as a CVReadOnlyPixelBuffer
        //                        (use VideoToolbox/CoreImage to convert if needed)
        let candidates = try await catalog.search(labels: descriptor.labels)
        return candidates.map(Product.init)
    }
}

SemanticContentDescriptor przenosi dwa pola wypełniane przez system: labels (tablica wykrytych tagów kategorii i treści, takich jak „wine bottle”, „pinot noir”, „label text” itd.) oraz pixelBuffer (bazowe dane obrazu jako CVReadOnlyPixelBuffer dla aplikacji, które chcą uruchomić własne modele wizyjne na zawartości). Zadaniem aplikacji jest mapowanie tych sygnałów na własne dane i zwrócenie pasujących encji.

Właściwy wzorzec adopcji: aplikacja zakupowa implementuje zapytanie wobec swojego katalogu produktów (kontekst wizualny → pasujące produkty), aplikacja winiarska wobec swojej bazy butelek (obraz etykiety → wpis o winie), aplikacja kulinarna wobec swojej biblioteki przepisów (zdjęcie składnika → pasujące przepisy).

@DeferredProperty: asynchroniczne wartości encji

Istniejące typy AppEntity deklarują swoje właściwości statycznie. Każda właściwość musi być obliczona, zanim encja zostanie zwrócona. Dla encji z właściwościami o mieszanym koszcie (szybki tytuł/podtytuł/obraz, wolny szczegółowy opis z serwera) obliczanie typu „wszystko albo nic” jest marnotrawstwem.

@DeferredProperty (iOS 26+) deklaruje właściwość jako obliczaną asynchronicznie³:

import AppIntents

struct Recipe: AppEntity {
    static var typeDisplayRepresentation = TypeDisplayRepresentation(...)
    static var defaultQuery = RecipeQuery()

    @Property(title: "Title")
    var title: String

    @Property(title: "Cuisine")
    var cuisine: String

    @DeferredProperty(title: "Detailed Instructions")
    var instructions: String {
        get async throws {
            try await loadInstructionsFromBackend(id: id)
        }
    }
}

Getter właściwości odroczonej jest asynchroniczny; uruchamia się dopiero wtedy, gdy system rzeczywiście potrzebuje wartości (np. gdy encja jest wybrana do wyświetlenia szczegółów). Dla encji zwracanych z zapytania i używanych wyłącznie w UI wyboru, właściwość odroczona nigdy nie jest obliczana.

Wzorzec sprawdza się dla każdej encji z polami szybkimi do zbudowania (id, tytuł, podsumowanie) i kosztownymi do zbudowania (pełna treść, obliczane metryki, dane pobierane z serwera). Bez @DeferredProperty deweloper albo oblicza wszystko (marnotrawstwo), albo oblicza tylko tanie pola i dodaje osobną intencję „załaduj szczegóły” (większa złożoność).

Interaktywne snippety i SnippetIntent

iOS 26 wprowadza dedykowany protokół SnippetIntent dla interakcji w kształcie snippetu, obok istniejącego od wcześniejszych wydań wzorca AppIntent zgodnego z ShowsSnippetView⁴. SnippetIntent dodaje statyczną metodę reload(), którą system może wywołać, aby odświeżyć zawartość snippetu bez pełnego ponownego wywołania intencji:

struct WeatherSnippet: SnippetIntent {
    static var title: LocalizedStringResource = "Weather Snippet"

    @Parameter(title: "City")
    var city: City

    func perform() async throws -> some IntentResult & ShowsSnippetView {
        let forecast = try await weatherService.forecast(for: city)
        return .result(view: ForecastSnippet(forecast: forecast))
    }

    static func reload() async throws {
        // Triggered by the system when it wants fresh snippet data
        // (e.g., after the data source signals an update)
    }
}

Dla intencji niespecyficznych dla snippetów, które chcą dołączyć widok snippetu do swojej odpowiedzi, istniejący wzorzec AppIntent + ShowsSnippetView nadal działa:

struct WeatherForecastIntent: AppIntent {
    static var title: LocalizedStringResource = "Weather Forecast"

    @Parameter(title: "City")
    var city: City

    func perform() async throws -> some IntentResult & ProvidesDialog & ShowsSnippetView {
        let forecast = try await weatherService.forecast(for: city)

        return .result(
            dialog: "Here's the forecast for \(city.name).",
            view: ForecastSnippet(forecast: forecast)
        )
    }
}

struct ForecastSnippet: View {
    let forecast: Forecast
    var body: some View {
        VStack(alignment: .leading) {
            Text(forecast.headline).font(.headline)
            HStack {
                ForEach(forecast.days) { day in
                    DayCell(day: day)
                }
            }
            Button("Open in App") {
                // App-launching action wired via App Intents
            }
        }
        .padding()
    }
}

Zgodność typu wyniku z ShowsSnippetView mówi systemowi, aby wyrenderował widok SwiftUI obok dialogu. Snippet jest interaktywny: przyciski w jego wnętrzu mogą wyzwalać inne App Intents, użytkownik może przewijać, widok uczestniczy w warstwie interakcji systemu.

Przypadki uzasadniające interaktywny snippet: prognozy pogody, wydarzenia kalendarzowe, czasy przejazdu, wyniki sportowe, śledzenie przesyłek. Wszędzie tam, gdzie użytkownik chce więcej niż jednowierszowej odpowiedzi dialogowej z powierzchni systemu.

Adnotacje widoków encji

Adnotacje widoków encji pozwalają aplikacji zadeklarować, jak AppEntity powinno być renderowane w różnych kontekstach systemowych⁵. Mechanizm rozszerza DisplayRepresentation o wiele wariantów:

struct Recipe: AppEntity {
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(
            title: "\(title)",
            subtitle: "\(cuisine) - \(time) min",
            image: .init(named: imageName)
        )
    }
}

Klasyczny model zwraca pojedynczą DisplayRepresentation. iOS 26 pozwala encjom dostarczać warianty specyficzne dla kontekstu, spośród których system wybiera w zależności od miejsca renderowania (kompaktowa lista, karta hero, wynik Spotlight, panel Visual Intelligence). Framework wybiera odpowiedni wariant per kontekst; aplikacja deklaruje każdy z nich.

Wzorzec wspiera aplikacje wymagające zróżnicowanego renderowania encji między, powiedzmy, gęsto upakowaną listą Spotlight a jednokartową odpowiedzią Visual Intelligence. Warianty komponują się bez konieczności wykrywania kontekstu przez aplikację.

Kompozycja z istniejącymi App Intents

Dodatki iOS 26 komponują się z istniejącymi prymitywami App Intents:

• AppShortcutsProvider aplikacji (omówiony w Dostępność jako platforma) rejestruje skróty dla głosu, przycisku akcji i Spotlight.
• Każdy AppShortcut odwołuje się do AppIntent, który posiada właściwości @Parameter rozwiązywane na podstawie żądania użytkownika.
• Metoda AppIntent.perform() zwraca typ wyniku, który może zawierać widok snippetu (ShowsSnippetView) lub dialog (ProvidesDialog).
• Typy AppEntity przywoływane przez parametry intencji obsługują teraz @DeferredProperty i adnotacje widoków encji.
• Nowe typy IntentValueQuery pozwalają tym samym encjom pojawić się w Visual Intelligence.

Kształt: istniejący model jest zachowany; praca w iOS 26 polega na dodaniu nowych typów (zapytań) i nowych adnotacji (odroczonych, wariantów widoków) do tej samej powierzchni encji.

Częste niepowodzenia

Trzy wzorce niepowodzeń przy adopcji App Intents 2.0:

IntentValueQuery zwracające wyniki bez ograniczeń. Zapytanie zwracające każdy produkt pasujący do terminów wyszukiwania deskryptora, niezależnie od trafności, rozwadnia doświadczenie Visual Intelligence. Naprawa: ogranicz zapytanie (top-N trafności, ważone aktualnością, spersonalizowane dla użytkownika), aby każda zwrócona encja zasłużyła sobie na miejsce w UI systemu.

@DeferredProperty dla szybkich wartości. Mechanizm odroczenia jest dla naprawdę kosztownych obliczeń. Oznaczenie szybkiej właściwości w pamięci jako odroczonej dodaje narzut asynchroniczności bez korzyści. Naprawa: zarezerwuj @DeferredProperty dla właściwości, które rzeczywiście opłaca się odroczyć (pobrania z serwera, duże obliczenia, wywołania modeli ML).

Interaktywne snippety będące pełnymi aplikacjami. Snippet jest kompaktową powierzchnią UI; traktowanie go jak miniaplikacji prowadzi do snippetów, które sprawiają wrażenie ciasnych lub renderują się wolno. Naprawa: utrzymuj snippety skupione na bezpośredniej odpowiedzi i jednej lub dwóch powiązanych akcjach; używaj przycisku „Open in App”, aby przekazywać złożone przepływy do pełnej aplikacji.

Co ten wzorzec oznacza dla aplikacji iOS 26+

Trzy wnioski.

1. Dodaj IntentValueQuery do każdej aplikacji z treścią wizualną. Zakupy, przepisy, produkty, lokalizacje, identyfikowalne obiekty. Integracja z Visual Intelligence to nowa powierzchnia odkrywania; aplikacje, które w niej nie uczestniczą, są tam niewidoczne.

2. Używaj @DeferredProperty dla kosztownych pól encji. Szczegółowe opisy, obliczane metryki, dane pobierane z serwera. Wzorzec domyślnie asynchroniczny pasuje do nowoczesnego kodu Swift i utrzymuje szybkie zwroty encji tanich w budowie.

3. Adoptuj interaktywne snippety dla typów zapytań o wysokiej wartości. Pogoda, kalendarz, transport, sport, śledzenie przesyłek. UI snippetu utrzymuje użytkowników na powierzchni odpowiedzi systemu w przypadkach, gdy jednowierszowy dialog nie wystarcza, a uruchomienie pełnej aplikacji to przesada.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; kwestia routingu; Foundation Models; rozróżnienie LLM runtime vs tooling; trzy powierzchnie; wzorzec single source of truth; Dwa serwery MCP; hooki dla rozwoju Apple; Live Activities; kontrakt runtime watchOS; wewnętrzne mechanizmy SwiftUI; model mentalny przestrzenny RealityKit; dyscyplina schematu SwiftData; wzorce Liquid Glass; wieloplatformowe wydawanie; macierz platform; framework Vision; Symbol Effects; inferencja Core ML; API Writing Tools; Swift Testing; Privacy Manifest; Dostępność jako platforma; typografia SF Pro; wzorce przestrzenne visionOS; framework Speech; migracje SwiftData; silnik fokusa tvOS; wewnętrzne mechanizmy @Observable; protokół Layout SwiftUI; niestandardowe SF Symbols; HDR w AVFoundation; cykl życia treningu watchOS; o czym odmawiam pisać. Hub znajduje się na serii Apple Ecosystem. Szerszy kontekst iOS-z-agentami-AI: przewodnik iOS Agent Development.

FAQ

Czy do testowania IntentValueQuery wymagane jest włączone Apple Intelligence?

Do pełnego testowania Visual Intelligence — tak. Visual Intelligence wymaga sprzętu obsługującego Apple Intelligence (iPhone 15 Pro lub nowszy, Mac z M1 lub nowszy) z iOS 26+ i włączonym Apple Intelligence. Na potrzeby rozwoju można testować zapytanie w testach jednostkowych poprzez bezpośrednie skonstruowanie SemanticContentDescriptor i wywołanie metody values(for:) zapytania bez pełnego stosu systemowego.

Czy @DeferredProperty może rzucać wyjątki?

Tak. Sygnatura asynchronicznego gettera to get async throws, a wyjątki propagują się do systemu. System obsługuje awarię, wyświetlając encję bez wartości właściwości odroczonej (lub pokazując stan błędu w niektórych kontekstach). Aplikacje powinny obsługiwać błędy w sposób elegancki i zwracać sensowne stany błędu zamiast się zawieszać.

Czy zawartość interaktywnego snippetu obsługuje animacje?

Tak, ze standardowymi prymitywami animacji SwiftUI. Widok snippetu działa na powierzchni odpowiedzi systemu, która obsługuje tę samą infrastrukturę animacji co SwiftUI w aplikacji. Warto sięgnąć do wpisu Symbol Effects z klastra po słownictwo animacji pasujące do konwencji platformy.

Jak adnotacje widoków encji współpracują z widżetami?

Widżety to oddzielna powierzchnia WidgetKit; adnotacje widoków encji obowiązują w kontekstach App Intents (Spotlight, Visual Intelligence, odpowiedzi Siri). Dla aplikacji eksponującej te same dane jednocześnie jako AppEntity i jako widżet, obie powierzchnie wymagają osobnych deklaracji UI. Aplikacje zwykle współdzielą bazowy model danych i piszą cienkie widoki prezentacyjne dla każdej powierzchni.

Jaka jest relacja między tym a narzędziami MCP?

App Intents to powierzchnia intencji Apple Intelligence; narzędzia MCP to protokół agent-serwer dla ogólnych LLM. iOS 26 dodaje Visual Intelligence do App Intents (powierzchnia Apple). Dla agentów spoza Apple (Claude, klasa GPT) narzędzia MCP działające lokalnie lub zdalnie pokrywają to samo terytorium koncepcyjne. Wpis App Intents vs narzędzia MCP z klastra omawia kwestię routingu.

Czy IntentValueQuery można łączyć z EntityQuery?

Tak. Obsługują różne powierzchnie: EntityQuery jest dla sytuacji, gdy użytkownik wpisuje lub wymawia nazwę encji (Spotlight, Siri); IntentValueQuery jest dla sytuacji, gdy użytkownik znajduje się w Visual Intelligence z kontekstem obrazu. AppEntity aplikacji może mieć zarejestrowane oba zapytania; system wybiera odpowiednie dla danego kontekstu.

Referencje