Your next user might never search for your app

For most of the life of the smartphone, finding an app has started with a search. You know roughly what you want, you open the App Store or Google Play, you type a few words and you pick from the results. Apple's own figures show just how central that habit is. According to Apple Ads, 70% of App Store visitors use search to discover apps, and almost 65% of downloads happen directly after a search (that's based on Apple's 2022 data).

That behaviour has shaped an entire discipline. App store optimisation exists because the person doing the searching is also the person doing the choosing. You give them the right keywords so they find you, the right screenshots so they understand you, and enough good reviews that they trust you more than the app sitting just below yours in the results. Everything about the model assumes a human is scanning a list and making a judgement.

It's worth pausing on that assumption, because it's the part that's starting to give way. When someone asks an assistant to get something done, there's no list to scan. The assistant does the scanning on their behalf, and it's looking for very different signals.

It would be easy to treat all of this as a distant prediction, but 2026 has been the year the three biggest assistant platforms moved from talking about it to shipping it. It's worth looking at each one, because they're arriving at the same place from slightly different directions.

In January, Apple and Google announced a multi-year collaboration under which the next generation of Apple Foundation Models will be based on Google's Gemini models and cloud technology, helping to power future Apple Intelligence features including a more personalised Siri. Apple then used WWDC in June to show what that Siri looks like, including deeper links into the apps on your phone.

The piece that matters most for app owners is a framework called App Intents. App Intents is the way an iOS app tells the system what it can do, such as "start a workout", "book a table" or "show my latest invoice", in a structured form that Siri, Spotlight, Shortcuts and widgets can all understand and call. It isn't new, as it's been around since iOS 16, but its role has grown considerably. Coverage of WWDC26 reported that Apple formally deprecated SiriKit, leaving App Intents as the framework Siri uses to call into third-party apps, with a window of a couple of years before older SiriKit-based features stop working.

In practical terms, if your iOS app doesn't describe its key actions through App Intents, the new Siri has very little to work with when someone asks for something your app could have helped with.

Google has been heading the same way on Android. In February, the Android team announced AppFunctions, which lets apps expose data and functionality directly to AI agents and assistants such as Gemini, so the assistant can find the right function and run it from a natural-language request. In the same announcement, Google described a separate UI automation framework that lets Gemini carry out multi-step tasks in installed apps, starting as a beta with a curated selection of food delivery, grocery and rideshare apps in the US and Korea.

The line from that announcement that we keep coming back to is from Matthew McCullough, VP of Product Management for Android Development, who wrote that success is shifting from getting users to open your app, to successfully fulfilling their tasks and helping them get more done faster. That's Google telling app makers, fairly directly, that the measure of a good app is changing.

Google has also been clear about where the user stays in control. The same post explains that people can watch a task's progress, take over manually at any point, and that Gemini is designed to alert users before completing sensitive tasks such as making a purchase. We'll come back to why that matters for design.

The third piece of the picture sits outside the phone's operating system altogether. In October 2025, OpenAI introduced apps in ChatGPT and the Apps SDK, letting third-party services such as Booking.com, Spotify and Zillow run inside a chat, with their own interactive interface.

At the same launch, OpenAI said developers building with the SDK could reach over 800 million ChatGPT users, and Sam Altman told the DevDay audience that more than 800 million people now use ChatGPT every week.

What's interesting here is how OpenAI describes discovery. People can call an app by name, but ChatGPT can also suggest one when it's relevant to the conversation, so someone talking about buying a home might be offered the Zillow app without ever asking for it.

OpenAI has since opened a directory where people can browse and add apps, but that "suggested at the right moment" behaviour is the part that feels genuinely different from a store. It's worth noting that when apps first launched, they weren't available to users in the UK, the European Economic Area or Switzerland, so if your audience is mainly in the UK it's a channel to keep an eye on rather than rely on today.

Platform

What the assistant can do

How your app plugs in

Siri (iOS)

Understand requests in natural language and act in apps on the user's behalf

App Intents

Gemini (Android)

Find and run functions in installed apps, and carry out multi-step tasks in selected categories

AppFunctions, plus Google's UI automation for some categories

ChatGPT

Suggest and run third-party apps inside a conversation

Apps SDK, built on the Model Context Protocol

The detail differs from platform to platform, but the direction is the same. Each one gives your app a way to describe what it can do in a form a machine can read, and each one lets the assistant decide when to use it.

This is the part where we have to be honest about what's known and what isn't. None of these companies publish the exact logic their assistants use to pick one app over another, and we'd be wary of anyone who claims to know it precisely. What we can do is look at how these systems are built and reason about the signals they're likely to rely on.

The simplest way we've found to explain it is the difference between browsing a high street and asking a concierge. When you browse, you walk past the shop windows and decide for yourself which one looks right. When you ask a concierge, you say what you want, and they send you somewhere based on what they know about the options and about you. The shop with the most eye-catching window doesn't automatically win. The one that clearly does what you asked, and that the concierge trusts to deliver, does.

An assistant is in that concierge role. When someone asks for something, it's likely to be weighing up questions such as these:

• Is there an app installed that can do this? For Siri and Gemini, apps already on the device are the natural starting point, so being installed and set up still matters a great deal.
• Has the app described an action that matches the request? An app that has clearly declared "reorder a previous purchase" is in a far better position than one that only exposes "open app".
• Can the assistant collect what the action needs? If an action needs a date, a location and a number of people, the assistant has to be able to gather those from the request or ask for them.
• What has this person done before? Habits and previous choices are useful context, which is why the app someone already uses will often get the job.
• Is the user comfortable with it? Permissions, and whether the user has connected the app, decide whether the assistant can act at all.

Here's how that compares with the way discovery has worked until now.

Search-led discovery

Intent-led discovery

Who chooses

The user, from a list of results

The assistant, on the user's behalf

What the user says

A few keywords, such as "restaurant booking app"

The outcome they want, such as "book a table for four on Friday"

What the app is judged on

Name, keywords, screenshots, ratings

Whether it exposes a matching action, and how clearly that action is described

Where your brand shows up

Store listing, icon, onboarding

Often a short confirmation, sometimes your own screens

The implication is uncomfortable but important. If your app doesn't describe what it can do in a way the assistant understands, it may simply not be considered, however good the app is once someone opens it.

For years, the shop window for an app has been its store listing. In an intent-led world, a growing share of that window is made up of the actions you expose to the operating system and to assistants. That shifts some decisions that used to sit purely with developers into the hands of product owners, because they're really decisions about what your product is for.

The first decision is which jobs a person could reasonably hand over to an assistant. This is rarely every feature. In our experience, most apps have two or three tasks that account for the bulk of what people come to do, such as checking a balance, booking a slot, reordering something, logging an activity or finding a document. Those are the actions worth describing really well first, because they're the ones people are most likely to ask for in their own words.

The second is how each action is named and described. This is where it starts to feel a lot like writing store copy, except the first reader is a machine. A vague description makes it harder for the assistant to match a request to your app, while a precise one, written in the language your users would naturally use, makes it easier. It's worth bringing the same care to this that you'd bring to a product page.

The third is what each action needs from the user and what it gives back. If someone asks to book a table, the assistant needs to know the restaurant, the time and the party size, and it needs to know what to do if one of those is missing. When the booking is made, your app needs to send back something the assistant can turn into a clear confirmation. Getting these inputs and results right is the difference between an assistant that completes the job and one that gives up halfway and sends the user into your app to finish it.

The last is trust. Every action you expose raises questions about what data the assistant can see and what it's allowed to do without asking first. That's partly a technical matter, but it's also a product and brand decision, because the way your app behaves when someone isn't looking at it says a lot about how much you respect the people using it.

One of the quieter consequences of all this is that some of your users will complete a task without ever seeing your interface. For anyone who has spent months refining a checkout flow or an onboarding journey, that can feel like a loss. We'd encourage you to see it a little differently, because it opens up a new set of design questions that are genuinely interesting to work through.

Think about how your brand comes across in a single line of confirmation. When Siri or Gemini tells someone their order is placed, what does that message say, and does it sound like you? It's a very small surface, but for some people it will become the most frequent contact they have with your product, so the tone, the clarity and the detail all matter.

Then there's the question of when to bring someone back into the app. Some tasks are perfectly suited to being handled in the background. Others involve a meaningful choice, a payment, or something personal enough that a person will want to see it properly before agreeing.

Google's own approach, where Gemini checks with the user before sensitive actions like purchases, is a useful model here. Part of designing for assistants is deciding, deliberately, where those handover points sit, and making sure that when someone does land in your app, it picks up exactly where the assistant left off so they don't have to start again.

Finally, it's worth thinking about how you'll measure success. If a growing number of tasks happen without anyone opening your app, then sessions, screen views and time in app will tell you less about how well you're serving people. Completed tasks, repeat use of an action and the rate at which assistant-led tasks need a person to step in are likely to become far more useful numbers. That's very much in line with Google's point about success moving towards fulfilling tasks rather than getting people to open the app.

You don't need to rebuild your app to get ready for this. For most products, it's a case of looking at what you already have through a slightly different lens and making some focused changes. If you're wondering where to begin, this is roughly the order we'd suggest.

• List your most important tasks. Write down the handful of things most of your users come to your app to do, ideally backed up by your analytics rather than gut feel.
• Check what you already expose. Many apps already have some Siri Shortcuts, App Intents or Android shortcuts in place, often added a few years ago and rarely revisited, so it's worth knowing where you're starting from.
• Map those tasks to each platform. Work out which tasks should become App Intents on iOS and AppFunctions on Android, and whether a ChatGPT app would make sense for your audience and your market.
• Write clear, specific action descriptions. Treat them with the same care as your store listing, using the words your users would actually say.
• Decide where a person must confirm. Anything involving money, personal information or sending something on someone's behalf should have a clear checkpoint.
• Agree how you'll measure it. Set up tracking for completed tasks and assistant-led use before you launch, so you can see whether the work is paying off.

If you're planning a new app rather than updating an existing one, the advantage is that you can build these actions in from the start. It's much easier to design a product around clearly defined tasks from day one than to retrofit them later.

We've been building apps since 2009, and if there's one thing that experience has taught us, it's that the way people use their phones changes faster than most product roadmaps do. Voice assistants, widgets, wearables and now AI assistants have each asked app owners to rethink where their product shows up and how people reach it. The apps that cope best are the ones built around a clear understanding of what people are actually trying to get done.

That's why, when we work with a partner on a new app or a significant update, we spend a lot of time early on understanding the real tasks people come to the app for, the language they use to describe them and the moments where they need to be in control. That understanding has always shaped how we design screens and journeys. Increasingly, it also shapes which actions we expose to Siri, Gemini and other assistants, and how we describe them.

If we were sitting across the table from you today, our advice would be fairly simple. Don't treat AI assistants as a separate channel to bolt on later. Treat them as another way people will reach the most important parts of your app, and make sure those parts are described clearly enough that an assistant can find them, understand them and use them well.

Not any time soon. People still need to find, install and trust an app before Siri or Gemini can use it, and stores remain the main place that happens. What's changing is how often people open an app once it's installed, and how they first come across one, which is why it's worth thinking about both.

App Intents is Apple's framework for describing what your app can do so that Siri, Spotlight, Shortcuts and widgets can use those actions. With SiriKit being phased out, it's the route Siri uses to work with third-party apps, so if you want your app to be useful to the new Siri, it's well worth adopting for your key tasks.

Google offers two routes. AppFunctions lets your app describe specific functions that Gemini can find and run, and a separate UI automation framework lets Gemini carry out tasks in some apps on the user's behalf, starting with selected food delivery, grocery and rideshare apps.

Usually not. In most cases it's about adding well-designed actions on top of the features you already have, then testing how they behave when an assistant calls them. The bigger work tends to be deciding which tasks to expose and how to describe them.

You'll need to plan for it in your analytics. Track when actions are triggered from outside the app, how often they complete without a person stepping in, and how often someone chooses to carry on in the app itself.

The way people find and use apps is moving from what they search for to what they want done. Search and the app stores aren't going anywhere, but alongside them, a growing share of decisions about which app gets used will be made by an assistant acting on someone's behalf, and the apps that describe their capabilities clearly are the ones those assistants will reach for.

If you’d like to know how ready your app is for Siri, Gemini and the assistants that follow, we’d be happy to look through it with you and talk about where to start.