Google quietly shipped one of the most consequential mobile platform changes in years, and most product teams are still sleeping on it.
Android App Functions, introduced for Android 16 and currently in experimental preview, let an Android app expose its capabilities as discoverable “tools” that an on-device agent (starting with Gemini) can call directly. Not deep links. Not intents that open a screen and hope. Actual function calls, executed locally, with typed parameters and structured return values.
If you build mobile apps, this changes two things: how users will reach your app, and what counts as “good” mobile UX over the next 24 months.
What App Functions actually are
An App Function is a Kotlin function in your Android app annotated with @AppFunction. The Jetpack library scans those annotations at build time, generates an XML schema describing every exposed function, and the OS indexes them. An agent like Gemini can then query the system, find functions that match a user’s request, and invoke them with the right parameters.
A minimal example, straight from the Android docs:
@AppFunction(isDescribedByKDoc = true)
suspend fun createNote(
appFunctionContext: AppFunctionContext,
title: String,
content: String
): Note {
return noteRepository.createNote(title, content)
}The KDoc above that function becomes the description the AI uses to decide when to call it. The parameters and return type form the schema. The system handles routing, permissions (EXECUTE_APP_FUNCTIONS), and lifecycle.
When a user tells Gemini “add picking up the package at 5 PM to my reminders,” the assistant doesn’t open your app. It calls createReminder("pick up package", time = 17:00) directly inside your app’s process, gets the result, and reports back.
That is a different model of mobile interaction than anything Android has shipped before.
Why this matters now, not in two years
Three reasons.
Discovery is moving up a layer. For ten years, app discovery has meant App Store ranking, ASO keywords, and someone tapping an icon on a home screen. App Functions add a new surface: the assistant. If your competitor’s note-taking app exposes createNote and yours doesn’t, Gemini calls theirs. The user never opens either app to compare.
Workflows cross app boundaries now. Google’s own example is telling: “find the noodle recipe from Lisa’s email and add ingredients to my shopping list.” That request spans Gmail, a recipe parser, and a grocery list app. The first apps that expose clean App Functions in their category will become default participants in cross-app workflows. The rest will be skipped.
On-device execution closes the latency gap. Server-side tool calling (the standard MCP pattern) costs a network round trip and an inference call. App Functions run locally, against your app’s existing state, with no extra latency. For anything time-sensitive (timers, calendar entries, in-app actions during navigation) the on-device path will simply feel faster.
What this means if you ship a Flutter app
We are a Flutter shop, so this is the question we have been asked twice in the last week: does App Functions work with Flutter?
The honest answer: yes, but you write the Android side in Kotlin.
App Functions live in the Android platform layer. Your Flutter code does not see them directly. The pattern is the same one Flutter teams already use for Bluetooth, background services, and platform-specific features:
- Write the
@AppFunction-annotated Kotlin code inandroid/app/src/main/kotlin/... - Use a method channel to call into your Flutter business logic (or your shared repository layer if you already split it out)
- Return a serializable result from Kotlin back to the system
This is normal Flutter platform integration, not exotic work. For a TMZ project with a clean BLoC or repository structure, exposing three or four core App Functions is roughly a one-to-two-week effort, including testing through adb shell cmd app_function list-app-functions and against the sample agent app.
iOS does not have an equivalent yet. Apple Intelligence and App Intents cover overlapping ground on iOS, but they are a separate implementation. A Flutter codebase is actually an advantage here: your shared business logic gets exposed twice (once through App Functions on Android, once through App Intents on iOS) without rewriting the underlying domain code.
What we tell clients to do this quarter
If you ship a consumer or productivity app on Android, three concrete actions.
Audit which of your core actions belong as App Functions. Not every screen needs one. The candidates are the verbs a user would speak out loud: create, add, find, schedule, send, start, stop. For a fitness app, that is logWorkout, startTimer, getLastWeekSummary. For a note app, createNote, searchNotes. Keep the list short and high-value.
Register for the Early Access Program now. The Gemini integration is in private preview as of May 2026. The apps that are wired up when it ships publicly will be the defaults in their categories.
Plan for both platforms. App Functions today is Android only. If you have an iOS user base too, scope an App Intents implementation in the same sprint. The schema design work transfers; the platform code does not.
The bigger shift
For most of mobile history, the unit of distribution was the app. Users found an app, installed it, opened it, learned its UI, came back to it. App Functions moves a piece of that loop up a level. The unit of distribution becomes the capability. Your app becomes one of many places where “create a calendar event” can happen, and the assistant picks the one with the best schema, the best permissions, and the best signal that the user actually wants it.
That is uncomfortable if you measured success in sessions and screen time. It is an opportunity if you measured success in jobs completed for the user.
We are building a small reference implementation of App Functions on a Flutter sample app over the next two weeks. If you want us to take a look at where this fits in your product, the contact form is the easiest way to start.
TMZ Software builds Flutter and native mobile apps for startups and SMEs in Western Europe and North America. We work directly with founders and CTOs, no account managers in between. Get in touch.
