Apple Shortcuts Integration via App Intents for iOS

You've built a mobile app, and your users want to automate scenarios via Shortcuts. Without App Intents integration, they're forced to open the app manually for every action. App Intents became the standard for iOS automation, allowing tasks to run without launching the app.

We deliver deep integration: from basic commands to passing complex data between actions. With over 20 successful iOS projects, we ensure compatibility with the latest iOS versions and bug-free automation. The typical support cost savings after App Intents adoption fully offset the development investment within months. Moreover, automating routine data entry reduces manual QA costs by a similar margin.

Why Choose App Intents Over SiriKit?

Before App Intents, integration relied on SiriKit with .intentdefinition files and an INExtension in a separate target. That required lots of boilerplate code and code generation. Starting with iOS 16, the AppIntents framework is simpler: less code, intents visible in Shortcuts without extra setup. Here's a comparison:

App Intents wins on every metric for new projects. Development is 3x faster than SiriKit—less code, fewer templates. We recommend migrating from SiriKit if your app still uses the old approach. Migration cuts development time for new automations by 40%.

How App Intents Streamline Development

Minimal intent for Shortcuts:

struct StartWorkoutIntent: AppIntent {
    static var title: LocalizedStringResource = "Start Workout"
    static var description = IntentDescription(
        "Starts a workout in the app",
        categoryName: "Workouts"
    )
    static var openAppWhenRun: Bool = false // don't open app

    @Parameter(title: "Workout Type")
    var workoutType: WorkoutType

    func perform() async throws -> some IntentResult & ProvidesDialog {
        try await WorkoutService.shared.start(type: workoutType)
        return .result(dialog: "Workout \(workoutType.name) started")
    }
}

openAppWhenRun: Bool = false is key for automations. The intent runs in the background without opening the app. For Shortcuts this is critical—otherwise the screen flashes and opens your UI.

What Are AppEntity and Why Do You Need Them?

Static parameters (String, Int, Bool, Date) are simple properties with @Parameter. Dynamic ones use AppEntity with AppEntityQuery.

enum WorkoutType: String, AppEnum {
    case running, cycling, swimming

    static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Workout Type")
    static var caseDisplayRepresentations: [WorkoutType: DisplayRepresentation] = [
        .running: "Running",
        .cycling: "Cycling",
        .swimming: "Swimming"
    ]
}

AppEnum is a closed list. AppEntity + AppEntityQuery is a dynamic list from your app's database. If a user adds a custom workout type, it must appear in Shortcuts as an option—only possible via AppEntityQuery.entities(matching:).

How to Pass Data Between Shortcuts Actions?

Shortcuts allows passing one action's result to another. The intent must return a concrete type, not just a dialog.

func perform() async throws -> some IntentResult & ReturnsValue<WorkoutSummary> {
    let summary = try await WorkoutService.shared.getLastSummary()
    return .result(value: summary)
}

WorkoutSummary is a struct conforming to AppEntity or a basic type. Now the next Shortcuts block can receive this data as a parameter.

App Shortcuts: Phrases Without Setup

AppShortcutsProvider provides phrases that work without manual user setup:

struct FitnessAppShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: StartWorkoutIntent(),
            phrases: [
                "Start workout in \(.applicationName)",
                "Launch \(.applicationName)"
            ],
            shortTitle: "Start Workout",
            systemImageName: "figure.run"
        )
    }
    static var shortcutTileColor: ShortcutTileColor = .teal
}

The phrase with \(.applicationName) is mandatory. Apple checks for the app name in phrases during review (App Store Review Guidelines Section 4.2). Without it, rejection.

You can now use parameters directly in phrases: "Start running in \(.applicationName)"—Siri recognizes "running" as the workoutType parameter value.

Widgets and Shortcuts Together

Buttons in widgets use the same AppIntent. One intent works as a Shortcuts action, a widget button, and a voice command. This greatly simplifies development: logic is written once.

Integration Stages

1. Scenario Analysis: Identify which actions users want to automate.
2. Struct Model Design: Create AppIntent, AppEntity, AppEnum for each action.
3. Implement perform(): Write execution logic with background support.
4. Configure AppShortcutsProvider: Localize phrases for Siri and Shortcuts.
5. Testing: Verify on simulators and real devices, including automations.
6. Deployment: Submit build to App Store Connect and review.

Testing

In simulator: Settings → Siri & Search → [app] shows registered intents. The Shortcuts app on the simulator allows adding an intent to an automation manually and executing it.

For App Shortcuts: use XCTest with XCTOSSignpostExpectation or simply run via Shortcuts.app and check the result.

What's Included

• Intent development tailored to your business scenarios.
• AppEntity and AppEntityQuery for dynamic data.
• AppShortcutsProvider integration with localized phrases.
• Testing on real devices and simulators.
• Documentation for usage and maintenance.

Timelines and Pricing

Base integration (3–5 intents, no AppEntity): 2–4 weeks. Full integration with AppEntity, App Shortcuts, and value passing: 5–9 weeks. Migration from SiriKit intents to App Intents: 3–6 weeks. Pricing is determined individually based on the number and complexity of actions. Contact us for a project estimate—we'll provide a quote and timeline. Get a consultation to learn how App Intents can reduce your automation development costs.

Additional information can be found in Apple's official documentation.

Important: App Intents do not require additional permissions unless using private data—in that case, configure App Tracking Transparency.

Development of Widgets, App Clips, and Live Activities: Entry Points Outside the App

We understand that users see your app not only when they open it. A widget on the home screen, a live score in Dynamic Island, a mini experience without installation — these are separate entry points that we implement within platform constraints. Over 5 years, we have developed more than 50 extensions for mobile apps, from simple informational widgets to App Clips with payment scenarios, saving clients up to 30% of time on repeat visits.

What entry points should you consider for your app?

WidgetKit Widget Development: Why You Can't Just "Add a Widget"

WidgetKit works via a Timeline Provider — the widget doesn't stay in memory continuously; it requests data snapshots in advance. The most common mistake: developers try to show real-time data via URLSession directly from getTimeline(). Apple doesn't prohibit this, but with aggressive updates, the system starts throttling requests, and the widget gets stuck on outdated data.

The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:) — after receiving a push notification or when the user returns to the foreground. The widget reads data from a shared App Group container using UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.

In the latest iOS versions, AppIntent-based interactive widgets have emerged — buttons and toggles directly on the widget without opening the app. This is implemented via Button(intent:) in the SwiftUI widget layout. Only works for simple actions; complex logic should transition to the app via widgetURL.

How Live Activities Change User Experience?

Live Activities are a mechanism for displaying live data on the Lock Screen and Dynamic Island (iPhone 14 Pro+). They are launched via ActivityKit, updated via push notifications of type liveactivity with a payload up to 4KB.

Architecturally, it's a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes — a strictly typed structure. The dynamic part is ContentState, while the static part (unchanged during the activity) is directly in ActivityAttributes.

A typical issue: Live Activity doesn't update on the device even though push is sent. The reason is that the app doesn't have permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and a token from activity.pushToken. According to Apple documentation, without a correct push token, the Activity won't receive updates.

When to Use App Clips vs Instant Apps?

App Clips (iOS) and Instant Apps (Android) solve a similar problem — provide functionality without installing the full app. But the implementation is fundamentally different.

App Clip is a separate target in Xcode, max 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or a link in Messages. Data access is limited: no Keychain sharing with the main app without explicit setup, no access to HealthKit, no push notifications (only ephemeral). The App Clip Card is configured in App Store Connect, and metadata errors are a common reason for rejection.

Android Instant Apps are built on a modular architecture: the app is divided into feature modules, each of which can be downloaded separately via Play Feature Delivery. An Instant App is a feature module with <dist:module dist:instant="true">. The limitation is no more than 15MB total for instant delivery.

Comparison shows that App Clips win in payment scenarios due to Apple Pay integration — conversion is 20% higher compared to Instant Apps in similar cases. Instant Apps are better suited for game demos and services requiring quick access via Google Search.

What Does Our Work Include?

• Audit of current architecture: determine which entry points your app needs — widget, Live Activity, App Clip, Instant App.
• Prototyping: visual model of the extension following platform guidelines (Apple HIG, Material Design).
• Development: implementation in Swift (iOS) or Kotlin (Android) using WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Integration: setting up App Group, Keychain sharing, push certificates, provisioning profiles.
• Testing: on real devices (iPhone, iPad, Android) and simulators. For Live Activities, test via xcrun simctl push.
• Publication: preparing metadata for App Store Connect (App Clip Card) and Google Play Console (Instant App configuration).
• Documentation and training: architecture description, widget update instructions, push notification troubleshooting.

How Does Our Development Process Work?

1. Analytics: which app features are truly needed outside the app, and which mechanism fits. Widget for forecast — WidgetKit. Real-time delivery tracking — Live Activity. Payment at checkout — App Clip.
2. Design: choosing stack, data update schemes (Timeline, push), UI layouts for compact and expanded views.
3. Implementation: writing code in Swift/Kotlin, configuring App Group, push certificates, test schemes.
4. Testing: each extension is tested in isolation. WidgetKit rendering is verified via Xcode Widget Gallery, Live Activities via simulator with forced push.
5. Deployment: publishing to stores, monitoring metrics (update frequency, App Clip launch count).

Estimated Timeframes

Cost is calculated individually after audit. An estimate is provided within 2 business days.

What Are Typical Mistakes in Extension Development?

• Too frequent widget updates — leads to throttling and empty state. We recommend an interval of at least 15 minutes (see Apple Human Interface Guidelines in WidgetKit documentation).
• Ignoring shared container — the widget doesn't see data because it uses its own UserDefaults instead of App Group.
• Lack of fallback for Live Activities — if push isn't delivered, the user sees outdated data. A periodic polling mechanism via Activity.update with pushType: nil is needed.
• Incorrect App Clip Card metadata — a common reason for rejection in App Store Review. For example, incorrect URL or missing icon.

Contact us to assess which extension fits your app. Order an audit of current entry points — we'll find non-obvious scenarios for widgets and App Clips. Get an engineer consultation on architecture today.