Ideas · Research

iOS 27 AI App Opportunities

iOS 27 turns the iPhone into an agent platform you can build for in an afternoon: expose your data as App Intents + Spotlight entities, let new Siri / Apple Intelligence act on it, and run private LLM reasoning on-device with the Foundation Models framework — no server, no per-token cloud bill.

Compiled for Ananth · Research date 2026-06-11 · Apple developer pages dated Jun 2026 (iOS 27 / Xcode 27 beta). All claims sourced below; speculation is labelled.

The one-line thesis

The unit of opportunity is no longer "an app" — it's "an adapter."

Apple's pitch for iOS 27 is that you stop building screens and start building structured access to data + actions. A thin native app that (1) pulls a data source you care about, (2) declares it as App Entities into the Spotlight semantic index, and (3) exposes App Intents for actions, becomes something new Siri and Apple Intelligence can reason over and operate — conversationally, on-screen, hands-free.

For a solo builder using Claude Code as the executor, this collapses the cost of "I wish my phone could just do X with my data" from a project to an afternoon. The catch (per the field reports below): Siri's source selection is still brittle — getting the entity/intent descriptions and indexing right is the actual work, not the Swift.

The second catch — surfaced by the Kris Puckett tweet below — is the ingestion layer: most of the data you'd want to expose lives behind a messy API, or behind no API at all. That's where Printing Press (printingpress.dev) fits: it prints a token-efficient agent-native CLI / skill / MCP server (often backed by a local SQLite mirror) for an arbitrary API, app, or site. So the full pattern is connector → adapter → assistant: Printing Press makes the data reachable, Claude Code wires it into App Intents + Spotlight, and iOS 27 turns it into a Siri/Spotlight surface.

01

Research order & method

How this pack was built, so the reasoning is auditable.

Step 1 · Signal

The attached image

Two Apple dev features were flagged: the Foundation Models framework and App Intents. Used as the entry point for what to dig into.

Step 2 · Ground

Apple source pages

Read Apple's own developer docs and "What's new" pages (Apple Intelligence, Foundation Models, App Intents, Image Playground, Visual Intelligence, ML, iOS, SwiftUI). These set the factual floor.

Step 3 · Reality

The X thread

Max Weinbach's thread + replies on "vibe-building a Siri adapter app." Adds a practitioner's read on what actually works today and where it's brittle.

Step 4 · Synthesize

Opportunity map

Crossed the new capabilities against Ananth's real surfaces (Tesla, Mission Control, health, SMB/sales, finance) to produce ranked, buildable ideas.

02

What changed in iOS 27 for AI builders

Eight capability shifts, each grounded in an Apple page. The first two are the engine of the whole "adapter" pattern.

On-device + Private Cloud LLM

Foundation Models framework

A native Swift API giving direct access to Apple Foundation Models — on-device and in Private Cloud Compute — plus any provider that ships a Swift package conforming to the LanguageModel protocol.

Includes: multimodal prompts; on-device Vision tools so the model reasons about images alongside text; Dynamic Profiles to swap models/tools/instructions mid-session; and an Evaluations framework to test reliability across conditions.

Why it matters: private inference with no per-token cloud bill, and a clean way to plug in your own/3rd-party models behind one API.

The adapter primitive

App Intents → Siri & Spotlight

Connects your app to Apple Intelligence and Siri through schemas. Entity schemas contribute your content to the Spotlight semantic index for personal-context understanding; intent schemas let people act on that content in natural language — no fixed trigger phrases, no code changes as Siri's language model evolves.

Also feeds Shortcuts, widgets, controls, Live Activities, the Action button and Apple Pencil. This is the mechanism the X thread is built on.

On-screen awareness

View Annotations API

Maps your SwiftUI/UIKit views to entities so people can reference and act on what's literally on screen conversationally ("send this one to…", "remind me about that"). Extends App Intents from "your data" to "your data, in context."

Why it matters: turns any list/detail screen into something Siri can point at and operate.

Reliability tooling

Evaluations + App Intents Testing

The Evaluations framework checks Foundation Models features behave across dynamic conditions. App Intents Testing (beta) lets you test the Siri / Spotlight / Shortcuts pathways directly — no fragile UI automation.

Why it matters: the brittle part of the adapter pattern (does Siri pick the right source?) becomes something you can actually regression-test.

Image generation API

Image Playground

Generate high-quality images in many styles incl. photorealistic, transform a user's own photos via natural-language descriptions, and edit by description or touch. Runs on Private Cloud Compute (photos never stored/shared) and is available through an API for your apps.

Why it matters: in-app image gen/edit without standing up an image model or a cloud bill.

Camera / screen / world

Visual Intelligence

Apps can supply matching content for what's in front of the user — Camera on iPhone, on-screen content on Mac/iPad, real objects on Vision Pro — and launch into your app for richer detail or actions.

Why it matters: "point camera → my app's relevant data appears" becomes a supported flow. Strong for inventory / catalog / field use.

Custom models on Apple Silicon

Core AI

A new on-device framework for running your own custom models on Apple Silicon via a Swift API — with model specialization, ahead-of-time compilation, explicit memory control, zero-copy, and stateful execution.

Why it matters: for cases where the system foundation model isn't enough, you can ship a specialized model locally with serious performance control.

Text + automation + UI

Writing Tools, Shortcuts & widgets

Standard text views get proofread / rewrite / summarize / compose for free (custom text views can adopt the APIs). Shortcuts assembles multi-step automations from natural-language descriptions. Widgets are now customizable through App Intents.

Plus iOS 27 adds a Music Understanding framework and NowPlaying framework; SwiftUI gains a Document API, AsyncImage HTTP caching, and a @State macro with lazy init.

Distribution unlock Cheap to run at small scale. Apple's "What's new in Apple Intelligence" page says developers in the Small Business Program and under 2M total first-time downloads can access next-generation Apple Foundation Models on Private Cloud Compute at no cloud API cost. For a solo builder, that removes the usual "the AI bill scales with users" risk — directly relevant to shipping personal/SMB tools.
03

The tweets that started this — in plain English

Two tweets, read together. Max Weinbach (@mweinbach), 2026-06-09 — the "build the app yourself" claim. Kris Puckett (@krispuckett), 2026-06-10 — quote-tweets Max to add the missing ingestion layer (Printing Press).

Max Weinbach
@mweinbach · Jun 9, 2026
What's nice about Fable 5 and new Siri is I can basically just tell Claude Code to create an app that pulls in the data I want (codex app-server, Tesla) via APIs then make sure App Intents and Spotlight indexing are properly done.

Why wait for devs if I can do it in an afternoon
7 reposts · 13 replies · 444 likes · 115 bookmarks · 25,984 impressions
@altryne: connect the dots for me? is the new siri finally doing the thing they promised 2 years ago with app intents? It pulls info out?  —  Max: yup!
@afc_timio: Tried this with fable. Spotlight can see the index data, Siri still has problems deciding where to pull the data you ask for from so it misses a lot of times. This is a hard problem to solve without instructions.  —  Max: I'm trying to see if there's a good way to add better descriptions to the App Intents or if index + app intents help on similar or the same data.

What he's actually saying

The new "promised two years ago" Siri behaviour — pulling info out of apps and acting on it — is now real because of App Intents + Spotlight indexing. So instead of waiting for some company to build the app you want, you point Claude Code at an API (Tesla, a personal data server, etc.), have it generate a thin native app that fetches that data, and — critically — wire up the App Intents and the Spotlight entity index correctly. Then Siri/Apple Intelligence can talk to your data as if it were a first-party feature.

The shift: the hard, valuable part isn't the UI anymore — it's modelling your data as entities + intents the system can reason over.

Reality check from the replies Siri's source selection is brittle today. @afc_timio reports Spotlight indexes the data fine, but Siri often fails to decide which source to pull from, so it misses. Max's own fix is exactly the lever to budget time for: better App Intent / entity descriptions and testing whether Spotlight indexing + App Intents reinforce each other on overlapping data. Treat "make Siri reliably pick my data" as the real engineering task, and use the App Intents Testing framework to measure it.
Kris Puckett
@krispuckett · Jun 10, 2026 · quote-tweeting Max
Have to imagine this is even more useful with @mvanhorn · printingpress.dev
0 reposts · 1 reply · 4 likes · 2 bookmarks · 2,493 impressions
@mvanhorn (Matt Van Horn, maker of Printing Press): yes. will add a lot of magic auto-magically

What Kris adds

Max assumes you can already get the data — point Claude Code at "the Tesla API" or "a codex app-server" and it fetches. Kris's point: the reachability of that data is itself the bottleneck. Real sources are messy APIs, rate-limited endpoints, or sites with no public API at all. Printing Press closes that gap — from one prompt it prints an agent-native CLI (plus a Claude Code skill, an OpenClaw skill, and an MCP server) for any API/app/site, baking in the playbook that a local SQLite mirror beats a remote call and compound commands beat ten round trips.

So the two tweets stack into one pipeline: Printing Press prints the connector → Claude Code builds the iOS adapter → iOS 27 exposes it to Siri. Matt Van Horn's reply ("will add a lot of magic auto-magically") is the maker confirming the connector layer is meant to slot in exactly here.

Where this is interpretation The combined "factory" stack is our synthesis, not a shipped product. Printing Press is real and prints connectors today; Claude Code building iOS adapters is real (Max's afternoon claim). Wiring the two into a repeatable Tesla/Mission-Control/CRM pipeline is the inference this pack proposes — and it inherits Max's open risk (Siri source selection) on top of any per-source connector work.
04

The full factory stack: Printing Press × Claude Code × iOS 27

Layering Kris Puckett's tweet onto Max's turns "build one app" into "run a factory for Siri adapters." Five stages, each owned by a different tool — the first two are the new part.

Stage 1 · Source

Any API / app / site

Tesla, a codex app-server, Linear, a CRM export, FPL, Google Workspace, WhatsApp exports, a niche website with no public API.

Stage 2 · Connector

Printing Press prints the CLI / skill / MCP

One prompt → token-efficient Go CLI + Claude Code skill + OpenClaw skill + MCP server, often over a local SQLite mirror. Makes messy/no-API data reliably reachable.

Stage 3 · Adapter

Claude Code builds the iOS app

Uses the connector to fetch, then writes the Swift app + App Intents + Spotlight entity schema + App Intents tests. The "afternoon" Max describes.

Stage 4 · Expose

Entities · intents · index · views

App contributes entities to the Spotlight semantic index, declares intents for actions, and maps on-screen views via View Annotations.

Stage 5 · Interface

Siri / Spotlight / Visual Intelligence

Apple Intelligence becomes the front-end: ask, act, point the camera — no custom UI required for the core loop.

Why this is the meta-unlock

The repeatable artifact isn't an app — it's the connector→adapter loop.

Once stages 2–3 are scripted, every new source is mostly "run Printing Press, then re-run the Claude Code adapter scaffold against the new connector." That's what makes a fleet of personal/business Siri adapters feasible for one builder: Tesla today, Mission Control tomorrow, a CRM the week after — same loop, different connector.

Printing Press's own framing ("every API has a secret identity") matters for the entity schema: the adapter should expose the source's useful shape (Linear as a "team behaviour observatory," not just issues) — which is exactly the rich-description work the field reports say Siri's source selection depends on.

Speculative End-to-end automation is not proven. Each stage exists independently; nobody in these sources has demonstrated the full Printing-Press-to-Siri loop running unattended. Treat the factory as a thesis to test (see Experiment 1), and budget per-source work for auth, rate limits, and Siri source disambiguation.
05

Opportunity map — 16 ideas

Each card: why iOS 27 makes it better, the Apple APIs you'd touch, an MVP path, and the main risk. Prioritised toward Ananth's real surfaces. Filter, star, and jot notes — your picks are saved locally in this browser.

Show
Workspace mode: ★ = "I want to build this", and the note box is yours to scope it. Saved in this browser only (localStorage) — nothing is sent anywhere. No JS? The cards still render; only starring/notes are disabled.

Tesla / car ops adapter

Build now
The literal example in the tweet · high personal payoff
Why now
Siri can read live car state (range, charge, location, climate) out of Spotlight and trigger actions by voice/on-screen — without Tesla shipping it.
APIs
App Intents (entity + intent schemas), Spotlight index, Foundation Models for "is it worth charging now?" reasoning.
Connector
Print a Tesla CLI/MCP with Printing Press (auth + rate-limit handling baked in) so the iOS app reads a stable local interface instead of raw HTTP.
MVP
Thin app polling the Tesla API → expose VehicleEntity + intents (precondition, set charge limit). Test via App Intents Testing.
Risk
Tesla API auth/rate limits; Siri source ambiguity if other car/location data competes.

Mission Control iOS companion

Build now
Notice Board on your phone, voice-capturable
Why now
"Hey Siri, capture to Ideas: …" and "what's in my Inbox lane?" become native. Items become Spotlight-searchable entities; View Annotations let you act on the open item.
APIs
App Intents, Spotlight, View Annotations, Foundation Models for auto-categorisation, WidgetKit for a Notice Board widget.
Connector
A Printing Press CLI over brain.json / the inbox (local SQLite mirror) gives the app and Dab the same agent-native interface to query/append.
MVP
App reads brain.json (synced) → NoticeItemEntity + a Capture intent that appends to inbox. Mirrors the existing WhatsApp capture flow.
Risk
Sync/auth to the repo; keeping render pipeline as source of truth. Low — you own both ends.

Read / learning queue assistant

Build now
Your saved-links problem, solved natively
Why now
On-device Foundation Models summarise saved articles privately; Siri answers "what should I read next on X?" from your own queue via Spotlight.
APIs
Foundation Models (summarise/classify), App Intents + Spotlight entities, Writing Tools for digests.
Connector
Printing Press CLIs for read-later sources (e.g. an Instapaper/RSS/site with no clean API) pull articles into a local mirror the app indexes.
MVP
Share-sheet capture → on-device summary + tags → ArticleEntity. "Read next" intent ranks by topic/length.
Risk
Summary quality on long pages; dedupe vs existing Notice Board "Read" lane.

Personal CRM adapter

Build now
"Who is this, last touch, next step" by voice
Why now
People + interactions become Spotlight entities; Siri surfaces context on-screen ("remind me to follow up with this person"). On-device model drafts the follow-up privately.
APIs
App Intents, Spotlight, View Annotations (act on the contact on screen), Writing Tools / Foundation Models for drafts.
Connector
Printing Press already ships CRM CLIs (its Sales/CRM library lists contact-goat et al.) — print one for your CRM and the app reads a uniform interface.
MVP
Import contacts + notes → PersonEntity with lastContact/nextStep. Intents: log interaction, draft follow-up.
Risk
Privacy of relationship notes (keep on-device); messy contact data.

Personal finance / spend tracker

Build now
Private money Q&A, no data leaves the phone
Why now
Foundation Models reason over transactions on-device (real privacy win for money). "How much on dining this month?" answered from your own indexed data.
APIs
Foundation Models (on-device only), App Intents + Spotlight, WidgetKit for a spend widget.
Connector
A Printing Press CLI handles the messy ingestion (bank/export endpoints → local SQLite mirror); the app reads the mirror so raw statements never hit a cloud.
MVP
Import CSV/bank export → TransactionEntity → category + query intents. Keep inference strictly on-device.
Risk
Bank data ingestion is the hard part; categorisation accuracy.

Health / nutrition coach

Build now
Cradlewise-adjacent; sensitive data stays local
Why now
Photo-of-meal → on-device Vision tools + Foundation Models estimate/log; HealthKit data becomes conversational via Siri. Privacy is a genuine selling point here.
APIs
Foundation Models multimodal, Vision tools, HealthKit, App Intents + Spotlight, Visual Intelligence for "what is this food".
MVP
Snap meal → on-device estimate → MealEntity; "how did I eat today?" intent over HealthKit + logs.
Risk
Nutrition estimate accuracy; HealthKit permissions; don't over-claim medical value.

Field-sales / SMB workflow assistant

Build now
Leverages the free-PCC small-business angle
Why now
Reps log visits / pull account context by voice; Visual Intelligence turns "point camera at shelf/product" into matched catalog data. PCC at no cloud cost under the small-biz/2M-downloads threshold.
APIs
App Intents + Spotlight, Visual Intelligence, Foundation Models (PCC), Shortcuts for multi-step "log visit" flows.
Connector
Print CLIs for the CRM + any lead/tender source (Printing Press lists eu-tenders, conduyt-crm) so account data is one query away.
MVP
AccountEntity + "log visit" / "next best action" intents over a CRM/Sheet export.
Risk
Real CRM integration depth; offline reliability in the field.

Generic "any-API → Siri" adapter kit

Build now
The meta-play: a template, not one app
Why now
The tweet's pattern generalises. A reusable Claude-Code scaffold that takes an OpenAPI spec → generates entities + intents + Spotlight indexing + tests. Build once, point at anything.
APIs
App Intents, Spotlight, App Intents Testing, Foundation Models for schema/description generation.
Connector
Printing Press is the front half: it normalises the source (incl. sites with no spec) into a CLI/MCP, so the scaffold consumes a uniform connector instead of bespoke HTTP per API.
MVP
Scaffold for one API end-to-end (e.g. Tesla), then parameterise the entity/intent generation.
Risk
Generalisation is hard; per-API auth differs. But highest reuse for a Claude-Code-driven builder.

Adapter Factory / Siri Adapter Studio

Build now
The most powerful meta-idea — Kris + Max combined
Why now
Don't build one app — build the loop. A repeatable toolchain: Printing Press prints a connector for a new source, then a Claude Code scaffold turns that connector into an iOS adapter (entities + intents + Spotlight + tests). New source = re-run the loop, not a new project.
APIs
App Intents, Spotlight, App Intents Testing, Foundation Models — orchestrated by Claude Code; Printing Press for the connector layer.
Connector
Printing Press is stage 2 of the factory: CLI + Claude Code skill + MCP per source, over a local SQLite mirror.
MVP
Run the loop end-to-end on one source (Tesla), then a second (Mission Control) reusing the same scaffold — prove the second one is hours, not days.
Risk
Speculative — the full unattended loop is unproven; each source still needs auth + Siri source-selection tuning. Higher leverage than any single app if it holds.

Wardrobe / personal-brand assistant

Wait / watch
Fun, image-heavy, lower stakes
Why now
Image Playground for outfit mockups; Visual Intelligence to catalog clothes from camera; on-device model suggests combos.
APIs
Image Playground API, Visual Intelligence, Foundation Models multimodal, Spotlight.
MVP
Photograph items → GarmentEntity → "what to wear for X" intent.
Risk
Cataloguing friction is high; payoff is novelty. Watch how reliable Visual Intelligence matching is first.

Family / time-allowances coordinator

Wait / watch
Ties to iOS 27 Time Allowances
Why now
iOS 27 surfaces device/time-allowance concepts; a family app could expose chores/screen-time as entities Siri manages. Speculative on how open the allowance hooks are.
APIs
App Intents + Spotlight; Time Allowances / Screen Time integration (verify availability).
MVP
ChoreEntity + allowance intents; start without deep Screen Time hooks.
Risk
Speculative — depth of public Time Allowances API is unconfirmed. Multi-user/parental data is sensitive.

"AI employees" / business-ops agent

Wait / watch
Ambitious; better as a server + thin iOS face
Why now
iOS 27 makes a great front door (voice + on-screen) to back-office agents, but the actual multi-step work belongs on a server, not on-device Siri.
APIs
App Intents as the trigger surface, Foundation Models for light reasoning, Shortcuts for chaining; real logic external.
MVP
Expose 2–3 "run this ops task" intents that call your existing automation; keep iOS thin.
Risk
Scope creep; Siri reliability for high-stakes actions. Don't put irreversible ops behind a flaky trigger yet.

Music-understanding / media tool

Wait / watch
New frameworks, unclear personal payoff
Why now
iOS 27 adds a Music Understanding framework + NowPlaying framework — opens "what's this vibe / build a set from my taste" apps.
APIs
Music Understanding, NowPlaying, Foundation Models, App Intents.
MVP
"Describe what I'm listening to" / mood-tag library intent.
Risk
Framework maturity unknown; weaker tie to Ananth's stated priorities. Watch what these frameworks actually expose.

Visual-intelligence inventory / catalog

Wait / watch
Strong if a real catalog exists
Why now
Point camera at a product/shelf → your app returns matched SKU/spec/stock and deep-links in. Great for SMB/retail; needs a real catalog to be worth it.
APIs
Visual Intelligence (+ the App Intents visual-intelligence matching intent), Spotlight, Foundation Models.
MVP
Index a sample catalog → image-match intent returns the entity.
Risk
Match accuracy; only valuable atop a maintained catalog. Pilot before committing.

On-device privacy / "ask my documents"

Wait / watch
Privacy is the whole pitch
Why now
Foundation Models on-device + Core AI for a specialised model = a private "ask my sensitive docs" tool with nothing leaving the device. Differentiated, but inference quality on-device is the open question.
APIs
Foundation Models (on-device), Core AI, App Intents + Spotlight, SwiftUI Document API.
MVP
Index a folder of docs → on-device Q&A intent; measure answer quality vs cloud.
Risk
On-device model capability ceiling; retrieval quality. Validate quality before building UX.

Image-Playground content/marketing helper

Wait / watch
Quick wins, but commoditised
Why now
In-app photorealistic generation + photo transforms with no image-model bill (PCC). Good for a content/marketing micro-tool.
APIs
Image Playground API, Writing Tools, App Intents.
MVP
"Make a variant of this product photo in style X" intent.
Risk
Style controllability vs dedicated tools; crowded space. Lower strategic value than the data-adapter ideas.
06

Ranking — build now vs wait / watch

Build-now = high personal payoff, APIs are GA-ish, and you own both ends of the data. Wait/watch = depends on framework maturity, accuracy you can't yet verify, or weaker tie to your priorities.

IdeaLaneWhy iOS 27 helpsMain risk
Tesla / car ops adapterBuild nowLive car state + voice actions via App Intents/SpotlightTesla API auth; Siri source ambiguity
Mission Control iOS companionBuild nowVoice capture + on-screen actions on your own boardRepo sync; keep render pipeline canonical
Read / learning queueBuild nowPrivate on-device summaries; "read next" intentSummary quality; dedupe with Read lane
Personal CRM adapterBuild nowPeople as entities; on-screen follow-up draftsNote privacy; messy contacts
Finance / spend trackerBuild nowOn-device money Q&A — real privacy winBank data ingestion; categorisation
Health / nutrition coachBuild nowMultimodal meal logging; local HealthKit Q&AEstimate accuracy; don't over-claim
Field-sales / SMB assistantBuild nowVoice logging + Visual Intelligence; free PCC at small scaleCRM depth; field offline reliability
Generic any-API → Siri kitBuild nowReusable Claude-Code scaffold for the whole patternGeneralisation + per-API auth
Adapter Factory (Printing Press × Claude Code)Build nowConnector→adapter loop; new source = re-run, not rebuildFull loop unproven; per-source auth + Siri tuning
Wardrobe / personal-brandWait / watchImage Playground + Visual Intelligence cataloguingHigh cataloguing friction; novelty payoff
Family / time-allowancesWait / watchCould expose chores/allowances to SiriTime Allowances API depth unconfirmed
AI employees / business opsWait / watchiOS as voice front-door to server agentsScope creep; flaky trigger for high stakes
Music-understanding toolWait / watchNew Music Understanding / NowPlaying frameworksMaturity unknown; weak priority fit
Visual-intelligence inventoryWait / watchCamera → matched catalog entityMatch accuracy; needs real catalog
On-device "ask my docs"Wait / watchFully private doc Q&A via Foundation Models/Core AIOn-device capability ceiling
Image-Playground content helperWait / watchIn-app image gen with no model billControllability; crowded space
07

First 3 experiments I'd actually run

Ordered to de-risk the brittle part (Siri source selection) early, on data you fully control, before investing in anything user-facing.

Experiment 1 · ~1 day

Build one end-to-end adapter-factory loop: Tesla

Goal: run the full Kris+Max stack once — Printing Press connector → Claude Code iOS adapter → Siri — and confirm Siri can reliably read and act on the data via App Intents + Spotlight. This is the go/no-go for the whole factory thesis.

  1. Connector (Printing Press): from a single prompt, print a Tesla CLI/MCP (auth, rate limits, local mirror handled). Verify you can query vehicle state from the connector before any Swift.
  2. Have Claude Code scaffold a minimal SwiftUI app that reads vehicle state through that connector.
  3. Define one VehicleEntity (range, charge %, location) and contribute it to the Spotlight index; add two intents: "precondition the car" and "set charge limit".
  4. Write deliberately rich entity/intent descriptions — this is the lever @afc_timio and Max both point at.
  5. Use the App Intents Testing framework to assert Siri/Spotlight resolve the right entity for 8–10 phrasings.
  6. Record two numbers: the Siri source-selection hit rate, and how much of stages 2–3 was reusable scaffold vs Tesla-specific. Both gate every other idea — and tell you whether a second source is hours or days.
Validates: the whole factory thesisTools: Printing Press, App Intents, Spotlight, App Intents TestingKill criteria: <~70% correct source selection after tuning, or the connector→adapter loop isn't meaningfully reusable
Experiment 2 · ~1 day

On-device reasoning, no cloud: private spend Q&A

Goal: test whether the on-device Foundation Model is good enough to be useful on your own structured data, with zero data leaving the phone.

  1. Import a CSV of transactions into TransactionEntity objects (no bank integration yet — keep it a fixture).
  2. Use the Foundation Models framework on-device only to answer "how much on dining in May?" and "biggest unusual charge?".
  3. Wrap it in a single "ask my spending" intent so Siri can invoke it.
  4. Run the Evaluations framework over ~20 questions to measure correctness/consistency.
  5. Judge: is on-device quality good enough, or do these ideas need PCC / a server?
Validates: finance, health, docs, read-queue ideasAPIs: Foundation Models (on-device), Evaluations, App IntentsKill criteria: consistent wrong-number answers on simple aggregations
Experiment 3 · ~1 day

Dogfood: Mission Control capture by voice

Goal: ship something you'll actually use daily, and learn the View Annotations / on-screen-awareness flow on a board you already understand.

  1. App reads a synced copy of brain.json; expose items as NoticeItemEntity in Spotlight.
  2. Add a "capture to <category>" intent that appends to the inbox (mirroring the WhatsApp capture contract — Dab/render stays the source of truth).
  3. Add View Annotations so "remind me about this" works on the open item.
  4. Use on-device Foundation Models to suggest the category, matching the existing capture semantics.
  5. Live with it for a week; note every miss for the description-tuning backlog.
Validates: Mission Control companion, CRM, any capture-style appAPIs: App Intents, Spotlight, View Annotations, Foundation ModelsKill criteria: capture is slower/less reliable than the WhatsApp flow
Sequencing logic 1 before everything else. Every idea in this pack rests on "Siri reliably picks my data and acts on it." Experiment 1 measures that on the cheapest possible surface. If it passes, fan out; if it's brittle, the work is description/indexing tuning (and the App Intents Testing loop), not more apps.
08

Sources

Apple developer pages (dated Jun 2026, iOS 27 / Xcode 27 beta cycle) and the originating X thread. Claims above trace to these; anything not directly supported is labelled Speculative.

Source: projects/ios27-ai-app-opportunities.html · Compiled 2026-06-11 · Mission Control / Notice Board · Edits via Dab/Claude only. Star/note state is stored locally in your browser and never transmitted.