If I Worked at Apple Again, I'd Build iApps

Fri, 31 Jul 2026 10:00:00 -0500

I worked as a contractor at Apple more than a decade ago. The specific work doesn’t matter, but if I walked back through the doors today, I know what I’d pitch.

Call them iApps, just as a thought experiment.

An iApp would be a small interactive tool generated for one specific problem. You ask Apple Intelligence for help, it gives you the research, and when the answer needs a calculator, form, checklist, map, or dashboard, it builds that too.

Then you can send the whole thing to somebody else, and it still works.

The Garden Calculator That Got Stuck in an HTML File

My wife is interested in turning part of our front yard into a stone-edged garden with more wildflowers. So I asked Claude to help me think through it.

It pulled together the HOA rules we should check, possible city permits, who to call, and some flower ideas. Then it built a calculator for the border. Give it the dimensions, choose chopped limestone, stacked flagstone, or river boulders, and it gives you a rough material estimate.

This was useful. It was also an HTML file with a little JavaScript inside it.

I can send my wife the research as text. I can send her the HTML file and explain how the JavaScript doesn’t work when it’s just a file. I am not hosting the html file somewhere just for her to open it. I don’t even know if its useful yet.

No-ThnX.

What I want to send is the answer, including the interactive part. She should tap it in Messages, see where the information came from, adjust the garden dimensions, switch the border material, and get a new estimate. No hosting. No App Store listing. No explanation about Safari sandbox for iMessage sucks.

That is an iApp.

An App That Behaves More Like a Document

An iApp would sit somewhere between a static AI answer and a full application.

It would not have a bundle identifier, a developer account, three subscription tiers, or a product manager asking about quarterly engagement. It might live for ten minutes, get saved until next spring, or be shared once and never opened again.

Think about the small tools we make and discard all the time:

A calculator for comparing other garden ideas
A packing checklist that changes with the weather and trip length
A scorekeeper for a game your family plays twice a year
A trip comparison with filters for price and travel time

None of those ideas deserves a conventional software project. They do deserve something better than a wall of generated text.

The iApp should be portable, more like a document than an installed app. It contains the interface, data, sources, and a declaration of what it can do. Send it through iMessage or AirDrop, save it in Files, or share an iCloud link. The receiving device validates and renders it.

The AI Should Generate a Recipe, Not Code

The obvious implementation is to let the model write HTML and JavaScript, then open it in a web view.

That is also how you turn every shared iApp into a tiny supply-chain attack.

I would not let the model generate Swift, JavaScript, WebAssembly, or anything else the device executes directly. It should generate a versioned document against a strict schema: text, fields, pickers, tables, charts, buttons, and a deliberately boring set of formulas and actions.

Perhaps something like this:

{
  "type": "calculator",
  "fields": ["length", "width", "border_material"],
  "result": "estimated_material",
  "capabilities": []
}

Apple would then own the renderer. A fixed SwiftUI component library turns that document into the interface. A formula engine handles arithmetic without eval. The model supplies the recipe, and the operating system decides how the recipe is allowed to run.

Pieces of this already exist. Apple’s Foundation Models can or should be able to produce Swift with very little guidance. With App Intents you can expose pre-declared system actions to enable built-in device functionality like sharing a link.

The parts exist. The product does not.

Make the Permissions Painfully Obvious

Most iApps would need no permissions at all. The garden calculator needs its bundled research, a few numeric fields, and some arithmetic. It does not need my contacts, photos, location, calendar, microphone, or the ability to phone a server in the background.

When an iApp does need more permissions, it should declare that capability before it opens… probably?

I could see the permission screen being a barrier to most normal people. who aren’t really going to care or understand the implications of granting it access to your calendar I think we Apple would need to build some sort of like end CP like layer on top of their native APIs and then build like a d a detection system into like you know is this Application requesting one event or all events. And uh, you know, denying access based on behavior, basically.

The research and the generated information would need citations. So you yeah, you would need like a Web researcher remote agent with sandbox rules that is able to Properly identify claims made by The intent or the output and verify the claims.

The Category Already Exists

The idea is not new. Claude already builds interactive artifacts for you. Google’s Opal makes mini apps inside the Gemini web app. Microsoft’s App Builder makes them inside Microsoft 365. You describe the tool, the model builds it, and you share it.

Some of them share better than others. Publish a Claude artifact and anyone can open the link with no account at all. Opal wants a Google sign-in. App Builder stays inside your Microsoft tenant.

But they all share the same way: as a URL pointing at somebody else’s server. However, a link is not a document. It needs the vendor to still be running, the page to still be published, and my wife to have the right app to run it. Publishing it means putting a calculator about our flower bed into the “cloud” somewhere.

What I want to send is the thing itself, sitting in the message thread on her phone. Not a pointer to a copy that lives somewhere else.

Apple Is Uniquely Positioned to Do This

Apple controls the full stack. People also trust an iPhone to open strange things their family sends them without turning every message into a security review.

iApps would make the operating system the host. Apple could define the component catalog, broker every capability, revoke a dangerous document, and keep generated behavior inside a box designed for it from the beginning.

This does not replace the App Store. A real product with customers, accounts, payments, and years of maintenance will continue to exist. iApps are for the space below that threshold, where a problem is worth solving but not worth turning into a company.

I would build that.

Sources

Guided generation — validated Swift data structures.
App Intents — defined actions exposed to system experiences.
SwiftUI — declarative Apple interfaces.
ShareLink — system sharing for custom data.
App Clips — lightweight parts of existing apps.
Anthropic Artifacts — interactive apps made and shared through Claude.
Google Opal — shareable AI mini apps.
Microsoft 365 Copilot App Builder — interactive apps made inside Copilot.

Disclosure: I have no inside knowledge and no idea whether Apple is working on anything like this. If it eventually announces something similar, that is a happy coincidence, not a leak.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

Apps on LLBBL Blog