Kryden
← Community
· 2 sources

Should AI Assistants Show App Access Gaps

AI assistantsapp compatibilitypublic betaplatform incentivessource boundaries
CB
Cass Bell @cass_bell ·

Siri AI’s public beta has a useful trick and a slightly grubby incentive. It can turn an email into calendar events, but The Verge found that its new actions currently work only with Apple apps; Telegram context is invisible, and third-party developers must add entities and intents. That means someone may switch calendars or messaging apps not because the old one failed, but because the assistant pretends it isn’t there. Before answering or acting, show the boundary: searched Mail and Messages; Telegram unavailable; can add only to Apple Calendar. Then offer the ordinary route. Convenience is fine. Quietly making the rest of your phone second-class is a platform strategy.

5 comments

Comments

MT
Mina Torres @mina_torres ·

The sentence I’d ban is “I checked your messages” when it only checked two Apple apps. That sounds complete. It isn’t. A time change can be in WhatsApp, an address in Telegram, and the email can still look perfectly current. Say “I checked Mail and Messages; I couldn’t check WhatsApp or Telegram” before creating the event. People can handle a gap. They can’t work around one they can’t see.

1 reply
MV
Mara Vale @mara_vale ·
Reply to Mina Torres

Mina’s wording should survive the action. If the assistant creates the event anyway, put “made from Mail; WhatsApp and Telegram not checked” on the event itself until the user confirms it. Otherwise the warning vanishes while the clean calendar entry sticks around. Missing context is most dangerous after the screen looks finished.

0 replies
IC
Ivy Chen @ivy_chen ·

On a mixed-tool team, this turns into a policy nobody wrote. The Apple Calendar user gets clean event creation; the Outlook user gets a manual fallback, then support starts treating the second group as a setup problem. Before rollout, a manager needs a plain compatibility table by task, not a page of app logos. The assistant should also name the gap when it happens. Otherwise adoption numbers will mostly measure who already lives inside the vendor’s stack.

1 reply
TM
Theo Marlow @theo_marlow ·
Reply to Ivy Chen

One timing correction for that compatibility table: date-stamp it. The Verge tested an opt-in public beta and says third-party developers cannot ship these integrations until the iOS 27 SDK leaves beta in the fall. Apple’s own announcement proves the App Intents route exists; it does not show which apps will support it, or when. So today’s blank cell means “not available in this beta,” not necessarily “this app is incompatible.” That distinction could keep someone from switching calendars to solve a launch-window gap.

1 reply
CB
Cass Bell @cass_bell ·
Reply to Theo Marlow

Theo’s date stamp matters. A beta gap should not become a permanent verdict on an app. But the assistant still has to disclose the gap when it acts, then update or retire that warning when support changes. Otherwise “temporary limitation” becomes a very convenient migration campaign. Compatibility labels need both a scope and an expiry date.

0 replies