Apple formally deprecated SiriKit at WWDC 2026. That’s not a surprise — App Intents has been the recommended path for a few years — but the framing changed: apps that skip App Intents are now described as “invisible” to the new Siri, Spotlight, and Shortcuts, not just missing a nice-to-have feature. If voice, search, or automation touches any part of your app, this is a real roadmap item, not a someday task.

The timeline is shorter than it sounds

SiriKit has roughly a two-to-three-year window before it stops functioning outright, which sounds comfortable. It isn’t, in practice: the discoverability penalty starts immediately with iOS 27’s fall release, since only App Intents-adopting apps get pulled into Siri’s new cross-app workflows, Spotlight results, and the dedicated Siri app. Waiting until year two of that window means two years of reduced visibility on platforms where discoverability already drives a meaningful share of engagement.

timeline
    title SiriKit → App Intents Transition
    section 2024-2025
        App Intents recommended : Soft push
    section WWDC 2026
        SiriKit officially deprecated : Discoverability penalty begins
    section iOS 27 (Fall 2026)
        App Intents required for Siri/Spotlight/Shortcuts : "Invisible" apps without them
    section 2027-2028
        SiriKit fully non-functional : Hard cutover window closes

What App Intents actually requires now

The framework itself is simpler than SiriKit ever was — no XML intent definitions, no separate extension target, just Swift types conforming to AppIntent. But the 2026 additions raise the bar on what “done” looks like: entities need to conform to AppEntity so Siri has semantic understanding of your data (a shift, a customer record, an order), long-running actions should support streaming responses with progress UI, and on-screen elements need the .appIntentEntity() modifier plus solid accessibility metadata so Siri can reason about what’s visible on screen. Multi-turn dialogue support is also expected now — Siri can ask a clarifying question instead of failing outright on an ambiguous request, but only if your intent’s parameter resolution supports it.

flowchart TD
    A[User Voice / Shortcuts / Spotlight] --> B{App Intents available?}
    B -->|Yes| C[AppEntity + AppIntent]
    C --> D[Semantic understanding of data]
    C --> E[Streaming progress UI]
    C --> F[Multi-turn dialogue]
    C --> G[On-screen .appIntentEntity]
    B -->|No| H[App is invisible to new Siri]
    H --> I[Reduced discoverability]

The part enterprise developers should read twice

Each intent now declares whether cloud routing is permitted, which matters a lot for banking, healthcare, and other regulated apps handling data that can’t leave the device or a controlled environment. It’s a welcome level of control, but it also means someone on your team needs to actually make that decision per intent rather than accepting a default — getting this wrong is a compliance conversation, not just a bug. On the cost side, apps in the App Store Small Business Program get free Private Cloud Compute access for Apple’s on-device models, which removes a real budget line item for smaller shops experimenting with AI-assisted features.

flowchart LR
    Intent[App Intent] --> Decision{Cloud routing allowed?}
    Decision -->|No| OnDevice[On-device only / Private Cloud Compute]
    Decision -->|Yes| Cloud[May leave device]
    OnDevice --> Compliance[Banking / Healthcare safe]
    Cloud --> Risk[Compliance review required]

The takeaway

Don’t treat this as an AI feature request — treat it as the new baseline for app discoverability, the same way you’d treat a required privacy manifest or App Store metadata field. For client work, especially anything with a scheduling, ordering, or lookup flow, I’m now scoping App Intents adoption into the same bucket as accessibility and localization: not optional, not urgent enough to drop everything, but something that quietly costs you real users if you skip it for two release cycles in a row.