App Intents w iOS 27: praca w tle, synchronizacja, Spotlight

App Intents pojawiło się w iOS 16 jako stworzony przez Apple, typowany API ze strukturalnymi akcjami dla Shortcuts, Siri i Spotlight; iOS 17 rozszerzyło go na widżety napędzane przez App Intents; iOS 18 uczyniło go kontraktem dla powierzchni akcji Apple Intelligence; iOS 26 wprowadziło go do Visual Intelligence i interaktywnych snippetów. iOS 27 ponownie zmienia kształt tego zakładu, a zmiana jest mechaniczna, nie kosmetyczna: intent może teraz działać dłużej niż 30-sekundowy limit w tle, encja może nieść tożsamość przetrwałą podróż między urządzeniami użytkownika, a zapytanie może naprawić własny indeks Spotlight, gdy system o to poprosi. iOS 27 dodaje możliwości, a nie ozdoby.¹

Każde wcześniejsze wydanie poszerzało to, kto mógł wywołać Pana/Pani intenty. iOS 27 poszerza to, co intenty mogą zrobić po wywołaniu. Intent synchronizacji operujący na kilku tysiącach rekordów ścigał się dawniej z 30-sekundowym licznikiem i przegrywał; teraz prosi system o więcej czasu i raportuje postęp w trakcie pracy. Encja, która na iPhonie znaczyła jedno, a na Macu coś innego, rozwiązuje się teraz do tego samego obiektu na obu urządzeniach. Ten wpis prowadzi przez powierzchnię iOS 27 w odniesieniu do dokumentacji Apple, z tym samym założeniem co reszta klastra: co aplikacja, która już dostarcza App Intents, dodaje, aby zyskać każdą nową możliwość.

TL;DR

• LongRunningIntent przedłuża czas działania intentu w tle ponad systemowy limit 30 sekund. Pracę opakowuje się w performBackgroundTask(options:operation:) i przekazuje LongRunningTaskOptions; protokół zawęża ProgressReportingIntent, więc raportowanie postępu jest wymogiem, a nie opcją. Live Activities renderuje ten postęp automatycznie.²³⁴
• SyncableEntity deklaruje, że AppEntity niesie identyfikator spójny między urządzeniami użytkownika, co pozwala systemowi odwoływać się do tego samego obiektu na iPhonie, Macu i Watchu (Siri używa tego, by przekazać rozmowę z jednego urządzenia na drugie).⁵
• IndexedEntityQuery dodaje do EntityQuery obsługę ponownego indeksowania Spotlight, więc gdy system zgłosi problem z indeksem aplikacji, może poprosić zapytanie o ponowne przekazanie dotkniętych encji.⁶
• AppUnionValue i AppUnionValueCasesProviding (generowane przez makro @UnionValue) pozwalają jednemu parametrowi przyjmować kilka odrębnych typów encji z właściwym interfejsem wyboru i podsumowaniami parametrów.⁷⁸
• OwnershipProvidingEntity, EntityOwnership i EntityCollection obejmują potwierdzanie świadome własności oraz wydajność operacji masowych; RunSystemShortcutIntent i IntentExecutionTargets obejmują akcje systemowe uruchamiane z widżetu oraz to, który proces wykonuje intent.^910111213

Ściana 30 sekund: LongRunningIntent

Limit wykonywania w tle był cichym pułapem tego, co App Intent mógł zrobić. Gdy system wykonuje intent w tle (użytkownik prosi Siri o synchronizację, po czym blokuje telefon i chowa go do kieszeni), tradycyjnie przyznaje na ukończenie mniej więcej 30 sekund.² Do zapisania wypitej szklanki wody to hojny zapas. Do zsynchronizowania biblioteki, uruchomienia wnioskowania na urządzeniu czy przetworzenia dużego pliku 30 sekund to gilotyna: system zabija zadanie w połowie zapisu, a użytkownik dostaje wynik ukończony w połowie.

iOS 27 wprowadza LongRunningIntent, protokół, który intent przyjmuje, by poprosić system o wydłużone okno działania w tle.² Apple wprost wymienia przypadki użycia w dokumentacji: operacje na plikach, synchronizacja danych, wnioskowanie uczenia maszynowego oraz przetwarzanie danych na dostatecznie dużym zbiorze. Deklaracja przedstawia najważniejsze ograniczenie, zanim napisze się jeden wiersz:

protocol LongRunningIntent : ProgressReportingIntent

LongRunningIntent zawęża ProgressReportingIntent.² Nie można przyjąć protokołu długiego działania bez równoczesnego raportowania postępu — i tak to zaprojektowano. Wydłużony czas działania to przywilej, który system przyznaje warunkowo, a warunkiem jest to, że nieustannie informuje się go, jak daleko się zaszło. Po zaprzestaniu raportowania system może cofnąć przedłużenie i zakończyć zadanie wcześniej.³

Praca trafia do wnętrza performBackgroundTask(options:operation:):

@discardableResult
func performBackgroundTask<T>(
    options: LongRunningTaskOptions = [],
    operation: @escaping () async throws -> T
) async throws -> T

Metodę wywołuje się z ciała perform() intentu i umieszcza kosztowny kod w domknięciu operation. Metoda automatycznie przedłuża czas działania ponad standardowy limit 30 sekund na platformach, które go narzucają; nie uruchamia się osobnego zadania w tle ani nie zarządza samodzielnie UIBackgroundTaskIdentifier.³ Intent synchronizacji biblioteki wygląda tak:

import AppIntents

struct SyncLibraryIntent: LongRunningIntent {
    static var title: LocalizedStringResource = "Sync Library"

    func perform() async throws -> some IntentResult {
        try await performBackgroundTask(options: []) {
            let records = try await server.fetchPendingRecords()
            for (offset, record) in records.enumerated() {
                try await store.apply(record)
                progress.completedUnitCount = Int64(offset + 1)
                progress.totalUnitCount = Int64(records.count)
            }
            return ()
        }
        return .result()
    }
}

Dwie rzeczy zasługują na wyjaśnienie, bo poradniki je pomijają.

Właściwość progress to kontrakt, a nie telemetria. Apple stawia sprawę jasno: w trakcie działania operacji należy regularnie aktualizować Progress z konformacji ProgressReportingIntent, a jeśli się tego nie robi, system może anulować przedłużenie czasu działania i przedwcześnie zakończyć zadanie.³ Raportowanie postępu w zwykłym intencie to miły dodatek. W LongRunningIntent to bicie serca, które utrzymuje przedłużenie przy życiu.

LongRunningTaskOptions deklaruje wymagania dotyczące zasobów. Wartość opcji (struktura w stylu OptionSet, domyślnie []) informuje system o dodatkowych potrzebach zasobowych zadania, które uwzględnia on w przyznawanym czasie działania.⁴ Pusty zbiór to przypadek typowy. Po jawne opcje sięga się, gdy praca potrzebuje czegoś więcej niż profil domyślny.

Korzyść wykraczająca poza przetrwanie ponad 30 sekund: Live Activities renderuje postęp za darmo. Dokumentacja stwierdza, że Live Activities wyświetla postęp zadania intentu, korzystając z informacji otrzymywanych automatycznie z performBackgroundTask, rysując tytuł, podtytuł i pasek postępu na podstawie wartości raportowanych przez kod.³ Długa synchronizacja uruchomiona głosem pojawia się na ekranie blokady jako pasek postępu na żywo, bez budowania ani jednego widoku Live Activity. Intent raportuje, system renderuje.

W sesji 345 Apple demonstruje LongRunningIntent na realnym przypadku awarii — przesyłaniu zdjęcia, które wciąż umierało w oknie 30 sekund — i pokazuje, jak system zarządza cyklem życia zadania w tle, jednocześnie ujawniając postęp i element sterujący anulowaniem jako Live Activity.¹⁴

Spójna tożsamość: SyncableEntity

AppEntity ma id. Na pojedynczym urządzeniu ten identyfikator musi być unikatowy tylko w obrębie aplikacji. Kłopot zaczyna się w chwili, gdy użytkownik posiada więcej niż jedno urządzenie, co w ekosystemie Apple jest stanem domyślnym. „Project Atlas”, o którym użytkownik rozmawiał z Siri na iPhonie, musi być rozpoznawalny jako ten sam „Project Atlas”, gdy podejmie rozmowę na nowo na Macu. Jeśli lokalny identyfikator iPhone’a różni się od identyfikatora Maca, system ma dwa niepowiązane obiekty i żadnego sposobu, by je połączyć.

SyncableEntity to odpowiedź iOS 27:⁵

protocol SyncableEntity : AppEntity

Przyjęcie go deklaruje, że identyfikator encji jest taki sam na wszystkich urządzeniach. Obecność protokołu mówi systemowi, że może odwoływać się do encji spójnie z jednego urządzenia na drugie. Apple podaje konkretną korzyść: Siri używa tej możliwości, by przenieść rozmowę z jednego urządzenia na drugie.⁵

Koszt przyjęcia zależy całkowicie od tego, skąd pochodzą identyfikatory. Jeśli encje już używają stabilnego identyfikatora wspólnego dla urządzeń (UUID wystawiony przez serwer, nazwa rekordu iCloud), SyncableEntity przyjmuje się bez żadnych innych zmian, bo wartość, którą już się przechowuje, jest wartością, której potrzebuje system.⁵

import AppIntents

struct ProjectEntity: SyncableEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Project"
    static var defaultQuery = ProjectQuery()

    // A UUID issued by the backend and identical on every device.
    var id: UUID

    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)")
    }

    @Property(title: "Name") var name: String
}

Pułapką jest aplikacja, która na każdym urządzeniu tworzy świeży identyfikator lokalny (automatycznie inkrementowany numer wiersza, UUID na instalację). Te identyfikatory są unikatowe lokalnie i pozbawione znaczenia między urządzeniami. Wskazówka Apple na ten przypadek: przyjąć protokół i oprzeć tożsamość na wartości, która jest faktycznie stabilna, aby system miał trwały punkt zaczepienia.⁵ Synchronizacja była trudnym problemem, który zespoły wciąż rozwiązywały ręcznie własnym oprzyrządowaniem iCloud. SyncableEntity przenosi deklarację tożsamości między urządzeniami do frameworka, gdzie Siri i reszta systemu mogą na niej działać.

Samonaprawiające się wyszukiwanie: IndexedEntityQuery

iOS 16 pozwoliło przekazywać instancje IndexedEntity do Spotlight, aby poszczególne encje stały się wyszukiwalne. Luką była naprawa. Indeksy się rozjeżdżają, ulegają uszkodzeniu lub zostają w tyle po migracji, a do iOS 27 jedynym ratunkiem systemu było oparcie się na delegacie CSSearchableIndex aplikacji lub jej CSImportExtension.

IndexedEntityQuery zamyka tę lukę, pozwalając systemowi poprosić zapytanie o ponowne zindeksowanie:⁶

protocol IndexedEntityQuery : EntityQuery where Self.Entity : IndexedEntity

Klauzula where to warunek wstępny: encja zapytania musi być zgodna z IndexedEntity, bo ponowne indeksowanie ma sens tylko dla encji, które w ogóle przekazuje się do Spotlight.⁶ Gdy system napotka problem z indeksem aplikacji, wywołuje metody tego protokołu, jeśli typ zapytania go przyjmuje; jeśli zapytanie tego nie robi, Spotlight nadal prosi obiekt CSSearchableIndex (lub CSImportExtension, jeśli przekazano przez powiązanie encji z tym typem) o wykonanie pracy.⁶ Metody implementuje się tak, by pobrać żądane encje i ponownie przekazać je przez preferowany indeks wyszukiwania.

import AppIntents
import CoreSpotlight

struct PhotoQuery: IndexedEntityQuery {
    func entities(for identifiers: [Photo.ID]) async throws -> [Photo] {
        try await library.photos(matching: identifiers)
    }

    func suggestedEntities() async throws -> [Photo] {
        try await library.recentPhotos(limit: 20)
    }

    // Called by the system during reindexing. Fetch the requested
    // entities and donate them again to Spotlight.
    func entities(matching string: String) async throws -> [Photo] {
        try await library.photos(matchingText: string)
    }
}

Wartość jest operacyjna. Aplikacja, która poprawnie wdraża IndexedEntityQuery, uczestniczy w pętli odzyskiwania Spotlight: system zauważa, że indeks jest błędny, a aplikacja dostarcza świeże dane na żądanie — zamiast cichej utraty wyników wyszukiwania aż do następnego pełnego ponownego przekazania. Fundamentalny wpis o App Intents z klastra opisywał samo udostępnianie IndexedEntity w celu uczynienia wpisów wyszukiwalnymi; IndexedEntityQuery to nałożona na to warstwa utrzymaniowa.

Jeden parametr, kilka typów: AppUnionValue

Mnóstwo realnych intentów przyjmuje parametr, który w sposób uprawniony jest jednym z kilku typów. „Udostępnij to”, gdzie „to” jest zdjęciem, dokumentem lub linkiem. Obejścia sprzed iOS 27 były nieładne: osobne intenty na każdy typ albo dyskryminator tekstowy plus opcjonalne parametry, których interfejs wyboru nie potrafił czysto wyrenderować.

iOS 27 dodaje AppUnionValue dla typowanych parametrów unii:⁷

protocol AppUnionValue : TypeDisplayRepresentable

Wartość unii zgodna z tym protokołem działa jako parametr Shortcuts z bogatymi metadanymi, więc system może przedstawić odpowiedni interfejs wyboru oraz sensowne podsumowanie parametru obejmujące typy składowe.⁷ Konformacji nie pisze się ręcznie. Generuje ją makro @UnionValue, a to samo makro generuje zagnieżdżony enum Cases zgodny z AppUnionValueCasesProviding:⁷⁸

protocol AppUnionValueCasesProviding : AppEnum

AppUnionValueCasesProviding jest spełniany automatycznie przez enum Cases emitowany przez makro.⁸ Łączy on enum przypadków z powrotem z typem wartości unii i dziedziczy metadane przez swoją konformację AppEnum, co nadaje każdemu przypadkowi nazwę wyświetlaną w interfejsie wyboru.⁸ W praktyce pisze się unię i opatruje ją adnotacją:

import AppIntents

@UnionValue
enum ShareTarget {
    case photo(PhotoEntity)
    case document(DocumentEntity)
    case link(URL)
}

struct ShareIntent: AppIntent {
    static var title: LocalizedStringResource = "Share Item"

    @Parameter(title: "Item")
    var target: ShareTarget

    func perform() async throws -> some IntentResult {
        // Switch over the concrete case and act accordingly.
        return .result()
    }
}

Makro @UnionValue obsługuje konformacje AppUnionValue i AppUnionValueCasesProviding; jeśli potrzeba metadanych niestandardowych wykraczających poza wartości domyślne, wymagania protokołu implementuje się w rozszerzeniu.⁷ Jeden parametr, trzy poprawne typy, interfejs wyboru, który wie, jak pokazać wszystkie trzy.

Własność i wydajność

Dwa odrębne zagadnienia iOS 27 dzielą tę sekcję, bo oba chronią system przed nieostrożnym działaniem na danych: potwierdzanie świadome własności oraz wydajność operacji masowych.

Potwierdzanie akcji destrukcyjnych: OwnershipProvidingEntity

Gdy aplikacja przekazuje encje do intentów i zwraca je z wyników, Apple Intelligence, Siri i niestandardowe skróty mogą działać na tych encjach między aplikacjami. Dla akcji destrukcyjnych lub wrażliwych (usunięcie encji, aktualizacja współdzielonej) potrzebne jest potwierdzenie niosące właściwy kontekst. OwnershipProvidingEntity go dostarcza:⁹

protocol OwnershipProvidingEntity : AppEntity

Gdy encja jest z nim zgodna, system prosi o potwierdzenie z odpowiednim kontekstem w oknie dialogowym, gdy intent działa na encjach współdzielonych lub publicznie dostępnych.⁹ Sam stan własności to wartość EntityOwnership, struktura oparta na flagach, w której podaje się pojedynczy stan lub łączy kilka za pomocą OptionSet:¹⁰

import AppIntents

struct AlbumEntity: OwnershipProvidingEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Album"
    static var defaultQuery = AlbumQuery()

    var id: UUID
    var isSharedWithFamily: Bool
    var isPublished: Bool

    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)")
    }

    @Property(title: "Name") var name: String

    // Reflect how the user has shared this album so the system can
    // calibrate its confirmation dialog.
    var ownership: EntityOwnership {
        var state: EntityOwnership = []
        if isSharedWithFamily || isPublished {
            state = .shared
        }
        return state
    }
}

Mechanizm ma największe znaczenie dla aplikacji z treściami współdzielonymi: album zdjęć, który opublikowano lub udostępniono rodzinie, powinien dawać ostrożniejsze potwierdzenie niż prywatny, a OwnershipProvidingEntity to sposób, w jaki encja mówi systemowi, który jest który.⁹

Operacje masowe bez obciążenia pamięci: EntityCollection

Rozwiązywanie encji nie jest darmowe. Gdy intent przyjmuje setki encji jako parametr, zmuszanie systemu do rozwiązania każdego identyfikatora w pełną instancję podczas rozwiązywania parametrów może kosztować znaczący czas i pamięć w złym momencie. EntityCollection to rozwiązanie:¹¹

struct EntityCollection<Entity> where Entity : AppEntity

Kolekcja początkowo przechowuje jedynie identyfikator każdej encji i oferuje opcję późniejszego pobrania pełnych instancji, jeśli będą potrzebne.¹¹ Używa się jej jako typu zmiennej, gdy przechowuje się wiele identyfikatorów, oraz jako typu parametru, gdy intent operuje na dużym zbiorze:

import AppIntents

struct DisableNotificationsIntent: AppIntent {
    static var title: LocalizedStringResource = "Disable Notifications"

    // Hundreds of conversations resolve lazily, not all at once.
    @Parameter(title: "Conversations")
    var conversations: EntityCollection<ConversationEntity>

    func perform() async throws -> some IntentResult {
        return .result()
    }
}

Dla parametru przechowującego setki encji pominięcie rozwiązywania każdego identyfikatora oszczędza czas i pamięć dokładnie wtedy, gdy użytkownik czeka na rozpoczęcie akcji.¹¹

Gdzie wykonuje się intent: RunSystemShortcutIntent i IntentExecutionTargets

Dwa mniejsze dodatki iOS 27 dopełniają tę powierzchnię. RunSystemShortcutIntent to intent wyłącznie dla widżetów, służący do uruchamiania innej aplikacji albo wykonywania App Shortcut, skrótu niestandardowego lub akcji systemowej z przycisku widżetu:¹²

struct RunSystemShortcutIntent

Używa się go jedynie do zainicjowania Button inicjalizatorem skrótu systemowego i umieszczenia tego przycisku w widżecie; poza tym kontekstem nie robi nic użytecznego.¹² Gdy użytkownik konfiguruje widżet, wybiera akcję przycisku, a intent dostarcza metadane, których system potrzebuje dla interfejsu konfiguracji. Nie daje on widżetowi dostępu do akcji, parametrów ani implementacji skrótu. Jeśli wybrany skrót musi poprosić o dane wejściowe, system może otworzyć aplikację Shortcuts, by go wykonać.¹²

IntentExecutionTargets odpowiada na pytanie, które pojawia się, gdy współdzieli się intenty i encje między aplikacją, rozszerzeniem widżetu oraz rozszerzeniem App Intents poprzez pakiet lub framework Swift: który proces wykonuje intent?¹³

struct IntentExecutionTargets

Domyślnie system wykonuje intent lub zapytanie o encję, używając dowolnego dostępnego celu.¹³ IntentExecutionTargets służy do ograniczenia tego. Przykład Apple to przeglądarka: dodanie zakładki może odbyć się, gdy aplikacja nie jest widoczna, więc rozszerzenie App Intents wystarczy, ale otwarcie nowej karty ma sens tylko wtedy, gdy aplikacja jest widoczna, co wymaga jej własnego procesu.¹³ Deklaruje się poprawne cele, a system honoruje to ograniczenie.

Ścieżka przyjęcia

Aplikacja, która już dostarcza App Intents, dodaje możliwości iOS 27 przyrostowo; żadna z nich nie przepisuje podstawowego modelu.

1. Znajdź swój najwolniejszy intent. Każdy intent wykonujący operacje wejścia/wyjścia na plikach, synchronizację, wnioskowanie na urządzeniu lub przetwarzanie dużych danych jest kandydatem na LongRunningIntent. Przyjmij protokół, przenieś pracę do performBackgroundTask(options:operation:) i raportuj progress przez cały czas. Zyskujesz czas działania ponad 30 sekund oraz darmowy postęp Live Activities.²³
2. Zaudytuj identyfikatory encji. Jeśli są już stabilne między urządzeniami (UUID z serwera, nazwa rekordu iCloud), uczyń odpowiednie encje zgodnymi z SyncableEntity i dostarcz. Jeśli są specyficzne dla urządzenia, najpierw napraw tożsamość, a potem zapewnij zgodność.⁵
3. Dodaj IndexedEntityQuery do zapytań, których encje są IndexedEntity. Jest to czysto addytywne: metody wywołują się tylko wtedy, gdy system potrzebuje ponownego indeksowania, a wyniki wyszukiwania pozostają poprawne mimo rozjeżdżania się indeksu.⁶
4. Złóż parametry wielotypowe za pomocą @UnionValue. Wszędzie tam, gdzie udawano unię osobnymi intentami albo tekstem dyskryminatora, makro daje jeden czysty parametr.⁷
5. Oznacz encje współdzielone za pomocą OwnershipProvidingEntity i przełącz parametry dużych zbiorów na EntityCollection. Pierwsze poprawia bezpieczeństwo potwierdzeń, drugie poprawia wydajność rozwiązywania.⁹¹¹

FAQ

Jak długo LongRunningIntent może działać w tle?

Apple dokumentuje podłogę, którą podnosi, a nie stały sufit. System tradycyjnie daje zadaniu w tle mniej więcej 30 sekund na ukończenie, a LongRunningIntent (przez performBackgroundTask(options:operation:)) automatycznie przedłuża to okno ponad standardowy limit na platformach, które go narzucają.²³ Przedłużenie jest warunkowe: trzeba nieustannie aktualizować Progress z konformacji ProgressReportingIntent, a jeśli się przestanie, system może anulować przedłużenie i zakończyć zadanie wcześniej.³ Raportowanie postępu należy traktować jako cenę dodatkowego czasu działania.

Czy muszę raportować postęp, by używać LongRunningIntent?

Tak. LongRunningIntent jest zadeklarowany jako protocol LongRunningIntent : ProgressReportingIntent, więc jego przyjęcie wymaga konformacji ProgressReportingIntent i jej Progress.² Poza zadowoleniem kompilatora regularne aktualizacje postępu utrzymują przedłużenie czasu działania w tle przy życiu i zasilają tytuł, podtytuł oraz pasek postępu, które Live Activities renderuje automatycznie z performBackgroundTask.³

Co SyncableEntity faktycznie zmienia w czasie działania?

Deklaruje, że identyfikator encji jest identyczny między urządzeniami użytkownika, co pozwala systemowi traktować obiekt jako jedną encję wszędzie zamiast osobnych obiektów na każdym urządzeniu.⁵ Konkretna możliwość wymieniona przez Apple: Siri może przenieść rozmowę o tej encji z jednego urządzenia na drugie. Jeśli identyfikatory są już stabilne między urządzeniami, protokół przyjmuje się bez żadnych innych zmian; jeśli są specyficzne dla urządzenia, najpierw przenosi się tożsamość na stabilną wartość.⁵

Kiedy system wywołuje IndexedEntityQuery?

Gdy napotka problem z indeksem Spotlight aplikacji, a typ zapytania przyjmuje IndexedEntityQuery (przy encji zgodnej z IndexedEntity).⁶ System wywołuje metody protokołu, by pobrać dotknięte encje i ponownie przekazać je do Spotlight. Jeśli zapytanie nie przyjmuje protokołu, Spotlight wraca do proszenia obiektu CSSearchableIndex lub CSImportExtension, jeśli przekazano przez ten typ.⁶

Dlaczego używać EntityCollection zamiast zwykłej tablicy encji?

EntityCollection<Entity> przechowuje z góry jedynie identyfikator każdej encji, a pełne instancje pobiera później, jeśli to potrzebne.¹¹ Jako parametr intentu powstrzymuje system od zmuszania każdego identyfikatora do rozwiązania w pełną instancję podczas rozwiązywania parametrów, co dla parametru przechowującego setki encji oszczędza czas i pamięć w potencjalnie krytycznym momencie.¹¹ Zwykła tablica [Entity] rozwiązuje wszystko zachłannie.

Czy RunSystemShortcutIntent da się użyć poza widżetami?

Nie. Istnieje wyłącznie po to, by zainicjować Button inicjalizatorem skrótu systemowego w celu umieszczenia w widżecie, i nie zapewnia żadnej funkcjonalności w innych kontekstach.¹² Ujawnia metadane dla interfejsu konfiguracji widżetu i reprezentuje akcję wybraną przez użytkownika; nie daje widżetowi ani aplikacji dostępu do akcji, parametrów ani implementacji bazowego skrótu.¹²

Pełny klaster ekosystemu Apple: typowane App Intents; dodatki iOS 26; kwestia routingu wobec narzędzi MCP; Foundation Models; nowa kontrola wywoływania narzędzi Foundation Models; rozróżnienie środowiska wykonawczego od oprzyrządowania LLM; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; serwery MCP obok aplikacji; Live Activities; środowisko wykonawcze watchOS; wnętrze SwiftUI; dyscyplina schematu SwiftData; wzorce Liquid Glass; dostarczanie wieloplatformowe; macierz platform; framework Vision; wnętrze @Observable; dostępność jako platforma. Centrum znajduje się w serii o ekosystemie Apple. Szerszy kontekst iOS z agentami AI opisuje przewodnik po tworzeniu agentów iOS.

Źródła