On not taking the free thing

There’s been a steady stream of complaints from developers over the past few weeks about Apple’s Private Cloud Compute pricing. The story is that the new server-side AI tier is free, but only for developers in the App Store Small Business Program, which caps eligibility at two million lifetime downloads. A lot of developers are over that cap — sometimes for apps that haven’t made money in years — and there’s currently no paid path for them to access PCC even if they wanted to. They’re locked out, and they’re not happy about it.

I’m not locked out. Patter is well under the cap, and Gums & Bones is exactly the kind of small studio the program is meant for. I had the free tier available to me. I thought about using it. I decided not to. And the more I thought about why, the more I started to think the developers who got locked out got handed a gift, even if it doesn’t look like one from where they’re standing.

Here’s what Apple’s offering. The on-device AI model that ships with iOS is genuinely capable, but it has a small context window — roughly 4,000 tokens at the time of writing — which means it can’t reason over a folder full of documents or a very long input. For developers who want to do that kind of work, Apple has Private Cloud Compute: their server-side equivalent, running on Apple silicon in Apple data centres, with an architecture that genuinely doesn’t store or log requests. PCC is, by current standards, the most privacy-respecting server AI service on the market. That’s not the part I’m worried about.

The part I’m worried about is that it’s free. And by “free,” I mean: free to small developers, today, while Apple is building the platform’s gravitational pull. There is no published price for what it costs when you exceed the small-developer cap. There is no paid tier yet for the developers complaining about being locked out. There is no committed pricing for what the free tier will cost in two years, or five, when the program changes — and programs always eventually change.

Imagine, as a small developer, you build a feature on top of free PCC. It does something genuinely useful — let’s say it lets a user point your app at a folder of documents and synthesise them into something coherent. Users love it. Reviews praise it. People upgrade specifically for it. Two years pass. Apple announces that the small-developer program’s free PCC allotment is being capped at, say, ten thousand requests per month per app, with overage at some per-request rate. Or Apple announces a paid PCC tier and the free tier transitions to a “try before you buy” of some kind. Or you grow past the two-million-download cap, and there’s still no paid option, and your feature stops working for new users. Or any of the other things platforms do.

You have three options at that point. You can absorb the cost and let it eat into a one-time-purchase app’s economics forever. You can introduce a subscription, which, if you’ve made other promises to your users, breaks them. Or you can pull the feature, which is the option that protects your business but which makes you the bad guy. There’s no good fourth option. The decision tree was set the moment you opted in.

This is how platform lock-in actually works, by the way. Not through forcing anyone. Not through any malicious intent at all — I don’t think Apple is doing this in bad faith, and I think their privacy architecture is sincerely built. Lock-in works through subsidy. You give developers something genuinely valuable, for free, while you build the integration. Over time, the developers’ products evolve to depend on the subsidised resource. Then, when the economics need to change — and they always need to change — the developers can’t leave, because their users now expect the feature, and rebuilding without the subsidised resource is no longer possible. The platform didn’t do anything to them. They did it to themselves, one rational decision at a time.

The developers who are currently locked out of free PCC because their apps crossed two million downloads are being protected from making that bargain. They get to look at PCC, decide whether it’s worth paying for at some yet-to-be-announced price, and choose with their eyes open. The developers in the program are being offered something that looks like a deal and is actually a commitment.

That’s the case for treating “I can’t access it” as a better problem to have than “I have free access I might come to depend on.”

Now, in fairness to Apple, the small-developer program is a real benefit, and the privacy guarantees are real, and the engineers who built PCC clearly care about what they built. None of this is an argument that PCC is bad. It’s an argument that a feature whose continued existence depends on a subsidy you don’t control is a different kind of feature than one whose continued existence depends on hardware the user already paid for. The on-device model on your user’s iPhone keeps working whether Apple is happy with you or not. It keeps working if Apple changes its pricing strategy. It keeps working if Apple shifts the program. It keeps working five years from now, on hardware that’s already been bought. That’s a different asset class than a service.

So Patter’s AI feature uses the on-device model and only the on-device model. There are real things it can’t do. The folder-scale case is the one I keep coming back to — a user with a Notes folder of fragments who’d like the app to pull a routine out of all of it. That’s a useful thing, and it doesn’t fit in 4,000 tokens. For now, those users will have to summarise first, or write the routine themselves. The cost of that limitation is real, and I’m not pretending it isn’t. But it’s the cost of having a feature I can sustain forever, on my own terms, without having to revisit the decision every time Apple revisits its pricing.

There are two things I’m guessing at, and I might be wrong about both. The first is whether Apple eventually offers a paid PCC tier that’s priced cleanly and committed to for the long term. If they do, this whole calculation changes — a transparent paid service you can budget around is a very different thing from a free service whose future you can’t predict. I’d reconsider then. The second is whether the on-device model’s context window grows. It almost certainly will. If next year’s model handles 32,000 tokens instead of 4,000, the folder-scale case I keep mentioning might just disappear into the on-device path, and the question I’m wrestling with here gets quietly resolved by hardware progress. That’s the most likely outcome, and it’s another reason not to commit to a server path now.

The studios that took the free tier when it was offered will, in many cases, end up fine. Some will make the right calls when the terms change. Some won’t, and we’ll read about them later — pulled features, broken promises, awkward subscription pivots dressed up as “investing in the future of the product.” A few will quietly absorb costs that should have killed them, propped up by users who don’t know that’s what’s happening.

The studios that were locked out, and the ones who chose to stay out, won’t have any of those problems. They’ll have a different problem, which is that their app can’t do as much. That’s a real problem. But it’s a problem you can solve by being honest about it, instead of a problem that solves you when the terms change.

I picked the smaller problem. Most days I’m fairly sure it was the right choice.