Build Once, Appear in Search and Gemini: Google Opens Its Connected Apps Platform Preview

On October 28, Google released something almost invisible to ordinary users but potentially important for developers: a preview of the Connected Apps Platform. In Google's own words, it is a unified platform that lets developers integrate once and bring their service's capabilities into both Search and the Gemini app. Put more bluntly, when users ask a question or try to get something done in the search box or in Gemini, the answer itself may soon include your app's functionality — instead of merely handing them a link and leaving them to find their way on their own.

First, what exactly was announced. The post was jointly signed by Chips Mistry, Group Product Manager for Search, and Mai Lowe, Group Product Manager for the Gemini app, and is dated October 28, 2026. The platform itself is currently in preview, not generally available. Developers have two integration routes: a cloud-hosted MCP server — MCP being the open standard much of the industry has now adopted — or Android MCP using the AppFunctions APIs, which lets an Android app expose its functions to Gemini and run them on-device. Once integrated, developers use the Google Connected Console to register, test, and submit their app, and before review they choose whether it goes live in Search, the Gemini app, or both. After launch, they can track traffic, latency, and error rates, while keeping control of their brand identity, including verified logos and authenticated accounts.

The 50-plus apps already live, and the names mentioned this time

The same announcement states the existing scale: more than 50 Connected Apps have already launched between Search and Gemini, spanning productivity, event ticketing, health and fitness, and more. The newly named partners include Adobe, Experian, Localiza, and Peloton, whose integrations are live for users in Gemini, with Google saying they will come to Search in the coming weeks. One name needs to be read carefully: Calm. The announcement's wording for Calm is that Google will "also be launching" a new integration across both Search and Gemini — that is, not yet live at announcement time. Reading "coming soon" as "already live" is the most common way to misread announcements like this one.

The figure of 50-plus itself deserves a second look. The announcement counts Search and Gemini together, and does not say whether an app available in both products is counted once or twice, nor does it publish a full list — it points readers to the help center pages for Search and Gemini. That means the complete picture cannot be reconstructed from this post alone. The number is Google's own, and it is best understood as "a real, existing footprint, but far from a fully open market": large enough to show this is not an experiment starting from zero, but far from something every developer can use immediately.

Why "integrate once, appear in two places" matters

For developers, the weightiest part of this release is not any single new feature, but a change in where distribution happens. Traditionally, for users to use an app, they had to download it, install it, register, and open it — with attrition at every step. Connected Apps inverts that logic: the user starts with a concrete problem — booking a room, checking an itinerary, handling a document — and Google embeds a capable app directly into the answer. For users, the path changes from "find the app, then get the job done" to "get the job done where you asked the question." For developers, the competitive prize changes from "whose app has the most installs" to "whose functionality best answers the user's immediate question."

This is especially worth noting for small teams and independent developers. Distribution rules on large platforms usually favor incumbents, which have brands, budgets, and negotiating power. But under a "match functionality to the question" model, a small app whose feature is precise and deep enough theoretically has a chance to be picked for a specific class of question, without first climbing an app-store chart. That is only a theoretical opportunity so far — how much traffic actually flows depends on Google's matching and ranking rules, which were not disclosed this time, as discussed below. But directionally, the platform shortens the distance between "building a good feature" and "being encountered when the user needs it," and that is a genuine benefit for developers with limited resources.

There is a second layer of significance in the technology choice. By placing a cloud-hosted MCP server alongside the native Android route, Google is publicly betting that MCP will become the common language for app capabilities entering AI surfaces. For teams already using MCP, this is a tailwind: the same server-side capability may soon serve multiple surfaces. For teams that have not touched MCP yet, it is a clear signal to read the documentation and understand its boundaries now, rather than scrambling when every surface demands it. Windows of opportunity around technical standards usually open exactly like this: when a large platform starts using a standard to build distribution channels, learning costs are lowest and leverage is highest.

The four things the announcement does not say are precisely the four that matter most

This announcement is short — short enough to read word for word. And because it is short, its omissions stand out. First, fees and revenue share. The post says nothing about whether integration costs developers anything, whether the platform takes a cut, or how money is split when users complete transactions through Connected Apps. For a developer hoping to make a living from this, that is not a detail; it is the business model itself. Second, admission and ranking rules. Google does not explain which apps get into the preview, what the review criteria are, or, when several apps could answer the same question, who appears first and on what basis. Without those rules, developers cannot judge whether their development investment will translate into stable exposure.

Third, market and language coverage. The announcement only says that "more developers, markets, and Google products" will be added over the coming months, without listing which countries and regions are in the first phase or which languages are supported. Developers serving a global audience cannot assume their target markets are covered; developers serving a specific region need to confirm they are in the first batch before setting their pace of investment. Fourth, the preview's end criteria. The post gives no preview duration, no graduation criteria, and no word on whether policies may change during the preview. A platform in preview can adjust its rules, entry placement, and presentation at any time, and building a core business entirely on an entrance whose rules may still move is a risk that needs to be priced seriously.

One more unaddressed question: user data. When an app's capability is embedded in a Search or Gemini answer, how much of a user's question or action flows to the third-party app? The announcement mentions brand controls and authenticated accounts, but does not spell out data-flow boundaries. For developers handling sensitive areas such as health, finance, or travel, that is not a question to be answered after the fact; it must be answered from Google's documentation and policies before integrating. If the documentation does not answer it either, then the honest conclusion is that this direction is not yet suitable for sensitive scenarios — at least not as the only channel.

Platform opportunity and platform risk are always two sides of the same coin

Every "integrate once, distribute everywhere" platform story has the same shape: early benefits are real, and later tightening of the rules is almost inevitable. The early advantages are less competition, good placement, and a platform willing to promote flagship cases; the later norm is stricter review, ranking that tilts toward incumbents, and policy changes whose costs fall on developers. Connected Apps is clearly in its early phase: preview, phased access, 50-plus apps. The best use of this phase is to validate, at low cost, whether your functionality is genuinely needed in a question-answering context — not to immediately bet your entire user-acquisition strategy on it.

A more specific risk is dependence on the entrance itself. Once user habits shift from "open your app" to "ask Google and use your feature in passing," a layer of platform sits between you and your users. One adjustment to display rules, one ranking-algorithm change, one tightening of review, and your traffic can move with it, with almost no negotiating power on your side. That is not an argument against integrating; it is an argument for keeping your own direct channels at the same time — your own website, your own app, your own way of reaching users. Treating Connected Apps as an additional acquisition channel rather than the only one is the simplest hedge against this risk.

Brand control deserves to be singled out as well. The announcement specifically notes that after launch, developers keep control of their brand identity, including verified logos and authenticated accounts. That detail shows Google is aware of developers' concern: providing a service inside someone else's interface, the worst outcome is to be stripped of your name and reduced to an undifferentiated backend capability. For smaller developers, brand visibility is not vanity; it determines whether users can find you again next time. Before investing heavily, confirm what your brand elements actually look like in each of the two surfaces, and then decide how much to commit.

What you can do now

The first step is to read the documentation, not to write code first. The developers.google.com/connected-apps page linked in the announcement is the starting point, and the key questions are about fit: is your service better suited to cloud MCP or to Android AppFunctions? Is your functionality best as a single call, or does it need multi-turn interaction? Are your users' scenarios more common in Search, or in Gemini conversations? Making these judgments up front is far cheaper than reworking after integration.

The second step is to decide which single user question you answer. The unit of competition in Connected Apps is not the app, but the functionality. Your app may have ten features, but perhaps only one truly belongs inside a question-answering flow: the one users would naturally think of when asking, the most specific one, the one completable in a single step. Polishing that one feature until it is reliable, fast, and clear is worth more than wiring in all ten. Preview-stage review and ranking will most likely reward features with clear scenarios and high completion quality, not the longest feature lists.

The third step is to pace your investment to the phased rollout. The preview opens in batches; not being in the first batch is neither a rejection nor a reason to wait indefinitely. Useful work in the waiting window includes building and testing your MCP server, preparing brand assets and account-verification materials, writing up your data-flow compliance notes, and validating in your own channels whether users genuinely need this feature at all. None of that work is wasted by queuing, because it pays off whichever entrance you eventually use.

Seen in the bigger picture of late October

Note the timing: the Connected Apps preview and the Gemini 4 Carbon announcement landed on the same day, October 28. On one side, the strongest model goes to defenders first, in phases; on the other, third-party app capabilities are embedded into Search and Gemini, also in phases. The rhythm is identical: start with a few, gather feedback, expand. This tells us Google was advancing two tracks at once in late October — the model-capability track and the distribution-entrance track. For developers, that means the variables to watch in the coming months are not only in the models themselves, but also in which third-party capabilities the models are willing to bring into their answers. Those who watch only model parameter changes may miss the opportunities created by distribution-rule changes.

For vibe coding developers, there is a more direct implication. In the past, for a vibe project to reach users, it usually had to solve a whole stack of problems: deployment, launch, promotion, retention. Connected Apps points to a lighter possibility: a small tool with a single, well-executed function could appear directly where users ask questions. That is only a possibility, not a promise. Preview thresholds, review, and ranking are not yet fully public, and any claim that "integration guarantees traffic" would be an overstatement. But the direction itself deserves to be taken seriously: when AI surfaces become the first stop for getting things done, "building a small tool that can be asked for" may become a second path alongside "building an app." For independent developers with limited resources, one more path is itself good news.

Finally, a judgment. The Connected Apps Platform preview is not a sensational release: no new model, no startling benchmark score, no timetable for opening to everyone. But it may be the short announcement from late October most worth a developer's careful reading, because it is not about what technology can do, but about where users will encounter your product in the future. Changes in entrances always arrive more slowly than changes in models, but once a habit forms, it is hard to reverse. Spending an afternoon now reading the documentation and deciding which user question your functionality answers costs very little; entering after the rules have hardened and the positions have been taken will only cost more. The greatest value of a preview phase was never immediate traffic — it is understanding the rules early.

Different advice for two kinds of developers

Teams with mature products should treat Connected Apps as a channel experiment, not a product rebuild. Pick the single feature best suited to a question-answering context, run it as a pilot, and measure separately what incremental usage and incremental users it brings before deciding whether to expand. The metrics most worth recording during the pilot are not impressions, but completion rates: after users invoke your feature inside an answer, how many actually finish the task, how many abandon it midway, and how many later come back to you directly. Those numbers will tell you whether this entrance is genuinely incremental for your product, or merely relocating visits that would have happened anyway.

Independent developers starting from zero can invert the order. Do not first build a full-featured app and then apply for access; first find a problem specific enough to describe in one sentence, build the smallest feature that solves it well, and only then ask whether it belongs inside Search and Gemini answers. This "problem-first" approach has a side benefit: even if you never get into the preview, or the ranking rules do not favor you, the small tool itself remains a standalone, directly distributable product that does not go to zero because of the platform's pace. A platform can amplify a good feature, but it should never be the only reason a feature exists.

One more pitfall deserves its own warning: do not treat Connected Apps as a continuation of search optimization or app-store optimization. The old optimization logic competed over rankings and keywords; the new matching logic understands the user's question and judges which functionality best answers it. Stuffing keywords, exaggerating descriptions, or claiming irrelevant scenarios will most likely backfire in this model: one mismatched answer costs not just one impression, but users' trust in the entrance itself. Platforms' tolerance for such behavior typically tightens as scale grows, and positions gained early through shortcuts are often the first to be cleaned up. Writing functionality descriptions that are accurate, restrained, and verifiable is the most cost-effective long-term strategy in this new entrance.

Finally, back to the ordinary user's side. The change in user experience will not happen overnight: the preview is phased, partners arrive gradually, and Search-side coverage will take the coming weeks. But the direction is set: Search and conversational assistants are moving from "giving you a pile of links" toward "helping you get part of the job done directly." For users, that means judging an answer will no longer be only about whether it is correct, but also about whether it can conveniently finish the task. For developers, it means the measure of product value is also changing: no longer just how many features you have, but whether your functionality happens to appear in front of users at the exact moment they need it. That is the real significance of the Connected Apps preview: it turns the answer to that question from "we'll see later" into "you can start preparing now."