App Intents in React Native, now that SiriKit is gone

If you search for how to add Siri support to a React Native app, almost everything you will find describes SiriKit, INIntent definition files, or the react-native-siri-shortcut package. All of it is now the wrong answer, and the package in question has not been meaningfully maintained in years.

Apple deprecated SiriKit at WWDC 2026. Since the public release of iOS 27, an app that still relies on it compiles and runs, but receives no voice traffic, no Spotlight indexing and no Apple Intelligence personalisation. It is not broken. It is invisible, which is worse, because nothing in your crash reports will tell you.

The two frameworks are not interchangeable

This is the part that catches teams out. SiriKit worked by mapping your app onto Apple's fixed vocabulary of domains: messaging, payments, workouts, ride booking. If your app did something Apple had not anticipated, you were out of luck.

App Intents inverts that. You declare arbitrary actions with typed parameters, and the system works out how to surface them. That is far more powerful, but it means an existing SiriKit integration cannot be migrated mechanically. The concepts do not line up. You are rewriting the integration, not porting it.

Where the code actually lives

An App Intent is Swift, in your iOS target. There is no JavaScript equivalent and there will not be one, because the system needs to read your intents without launching your app. That constraint drives everything else.

Concretely, in a React Native project you end up with three pieces. First, a Swift struct conforming to AppIntent, declaring its parameters and its title. Second, an AppShortcutsProvider that gives Siri the phrases people will actually say. Third, a way for the intent to reach your app's data, which is the part nobody writes about.

The part nobody writes about

Your intent runs in a separate process from your React Native app. It cannot call into your JavaScript. It cannot read your AsyncStorage. If the user says the phrase while your app has never been launched since reboot, there is no JavaScript context in existence at all.

There are two honest strategies, and the choice matters.

Deep link and let the app do the work. The intent opens the app with a URL, and your existing JavaScript handles it. Simple, reliable, and it works with the code you already have. The cost is that the app has to come to the foreground, which defeats the purpose of a Control Center button or a hands-free Siri command.

Share state through an App Group and act natively. The intent reads and writes a store both processes can see, and returns a result without opening anything. This is what makes a Control Center toggle feel instant. The cost is that a slice of your business logic now exists in Swift, and has to stay in step with the JavaScript version.

In Ticket, a parking timer, I used the second approach: starting a session from Siri, from the Control Center or from an NFC tag on the dashboard has to work without unlocking the phone, so the intent writes to a shared store and the app catches up later. The shared surface is deliberately tiny — a start time and a duration — because every field you share is a field that can drift.

Ticket is fully native, so in its case both sides of that store are Swift. In a React Native app the same pattern holds, with one extra cost: the JavaScript side has to read the store on wake and reconcile, because the intent may have run while the app was not even in memory.

What to check if you are migrating

• Search your iOS target for INIntent, .intentdefinition files, and any dependency mentioning Siri shortcuts. Those are what stopped working.
• Test with the app force-quit and the device freshly rebooted. This is the case that reveals whether you actually built the integration or just tested the happy path.
• Decide your shared surface before writing anything. The smaller it is, the less it will drift.
• Write the Siri phrases as a person would say them, not as your feature is named internally. "Start parking" beats "Create session" every time.

Whether this is worth doing at all

Honestly: for many apps, no. If nobody was using your Siri integration when it worked, rebuilding it on App Intents will not create demand that was not there.

It is worth it when the action is something people do repeatedly, in a hurry, often with their hands full. Parking, timers, logging something, starting a session. If your action does not fit that description, spend the week on something else — and I would rather tell you that now than invoice you for it.