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.
\nCall them iApps, just as a thought experiment.
\nAn 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.
\nThen you can send the whole thing to somebody else, and it still works.
\nMy 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.
\nIt 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.
\nThis was useful. It was also an HTML file with a little JavaScript inside it.
\nI 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.
\nNo-ThnX.
\nWhat 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.
\nThat is an iApp.
\nAn iApp would sit somewhere between a static AI answer and a full application.
\nIt 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.
\nThink about the small tools we make and discard all the time:
\nNone of those ideas deserves a conventional software project. They do deserve something better than a wall of generated text.
\nThe 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.
\nThe obvious implementation is to let the model write HTML and JavaScript, then open it in a web view.
\nThat is also how you turn every shared iApp into a tiny supply-chain attack.
\nI 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.
\nPerhaps something like this:
\n{\n "type": "calculator",\n "fields": ["length", "width", "border_material"],\n "result": "estimated_material",\n "capabilities": []\n}\nApple 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.
\nThe parts exist. The product does not.
\nMost 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.
\nWhen an iApp does need more permissions, it should declare that capability before it opens… probably?
\nI 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.
\nThe 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.
\nThe 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.
\nSome 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.
\nBut 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.
\nWhat 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.
\nApple 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.
\niApps 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.
\nThis 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.
\nI would build that.
\nDisclosure: 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.
\n\n\n", "date_published": "2026-07-31T10:00:00-05:00", "url": "https://llbbl.blog/2026/07/31/if-i-worked-at-apple.html", "tags": ["AI","Apple","Apple-intelligence","Apps","Product-design"] } ] }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.
\n