:format(webp)){kind=small}
:format(webp))
If a user asks an assistant to bookmark a conference session, the assistant should not get a new way to decide which session—or which account—to change. It should call the same authorized bookmark capability the app already uses. That is the right order for mobile assistant work: define the action boundary first, then add Siri or Android integration around it.
The assistant is a new caller, not a new source of authority
A screen hides a lot of decisions. A user opens a conference, finds a session, taps a bookmark icon and sees the result. The screen may already know the selected conference and signed-in account. Its button may be attached to a specific session ID. Remove that screen and the request “bookmark the architecture session” becomes underspecified: Which conference? Which session with that title? Which account? Is the session still available?
The assistant can help interpret a request, but it should not settle those questions by guessing. The action needs explicit inputs and a trusted place to check them. A useful boundary for addBookmark would accept a stable session identifier, resolve its conference, establish the signed-in user, verify that the user can modify that account’s bookmarks, perform the write and return an outcome the app can display. If the request identifies two possible sessions, resolution should stop and ask for clarification rather than pick one.
That division also keeps product ownership clear. The app and its backend decide what a bookmark means and who may create one. Siri and Android tools describe and invoke that capability. Tool descriptions improve discovery; they do not confer permission. Apple identifies indirect prompt injection and unintended side effects as risks for agentic actions, and supports authenticationPolicy = .requiresAuthentication for custom App Intents. Authentication and contextual confirmation help, but neither replaces the app’s decision about whether this user may change this particular record Apple’s security guidance. The same principle applies to user- and record-level permissions at an agent tool boundary.
This is why an assistant integration should not become a parallel product implementation. If the app’s button and its assistant adapter can disagree about authorization, side effects or success, the team has created two workflows to maintain and two places for policy to drift.
Choose actions by their boundaries and consequences
Start with a small inventory, not a list of impressive prompts. For each proposed action, record the user goal, read or write classification, required fields, entity identifier, source of truth, authorization rule, confirmation requirement, result and error states. The inventory will expose actions that sound simple in conversation but rely on substantial screen context.
Proposed action | Inputs and source of truth | Boundary to enforce | Result or stop condition |
|---|---|---|---|
Find a conference session | Conference and search terms; session repository | Do not silently choose among matching sessions | Return identifiable matches or ask for clarification |
Add a bookmark | Stable session ID and signed-in account; current session and bookmark state | Check the account and session at execution; make a repeated request safe | Return the saved state, or an explicit missing, stale or unauthorized outcome |
Remove a bookmark | Stable session ID and signed-in account; current bookmark state | Check authorization; consider confirmation if the product treats removal as consequential | Return the resulting state, or a clear failure |
The table is a design tool, not an instruction to expose every row. A read action makes a good first pilot because a bad match is visible without changing data. A reversible write, such as a bookmark, then tests whether identity, current state, retries and error handling work across the boundary. For a destructive or hard-to-reverse action, require stronger review in the app—or leave the action on-screen.
Be precise about ambiguity. A session title is a useful search term but a poor write target if titles repeat. A selected account in the UI may not be available to an assistant caller. A session found earlier may have changed by the time the user approves a write. Resolve to an identifier, then recheck the actor, target and current state when executing. Treat missing or stale targets as outcomes to report, not reasons to proceed with the closest match.
The supplied Confetti AppFunctions example illustrates a sensible scope: getConference, listSessions, addBookmark and removeBookmark use existing repositories, and bookmark changes check for a signed-in user. It demonstrates calls through a testing agent. Its author explicitly left Gemini testing through Android MCP as a next step, so it should not be read as evidence of a production Gemini integration.
There is also a straightforward reason not to build an assistant entry point: the existing screen may already make the task easy, or the requested action may require enough comparison and review that moving it into a conversation adds risk without saving work. Judge each proposed action against those costs, rather than treating assistant coverage as a feature count.
Adapt one capability to Siri and Android without duplicating it
Apple’s November 3, 2026 Siri AI Developer Preview announcement opened access through the iOS 27.3 beta. Apps can expose content and custom actions through App Intents, and Apple introduced skills to guide Siri through combinations of actions. That is an opportunity to adapt an existing action boundary, not a reason to put bookmark policy inside an intent. The intent should resolve its platform-facing inputs, call the application capability and map its outcomes back to the caller.
It is also not a generally available acquisition channel. Apple described this as early developer access ahead of customer shipping, said submission would open in spring and had not yet published full terms and usage policies. Siri AI requires an Apple Intelligence-enabled device and a supported language; Apple said it was unavailable in the EU on iOS, iPadOS and watchOS, and to users under 13. Certain server-model features have variable daily usage limits. A screen-based journey therefore remains a product requirement, not merely a temporary testing convenience.
On Android, AppFunctions expose app data and actions as on-device tools to authorized callers on Android 16 or later. Google’s implementation guide calls for compileSdk 37 or higher and Android Gradle Plugin 9.1.0 or higher; its examples use @AppFunctionServiceEntryPoint, @AppFunctionDeclaration and KSP-generated service and schema metadata. It also documents runtime enablement and disablement for functions gated by an account or feature. That gate can help avoid offering an unusable function, but execution still needs its own authorization check Google’s implementation guide.
Check dependencies before copying an example. As of November 14, 2026, the newest listed Jetpack AppFunctions release was 1.0.0-rc01, released November 4; Google’s November 10 implementation example still showed 1.0.0-beta01. Neither version number establishes production assistant reach. Google still described Gemini integration as experimental and limited to selected apps and agents, with early-access registration not guaranteeing integration. Its Connected Apps announcement said local prototyping was possible, while production preview capacity remained limited to selected, production-ready apps in supported categories.
There is a separate architecture choice for server-owned workflows. Google presents a remote MCP server as its default route for foundational capabilities across Android, iOS and the web. Android MCP/AppFunctions complement that route when an action depends on device-local state, hardware or close OS integration. Neither route is a substitute for Apple App Intents: an MCP integration for Google surfaces does not make an app available through Siri. Pick the adapter according to where the capability lives and which surface needs it.
For a React Native app, this still means planning Swift App Intents and Kotlin AppFunctions as native adapters. Keep shared authorization and business policy in the existing backend or domain layer where appropriate; do not rewrite the app merely to add assistant access. If assessing those platform paths alongside an existing app release, mobile app development support is most useful when it starts with the action inventory rather than an assistant demo.
Prove the action and its fallback before expanding access
Test the capability before involving a model. Call it with a valid session ID, then with a missing ID, a stale target, the wrong account and an ambiguous search result. Invoke a write twice and check that the resulting state is safe and intelligible. Check that a network failure leaves the user with a clear result rather than an apparent success. The same cases should hold whether the caller is a screen or an adapter.
On iOS, Apple’s App Intents testing guidance describes executing intents and entity queries on-device from a separate XCUITest process. Move from intent tests to Shortcuts and Spotlight, then to an end-to-end Siri test on an eligible beta device. Passing an intent test proves the intent can run; it does not prove Siri will select that intent for a spoken request or resolve the right entity.
On Android, list and invoke AppFunctions with adb and the testing agent before treating Gemini access as a release dependency. Test enablement when the account or feature is unavailable, then test the same unauthorized and stale-input cases at execution. Google advises narrow data and action access, warns that system agents may process queries on a server, and recommends an app-provided clear confirmation for destructive actions Android AppFunctions implementation guidance. Design exposed data accordingly; do not assume an on-device tool means every part of the interaction stays on-device.
Finally, test the ordinary screen journey under conditions where the assistant is absent: an ineligible Siri device or region, an Android device without AppFunctions, an action the assistant fails to discover, or a failed network request. The user should still be able to complete the task and verify its state in the app. Count successful completions and erroneous writes, not only tool invocations.
Make a staged release decision
Use this gate before widening an assistant integration:
Select one read and one reversible write. Record their required fields, stable target IDs, source of truth, actor, side effects, confirmations and explicit error outcomes.
Prove shared behavior. Confirm that the screen and each adapter call the same capability; recheck authorization and state at execution, and make repeat writes safe.
Test each layer separately. Run direct capability tests, iOS intent and entity tests, Android local tool tests, and then end-to-end assistant tests only where access and devices permit.
Verify the fallback. Complete both workflows in the app without Siri AI or Android agent access, including after discovery and network failures.
Expand only against evidence. Review completion, incorrect-action rates, device coverage and the maintenance cost of both platform adapters. If an action still needs extensive on-screen review, keep it on-screen.
:format(webp))
:format(webp))
:format(webp))