Our customers had already told us what Siri should say

Thousands of apps run on our engine: a radio station, a sports club, a local paper, a pastry shop, each one different. A feature is written once, in the engine, and an app gets it at its next submission to the store, if its owner wants it.

That's the point of a platform, and it's the design constraint behind everything that follows: whatever we build has to make sense in apps we will never look at one by one.

What an assistant can do in an app

What an assistant can do in an app, we define the way we define a feature: once, in the engine, for every app that has the feature. Apple calls these things intents: an intent is what someone means to do in an app, put in a form an assistant can act on.

Exposing an app to an assistant means going through what the app can do and deciding, for each thing, whether an assistant can reach it, under what name, and with what answer. A developer who does this for their own app knows its content, its sections and its users, and decides for that one app.

Writing an intent is quick work now. The time goes into knowing what it should cover, for all of our apps at once, including apps that don't exist yet, without opening any of them.

Work we can't ask our customers to do

The obvious way out is to ask the owner, the customer who built the app. A form with a few questions: which sections may Siri answer from, what should it call them, what counts as news in your app. We decided against it, for reasons that hold for every intent we will ever add.

An owner builds an app to publish their content or run their organisation, not to set up an assistant. The assistant is our idea; the work it creates is ours.

The apps are already in the stores. An intent that depends on a form is empty in every app until its owner fills it in. Whatever we ship has to work in each app as it is, the day it gets the update.

And we would have to write the questions in advance, the same ones for the radio and the pastry shop, without knowing which matter where. We would be asking each owner to describe their app to us. They already have, once, by building it.

That's the premise we work from: deciding what an assistant can do in an app is our work, and the owner should never have to do it a second time.

A form could have been optional, defaults read from the structure and a setting on top; we didn't build that either. A second place where the app is described drifts from the first, and someone has to keep them in step.

Whether their app gets the update is their call, as with any store submission; what it answers once it has it is what this piece is about.

The structure is already a description

An app takes shape in our builder one choice at a time: dozens of choices, and its owner makes none of them at random.

• Which sections they add, and of which kind: a radio has a live stream and podcasts, a club has a calendar and a members' area, a shop has a catalogue and a loyalty card.
• Which sections go on the home screen, which stay in the menu, and in what order.
• How many items each widget on the home screen shows.
• The titles they give their sections and widgets.
• Which sections only members can open.

Across our paying customers' live iOS apps, the median app has 16 sections and the median home screen 6 widgets.

None of it was meant for an assistant, because it was made to give visual cues, not semantic ones. However, each choice is a weak signal about what counts in that app and what people come to it for, and together they are a description of the app that nobody wrote as one.

A radio that puts its live stream at the top of its home screen has said what people come for. A club whose only section open to everyone is its calendar has said who the rest of the app is for. The intents are in there. Our work is to read them out.

What we read today, and what each reading gives the assistant:

• What the owner chose: Which sections exist, and of which kind
  • What it tells us: What the app does: publish, stream, sell, gather members
  • What the assistant does with it: Only what exists is reachable; nothing is invented
• What the owner chose: Which sections sit on the home screen
  • What it tells us: What people come to the app for
  • What the assistant does with it: Where "what's new" and "what's on" read from
• What the owner chose: How many items each widget shows
  • What it tells us: How much room the owner gives each one
  • What the assistant does with it: How many items each one puts forward; the answer keeps the newest five
• What the owner chose: The order of the menu
  • What it tells us: The owner's hierarchy
  • What the assistant does with it: The order of the sections Siri offers when it has to ask
• What the owner chose: The titles of sections and widgets
  • What it tells us: The owner's vocabulary
  • What the assistant does with it: The words Siri uses
• What the owner chose: Which sections only members can open, and what subscribers pay for
  • What it tells us: Who the app is for
  • What the assistant does with it: What is listed as in the app, and what carries a lock

We don't have a method that covers everything an app does, not yet. The questions below are what we have, and for each of them we read the structure instead of asking.

What Siri answers, and where it reads

We started in September 2026 with Siri and with content: what's new on an app, then, in October, the latest article and the latest video in one of its sections. Three questions about events were announced in November and reach apps with their next store update: what's on today, what's coming up, what's on this weekend.

They read three places in an app: the content widgets on the home screen, the menu, and the Events widgets on the home screen. The owner's side is on our blog.

You can hear it yourself: install GoodBarber News, our own app, and ask Siri "What's new on GB News?"; GB News is the name under its icon, and the one Siri listens for. On a phone with Siri AI, Apple's new Siri, variations like "GoodBarber News" are understood just as well.

• The question: What's new
  • Where it reads: The content widgets on the home screen
  • The owner's choices it follows: Which widgets are there, how many items each shows, what they're called
• The question: The latest article, the latest video
  • Where it reads: The menu
  • The owner's choices it follows: Which sections exist, in what order, under what names
• The question: What's on today, coming up, this weekend
  • Where it reads: The Events widgets on the home screen
  • The owner's choices it follows: Which events are shown, and how many

"What's new" could have been a list of everything the app has published, newest first. That design needs to know nothing about an app. It treats every app as a pile of dated items, but no owner builds an app that way.

Instead, the action reads the home screen. It takes the content widgets the owner put there, articles, videos, photos, podcasts, as many items as each one shows, drops what appears twice, and puts the newest first. Siri gives each item's title and the name the owner gave the widget it came from, or its section's name when the widget has none. The date orders what the owner already chose and keeps the newest five: what gets in was the owner's choice.

We measured the gap between the two designs. In November we replayed both on 248 of our customers' live iOS apps, the ones whose home screen we can rebuild exactly from our own data. In 197 of them, four out of five, the five items read from the home screen are not the app's five most recent. In 72, the most recent dated item in the whole app is an event that hasn't happened yet.

Some signals are in what the content is, not where it sits. An event has a date too, but it means "when it happens", not "when it was published". Sorted with the rest, next June's festival would come out as the latest news. So events stay out of "what's new", and map points with them: a place isn't news either.

That exclusion is a rule of ours, made once for every app, and I'd rather say so. The structure doesn't speak by itself; someone has to read it. The order is our rule too. On the home screen, the owner's order says what counts; the question asks what is recent, so the date orders the answer.

"The latest article" and "the latest video" read the menu, and there we keep the owner's order. If the app has several video sections, Siri asks which one and lists them in that order, under the names the owner gave them; a section split into categories is read by its first category, and a live stream doesn't count as a video.

Apps gate content in two ways, and Siri mirrors both. A section only signed-in members can open is listed as the menu lists it, and opening anything from it takes the login, as in the app; a home screen behind a login gives a signed-out visitor nothing. An item subscribers pay for is named like the rest, with a lock before its title on the card Siri shows, and opening it still takes the subscription.

The event questions read the home screen too, from the Events widgets the owner put there: as many events as each one shows, and none that is already over. The scope comes from the structure again, and the date does a different job, because an event's date says when it happens. Events on right now come first, ending soonest first, then what starts later; what's coming up stops at five.

Where the structure says nothing, the rule is ours: the weekend starts at six in the evening before it, Friday or Thursday depending on which days the phone's region calls the weekend, and an event with no end time is never called "on now", because nobody told us it still is.

One rule we didn't anticipate before testing on a real device: the first version was one question with a blank for the timeframe (today, this week or this weekend). In October, on an iPhone running iOS 27, Siri left "today" out of the blank and answered as if no timeframe had been named; then "this weekend" came back as "this week", and the card looked fine.

A section name comes from the owner's menu, so a word that isn't on it makes Siri ask; "this week" and "this weekend" were both valid and sound alike, so Siri heard one for the other, and the answer, for the wrong week, sounded right. Each timeframe became its own question with fixed phrases, "this week" was dropped rather than shipped wrong, and fixed phrases got the right timeframe every time after that.

Our iOS team's write-up (kudos to them for the implementation!) has the whole run; what this piece adds is the decision not to ask the owner about any of it.

When there is nothing to say, because nothing new is on the home screen, or no content widget at all, the answer is one sentence, and Siri stops there: "There's nothing new right now." An empty weekend names the next event there is instead.

The same action gives a different answer in every app. The content is the owners', written years ago in some cases, without knowing it; the order, the cut and the sentence around it are ours.

Where the reading falls short

The reading takes the owner's screen as it is, and that is its weak side too. A widget with no title is named after its section. A home screen whose widgets are a player, a map, a form and a calendar gives "what's new" nothing to say, because events aren't news, and Siri says so; the event questions still read that calendar.

An app whose events live in a section the home screen doesn't show will tell Siri it has no events; an Events widget on the home page fixes that, and it's the owner's screen, not a setting. A widget titled "Home 1" is read as written. A home screen nobody has rearranged in years still reads fine as long as its sections are fed: the layout is old, the items are not.

And the owner sees none of it in the back office. To hear what Siri says about your app, you ask it, like everyone else; to change the answer, you change the app, the same screen your users see. An owner who rearranges the home screen for a Christmas campaign has changed what Siri says without touching a setting, because there is no second place to maintain; that is the point, and the price.

A name that can't change

One thing no structure can give us is the name underneath an action: the identifier Siri and Shortcuts bind to on the phone. It has to work in every app as it ships, ready to use before any owner makes it their own, and still hold later.

In Apple's framework, the name of the intent becomes the unique identifier of the action; a developer who renames the code later can keep the old identifier with a persistent identifier, so what can never change is not the code's name but what a shipped identifier means.

A developer with one app changes it with one update. Our apps don't rebuild together: each one gets the engine's changes at its owner's next submission, whenever that is, so whatever an identifier means has to stay true in binaries built months apart.

There's a ceiling too: an app can register at most ten App Shortcuts, the actions Siri knows with no setup, so every one we ship takes one of ten slots in every app at once. For events we wrote down 32 questions people might ask, scored them on value, on how reliably Siri hears them, on whether the data is there and on cost, and kept three.

Siri AI, further down, changes that ceiling: its tools are the intents themselves, marked as such in the code, with no phrase to register, and Apple's preview of November 3 puts no number on them.

So the name underneath is a word in the platform's vocabulary, chosen once, before any app carries it, and never renamed, whatever an owner puts on top of it. We already had that rule for the words an app is described with: you can add a word, you can't change what one means. Siri added one more place where it applies, and every action we add from here will follow it.

The phrases Siri listens for are shared the same way. A language is added once, for every app, before we know which app will speak it. There are eight today: English, French, Italian, German, Spanish, Portuguese, Dutch and Arabic, the phrases we wrote for App Shortcuts, the Siri that is already on iPhones.

Three habits, and where they'll strain

An app doesn't only publish articles and videos. It plays a live stream, takes a form, holds a loyalty card, opens a chat between members, and for each of them the same question comes back: what should an assistant be able to do here, and how do we know without asking? Three habits came out of these questions, and I expect them to hold for the rest.

The scope comes from the structure. An assistant reaches what the owner put in the app, w