Topics

The next Apple SEO is not a keyword trick

If Siri AI, Spotlight, Shortcuts, and on-screen context can discover app capabilities, optimization moves away from visibility theater and toward product grammar.

Language: en

SEO is an ugly word for a useful problem

I do not love calling this SEO, because the word brings a bad smell into the room before the argument has even started. It makes people think of keyword stuffing, metadata tricks, fake relevance, inflated category names, and the old habit of treating discovery as a ranking game rather than a trust problem. If a developer hears "App Intents SEO" and immediately asks how to appear for more phrases, the conversation is already leaning in the wrong direction. The useful comparison is narrower and more serious: every new discovery layer forces a product to explain itself in a format another system can understand. The danger is that teams import the old incentives without importing the old guardrails. A page can overpromise and still leave the user in control. An action schema can overpromise and invite the system to do something.

Web SEO was partly about making documents legible to search engines. App Store optimization was partly about making a listing legible to people browsing a store. App Intents optimization is different because the object being described is no longer only a page or a listing. It is a capability. It is the product saying, in a machine-readable and user-respecting way, these are the things I can do, these are the objects I can act on, these are the conditions under which the action is safe, and these are the moments where I should stop. That makes the work closer to product grammar than growth copy. The grammar has to include nouns, verbs, permissions, confirmation, refusal, result display, and recovery. Leave any one of those out and the system may still discover the capability, but the user may not be able to trust it.

The difference matters because an operating system does not merely read. It can suggest, invoke, route, confirm, and sometimes complete work across apps. A badly described web page may rank for the wrong query. A badly described intent may attach to the wrong customer, send the wrong file, expose the wrong note, or encourage a risky action before a person has noticed the ambiguity. So the goal is not to fool Siri AI into calling the app more often. The goal is to make the real structure of the product clear enough that being called by the system does not create a trust accident. That is why I would rather use the uncomfortable word SEO and then immediately discipline it. The useful part is legibility. The dangerous part is the temptation to make the product look more capable than it is. The honest version asks the product to become easier to understand, not easier to hype. It rewards teams that can say no, show uncertainty, and attach actions only to entities the system can identify with enough confidence.

Discovery starts to move into the operating system

A user may not begin by searching the App Store at all. They may ask Siri AI to do something while they are already inside another app. They may search in Spotlight because they remember the invoice but not the app. They may select text in Mail, look at a visible object on screen, create a Shortcut, or refer to a view conversationally: "send this to the client," "add that booking to the trip," "summarize the last update," "make a reminder from this." In that world, the app can matter deeply without being the first branded destination the user consciously chose. The user is not thinking about distribution. They are thinking about getting work done from the point where the need appears. That makes the system entry feel natural and makes the app boundary easier to miss.

Apple’s developer material points in this direction. App Intents connect app content and capabilities to Apple Intelligence and Siri AI. Entity schemas can make app content discoverable and contribute to Spotlight’s semantic index. Intent schemas let people act through natural language without memorizing fixed phrases. View Annotations connect what the user can see to the underlying entity the system can reason about. None of this is just a better search box. It is an attempt to let the operating system understand the objects and actions that live inside products. The more the system understands, the more important it becomes that the app speaks precisely. Loose language can move from harmless description into unsafe invocation.

That turns the old growth question into something too small. "How do we get seen?" still matters, but it is not the central question. The stronger question is operational: can the system understand which object is in scope, which action is being requested, whether the user has permission, whether the action changes state, whether the result should be shown, and whether the app should refuse or ask for confirmation? A product that cannot answer those questions may still have a beautiful interface, but it is not ready to be called from the outside. It may be optimized for a user who enters through the front door and reads the labels in order. System discovery creates side doors. Side doors need locks, signs, logs, and clear limits, not louder advertising.

Entities are what the system can point at

On the web, companies eventually learned to structure pages, titles, links, canonical URLs, and schema data. In this layer, apps have to structure entities. A project, customer, order, workout, recipe, lesson, invoice, source, note, file, playlist, claim, or booking is not only a thing inside a private UI. It may become something the user can refer to from outside the app, sometimes with messy language and sometimes while the system is looking at a different surface. The user does not think in database tables. They say "the Berlin client," "the invoice from last week," "that source I saved," or "the trip I was planning." If the app cannot translate those phrases into a stable object without guessing too aggressively, the system will either fail too often or act with false confidence.

This is where many teams will discover whether their product is actually coherent. If nobody agrees what counts as a client, whether an archived task is still searchable, whether a deleted file can be referenced, which account owns a shared document, or which fields define a source, the operating system will not clean up that confusion by magic. It will inherit it. Worse, it may expose the confusion at the exact moment the user expects the product to feel effortless. Ambiguous nouns are not a documentation problem anymore; they are a runtime behavior problem. They also become a business problem, because a user who sees one wrong suggestion may stop believing the product belongs in system-level workflows at all.

That is why this work is not only for developers. Product managers decide the conceptual model. Designers decide what the user can see and name. Data teams decide whether records have stable identifiers. Legal and privacy people decide what can leave the app boundary. Support teams hear where users use the same word for different things. If those groups never agree on the nouns, the schema becomes a thin wrapper around disagreement. Bad nouns become bad suggestions. Bad suggestions become mistrust, especially when the system sounds confident. The practical work can be boring: decide whether archived objects are callable, whether duplicate names require disambiguation, whether personal and team records share language, and whether deleted things can still appear in search. Boring decisions become trust decisions once the system can point at them.

Actions are where trust can break

Links on the web mostly moved a person from one document to another. Actions in an intent layer can change state. Create the invoice. Archive the file. Send the message. Approve the request. Pay the bill. Share the album. Schedule the meeting. Change the delivery address. Mark the medical note as reviewed. Invite the new teammate. These are not just navigational conveniences. They are operational verbs, and operational verbs carry responsibility. That responsibility should shape the schema, not sit outside it. A read-only action, a draft action, a send action, and a payment action should not be exposed with the same confidence, the same confirmation level, or the same recovery expectation.

That is why appearing more often is not automatically good. A bad search result wastes time and maybe sends a person to the wrong page. A bad action can expose data, charge an account, notify the wrong person, overwrite a field, leak a private file, or change a workflow in a way the user cannot easily reverse. The more natural the invocation feels, the easier it is for a person to miss the exact moment where the product crosses from suggestion into action. Smoothness becomes dangerous when it hides consequence. The right optimization may be to appear less often but with higher confidence, clearer confirmation, and stronger recovery. That is a very different instinct from normal growth work.

A serious product needs negative space. It should know when to say no: no because the account is ambiguous, no because the user lacks permission, no because the object is sensitive, no because the request conflicts with policy, no because the action needs review, no because the evidence is incomplete, no because two entities have similar names, no because the undo path is weak. Refusal should not feel like a crash. It should feel like the product protecting the user from a mistake. In agentic interfaces, refusal is not a defensive disclaimer. It is a core part of quality. The best refusal also teaches the boundary: "I found two Anna accounts," "this file is marked sensitive," "you can draft this message but not send it from here," "this payment needs review." That language is product design, not error handling.

Attribution is the business problem hiding inside the UX

If Siri AI completes a task using an app action, who gets the credit? The user may remember Apple because Apple interpreted the request, showed the suggestion, and carried the interaction. The app may have done the valuable work, but the value may feel like part of the system. If the app insists on appearing at every step, the system experience becomes noisy. If the app disappears completely, the business loses memory, brand, habit, and maybe even the paid moment. There is no clean universal answer, but treating this as a small label placement issue is naive. Attribution has to be designed around consequence. Lightweight value can stay quiet. High-value, high-risk, paid, collaborative, or review-heavy work needs a return path where the user can see what the app contributed.

The best pattern may be selective return. Let the system handle lightweight steps that do not need the full product surface: finding a record, creating a simple reminder, extracting a small fact, or preparing a draft. Bring the user back to the product when the work requires review, complex editing, paid value, team collaboration, source inspection, version history, audit trail, or expert explanation. The app should not fight every system entry. It should decide which moments deserve the full surface because that surface actually helps the user understand and control the work. That decision should be made per action, not at the brand level. A product can be quiet for one verb and assertive for another.

The risk here is real and it is not solved by saying "build for trust." Any optimization layer can become a game. Developers may over-declare actions, exaggerate what an entity represents, give ordinary objects promotional names, or turn schemas into another marketing surface. That would turn App Intents discovery into something worse than old SEO, because the inflated description would be attached to permissions and actions. The discipline that keeps the system honest has to be empirical: messy user phrases must resolve to the correct entity, risky actions must require confirmation, results must be visible, undo must exist where state changes, and refusal must be understandable instead of hidden behind generic failure. This is the point where optimization and safety become the same work. A team that measures only invocation volume will reward exaggeration. A team that measures correct resolution, recoverable failure, and user comprehension has a chance to reward honesty. The better question is not how many times the app was called, but how often the user would trust the same path again after seeing the result.

The product grammar has to survive messy language

Before writing growth copy, I would build an intent evaluation set. It should not be made only from the phrases the product team wishes users would say. It should include the strange, short, incomplete, and overloaded phrases people actually use: "send this to Anna," "archive the old one," "make the client version," "use the last quote," "add it to the trip," "show me the paid invoices," "share the safe copy." Each phrase should be tested against entity resolution, action selection, permission, confirmation, refusal, and result visibility. The point is to learn whether the product grammar survives real language. That test set should become a product artifact, not a one-time QA exercise. Every new entity, action, permission change, or account model change should force the team to ask what breaks in messy language.

Then I would test failure on purpose. Two customers with nearly identical names. A shared workspace where the user has read access but not write access. A sensitive file that should never be sent from a system suggestion. A personal account and a work account both containing a similar project. A stale record that looks current in the phrase but is not current in the data. A request that sounds convenient but should be rejected because the action is irreversible. If these tests fail, the product does not have an App Intents marketing problem. It has a product grammar problem.

I would also measure what happens after invocation, because success cannot mean only that the system called the action. Was the action corrected? Did the user abandon it? Did they return to the app for the richer workflow? Did they understand which product helped them? Did support tickets increase around ambiguous actions? Did users trust the shortcut more after seeing the result, or less after one strange suggestion? Without that loop, optimization becomes ritual. With it, the intent layer becomes product learning, because the team can see where language, entity model, permission design, and attribution are breaking down. The uncomfortable failures are the most useful ones: the similar customer name, the stale document, the wrong account, the missing permission, the action that should have stayed a draft.

The strategy conversation should be concrete enough to fit on a table. Name the five core entity types the product cannot function without. Name the ten actions that create the most user value. Name the three actions that could hurt the user most if invoked wrong. For every action, write the attribution moment: when the user should understand that this product helped, when they should be brought back, and when the system should stay light. After that, decide what belongs in Spotlight, what belongs in Siri AI, what belongs in Shortcuts, what belongs only in the app, and what should never be exposed outside the app boundary. This is not a growth inventory. It is a control inventory. It forces the team to see capability, risk, and credit together instead of treating discovery, safety, and business value as separate conversations. The same table should include the refusal rule and recovery path for each risky action. Otherwise the product will have a list of things it wants the system to call, but not a list of conditions that keep the user safe when the call is wrong.