The surface you design for is no longer only your own app. It is also the inside of someone else's assistant, with your logo, your data and your actions rendered on Google's terms.
What the Google Connected Apps Platform changes for designers
The Google Connected Apps Platform, announced in preview on 28 October 2026, gives any developer one path to put an app's capabilities inside the Gemini app and Google Search. For designers, that means a product you shipped as a screen can now be used as a conversation: a user types the app's name in Gemini, links their account once, and asks it to do something. The response comes back as text or as a branded interactive card your team designs.
The short answer to "what does this change for designers" is this: the surface you design for is no longer only your own app. It is also the inside of someone else's assistant, with your logo, your data and your actions rendered on Google's terms. According to Google's announcement, Adobe, Experian, Localiza and Peloton are already live in Gemini, Calm is launching across both Search and Gemini, and more than 50 Connected Apps exist between the two products. Access is opening in phases, so this is a preview, not a general launch.
What Google actually shipped on 28 October 2026
Strip the press language and there are four concrete pieces, all described in the Connected Apps developer documentation:
A cloud MCP server path. You host a remote server built on the Model Context Protocol, the same open standard that Claude, ChatGPT and Cursor use for tools. Google reads your tool schemas, descriptions and annotations to decide when to call your app.
An Android MCP path. Android apps expose functions through the Jetpack AppFunctions SDK so Gemini can run them on the device. This is the same mechanism covered in the earlier piece on apps without screens, now with a registration and review route attached.
The Google Connected Console. A self-service place to register tools, configure OAuth, pick whether the app goes live in Search, Gemini or both, submit for review, and then watch traffic, latency and error rates.
MCP Apps for interactive UI. A tool result can bind to a UI resource, and Google's docs say it then renders as a branded, interactive widget inside a sandboxed iframe in the conversation. The documentation describes this for Gemini and is silent on whether Search renders the same widgets.
There is also a Developer Mode in the Gemini web app, reachable from settings, where you connect an unpublished HTTPS endpoint, run simulated chats, inspect the JSON payloads and check how confirmation cards appear for read-only and destructive tools.
Hype vs reality: is this the end of the app?
The hype version writes itself: every product becomes a line in a chat, screens stop mattering, and whoever designs the best card wins. The reality is narrower and more interesting.
What holds up: the distribution argument is real. Gemini and Search are surfaces with enormous reach, and a user who never installs your app can still link it and use it. The MCP standard also means the work is portable. A server you build for Google is close to what the Framer, Webflow and Figma teams already ship for other assistants, and the earlier guide to the Webflow connector in Gemini shows the user side of exactly this pattern.
What does not hold up: nobody has shown that a conversational wrapper beats a good screen for the tasks people do most. A chat is a poor place to compare twenty flights or tune a color palette. Google's own model decides when to route to your app, so your "homepage" inside Gemini is a routing decision you influence through tool descriptions, not a layout you control. And the preview is gated. If your product is not in the first phases, you can prepare but not ship.
Verdict: treat Connected Apps as a new channel to design for, like a share sheet or a watch complication, not as a replacement for the product. The teams that benefit first are the ones whose core job can be stated in one sentence: book, check, log, pay, generate.
Old approach vs Connected App: what the design brief looks like
Design question | Native app or web app | Connected App in Gemini or Search |
|---|---|---|
Entry point | Icon, URL, search result | Mentioning the app name, or Google's model routing a request to it |
First-run experience | Onboarding flow you design end to end | One account link via OAuth, then straight to a task |
Primary unit of UI | Screen with navigation | A tool call with a text answer or one interactive card |
Who controls layout | Your team | Your team inside the card, Google outside it |
Error and empty states | Dedicated screens | Must be written into tool responses so the model can explain them |
Dangerous actions | Confirmation modal | Tool annotation marked destructive, plus Google's confirmation card |
Analytics | Your own events | Console metrics: traffic, latency, error rates |
Discoverability | App store, SEO | Google's routing quality plus your tool descriptions |
The table makes one thing obvious: half of the designer's craft moves into text. Tool names, parameter descriptions, allowed values and error messages are the interface now. Google's docs ask for typed schemas, parameter docstrings and explicit read-only and destructive annotations because those are the only hints the model has.
The Intent, Card, Confirm framework
A simple way to brief a Connected App is to design three artifacts and nothing else at first.
Intent. List the five requests a user would plausibly type to Gemini that your app should answer. Write them as sentences, not features. "Log a 30 minute run" beats "activity creation". These sentences become the tool descriptions and server instructions Google's model routes on. Test them in Developer Mode and watch which ones never trigger.
Card. For each intent, decide whether the answer is text or a widget. Text wins when the answer is one fact. A widget wins when the user must pick, compare or edit. Design the widget as a single-purpose component in your design system, not a shrunken screen. It lives in a sandboxed iframe inside a conversation, so it inherits none of your app's navigation and should not try to.
Confirm. Mark every tool that changes state. Decide which ones need Google's confirmation card and what the card must show for a user to say yes without opening your app. This is the same discipline described in the guide to agentic UX: delegation only works when approval is cheap and undo is visible.
A product team building this from scratch usually needs design and engineering in one room, because the schema is the design. That is the case where an AI product development partner who ships both sides tends to save the most time.
Where design work goes over the next three years
Expect three shifts. First, "assistant-ready" becomes a standard line in product requirements, next to "accessible" and "responsive". Second, design systems grow a conversational layer: card components, confirmation patterns and tone guidelines for tool responses, maintained by the same people who own buttons today. Third, the design engineer role gets stronger, since the artifact being designed is partly a schema and partly HTML in an iframe.
The role after this looks less like a screen painter and more like someone who decides which of a product's jobs deserve a screen, which deserve a card, and which should just happen silently when an assistant asks.
Frequently asked questions
Will the Google Connected Apps Platform replace UI designers?
No. It adds a surface, it does not remove one. Someone still has to decide what the card shows, what the confirmation says, how errors read in plain language and which requests the app should refuse. Those are design decisions, and they are harder to get right in a conversation than on a screen because there is no layout to lean on. The designers at risk are the ones who only produce pixel-perfect screens and never write the words.
Is the Google Connected Apps Platform overhyped?
Partly. The reach is real and the MCP standard makes the work reusable across assistants. But it is a gated preview, Google's model controls routing, and the interactive widgets are documented for Gemini rather than Search. Treat it as a channel to prepare for this quarter, not a platform to bet the roadmap on.
How does a designer try the Google Connected Apps Platform this week?
Three steps that cost nothing. Read the developer docs and list your product's top five intents as sentences. Ask an engineer to stand up a minimal MCP server with one read-only tool and connect it in Gemini Apps Developer Mode to see how a tool response renders. Then sketch one card as a design system component. Applying for the preview happens through the Connected Console form linked from the docs.
What should a Moroccan or African startup do with this?
Prepare the intents and the card now, and keep the native app as the primary product. Assistant surfaces reward products with one clear job and clean data, which many fintech, mobility and health startups already have. A studio that handles mobile app development alongside product design can expose the same actions to Gemini and to Android AppFunctions without rebuilding the product.
What to do before the preview reaches you
Write the five intents. Audit which actions in your product are destructive and give each a one-line confirmation. Add a "card" component family to your design system and test it at the width of a chat column. Those three tasks are useful even if Google never approves your app, because the same artifacts feed ChatGPT connectors, Claude integrations and your own in-product assistant.
If you want help shaping a product for assistant surfaces, DIGCY is a Dribbble Selected Agency and a UI/UX agency in Casablanca working with clients globally, with 50+ projects delivered and ZeroDrift, an Awwwards Honorable Mention. Start with a conversation about which of your product's jobs should become a card first, through the contact page.
Let’s keep in touch.
Discover more about high-performance web design. Follow us on Twitter and Instagram.
