⬡ Dev Tools/2026-06-15Intermediate

Exposing Your Rork Max App to Siri and Shortcuts with App Intents

How to add App Intents to a Swift app generated by Rork Max so Siri and Shortcuts can invoke your actions, from registering an AppShortcut to the production gotchas, with real code.

Rork Max¹⁵⁵ App Intents⁴ Siri² Shortcuts³ Swift¹⁵

✦ Premium Article

I ran a small app whose whole job was logging glasses of water, and I noticed that "open the app, tap a button, close it" was quietly hurting retention. The more often an action repeats in a day, the more the act of opening itself becomes a reason to drop off. If telling Siri "I drank water" logs it, those three steps vanish.

Rork Max generates the Swift app, but a mechanism like App Intents that invokes actions from outside the app is a separate layer you add yourself, apart from the generated screen code. Here is the order I used as an indie developer, including where I tripped.

App Intents Expose Your App's Actions to the OS

Grab the big picture first. App Intents is a framework that declares a specific in-app action as a single "intent" and lets the OS entry points (Siri, Shortcuts, Spotlight) invoke it. Picture lifting the action out, free of the screen.

Once that clicks, the design order settles into "extract the action as a function first, then wrap it in an intent." Leave the screen logic and the action tangled together and you cannot carve out a callable form.

Build a Minimal Intent

Make one struct conforming to AppIntent. Put the real work inside perform().

import AppIntents
 
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description = IntentDescription("Logs one glass of water")
 
    func perform() async throws -> some IntentResult & ProvidesDialog {
        await WaterStore.shared.addGlass()
        let total = await WaterStore.shared.todayCount
        return .result(dialog: "Logged. That's glass number \(total) today.")
    }
}

When perform() returns ProvidesDialog, Siri reads the result aloud. For logging actions, just hearing that it succeeded changes the sense of trust entirely. For the real work, calling the data layer Rork Max generated is enough.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Working code and registration steps for a minimal AppIntent and AppShortcutsProvider

✦How to add a parameter so Siri asks for the value, and how to design natural phrases

✦Fixes for shortcuts not updating, phrase collisions, and confirmation dialogs in production

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Register It as a Shortcut Automatically

Creating the intent alone does not teach Siri a phrase. Tie it to invocation phrases with AppShortcutsProvider.

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Tell \(.applicationName) I drank water"
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

\(.applicationName) is required. Every phrase must include the app-name placeholder, and leaving it out fails the build. You can register several phrases, and offering two or three likely wordings raises recognition.

Let Siri Ask for a Value with a Parameter

To specify a count like "log three glasses," add a @Parameter. If no value is passed, Siri asks for it automatically.

struct LogWaterAmountIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water by Count"
 
    @Parameter(title: "Glasses")
    var glasses: Int
 
    func perform() async throws -> some IntentResult & ProvidesDialog {
        await WaterStore.shared.add(glasses: glasses)
        return .result(dialog: "Logged \(glasses) glasses.")
    }
}

The title on @Parameter becomes the wording Siri uses when it asks. Make it concrete, like "Glasses," and it asks "How many?" naturally. A vague name makes the prompt vague too.

What Bit Me in Production

A few things about voice invocation only became clear once people were actually talking to the app, not the docs.

Shortcut registration does not always take effect immediately. Change AppShortcutsProvider and Siri does not hear it until you relaunch the app. Calling AppShortcuts.updateAppShortcutParameters() at launch speeds up the refresh. I burned about an hour here on "I changed the phrase and it is not recognized."

When a phrase collides with another app, the wrong app launches. The app-name rule exists partly to avoid that collision, so the production-safe call is to avoid overly generic wordings (just "log it").

Gate destructive actions like deletion before perform(). Call requestConfirmation() in the intent and Siri asks "Are you sure you want to delete?" Split it: reversible actions like adding a log run fast without confirmation, irreversible ones like deletion run with it.

The simulator confirms basic behavior, but real recognition accuracy and the variability of spoken phrasing only show on a device. Finalize phrase design on a real device.

In numbers, just going from two phrases to three noticeably steadied voice launches in my own testing. Preparing enough wordings to absorb the variation up front turned out to be the shortcut.

Deciding Which Actions to Turn Into Intents

You do not need to turn every action into an intent. Add too many entry points and Siri cannot narrow the candidates, which actually lowers recognition. What I recommend is to pick only actions that "repeat many times a day" and "finish in one step." A frequent, reversible action like logging water is well worth a voice entry point, while a rare, complex action like changing settings is less confusing left on a screen.

When I am unsure, my test is to say the action aloud and judge whether it sounds natural. "I drank water" is natural; "toggle the notifications switch in settings on" is not. Actions that do not ride on the voice, I leave un-intented. Drawing that line early keeps the number of intents sensible and lightens the maintenance load.

What to Delegate to Rork Max, What to Hand-Write

My call is to hand-write the intent definitions and phrase design. Phrasing leans on the nuances of natural language, and leaving it to generation tends to mix in awkward wording. The data operations perform() calls and the result screen, on the other hand, can use Rork Max's generated code as-is. If the action is carved out cleanly as a function, the intent is just a thin wrapper around it.

App Intents is not a flashy feature, but on the single point of removing the friction of a daily-repeated action, it moves retention. On a different axis from a direct revenue pillar like AdMob, it underpins the base that keeps people coming back. The comfort of a one-word action is something you cannot walk back from once you taste it. Getting your first one shipped is well worth it.

Thank you for reading.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.