Apple Foundation Models Are Now Free for Most Indie Apps — Three Questions That Decide What I Build

What stopped me during the WWDC 2026 Platforms State of the Union was not a benchmark chart. It was a single sentence about pricing: developers whose apps have fewer than 2 million first-time App Store downloads can now use Apple Foundation Models for free, including the larger models running on Private Cloud Compute.

The wallpaper apps I run as an indie developer fit inside that bracket. In practical terms, the marginal cost of adding AI features to them has just dropped to almost zero. Which is exactly when things get risky — free is the price at which every feature idea suddenly sounds reasonable. So I spent the weekend writing down candidates and sorting them properly.

Reading the announcement as an operator, not a spectator

First, the parts of the announcement that matter for day-to-day operation rather than for headlines.

• The free tier applies to developers under 2 million cumulative first-time downloads, and it covers not only the on-device models but also the larger ones on Private Cloud Compute
• Foundation Models now accept image input — for a wallpaper app, this is the headline feature
• The same Swift API can route requests to Claude or Gemini through server-side integration
• The framework is scheduled to go open source this summer

What deserves caution is the edge of the free tier, which is still underspecified. What billing looks like once you cross 2 million downloads, and what rate limits apply on the Private Cloud Compute side, cannot be judged from the announcement alone. My reading: this is plenty for starting small experiments, but I will not design features whose viability depends on the free tier lasting forever. Never place the free tier somewhere you cannot retreat from.

Three questions to stop myself from shipping features just because they are free

The most dangerous thing about zero marginal cost is that the bar for adding features quietly drops to zero with it. I settled on three questions for sorting candidates.

Question 1: Does it deliver its value fully offline? Wallpaper apps get used on trains and in bed, in places where connectivity is unreliable. A feature that closes entirely on-device is not only more stable for the user — it also frees me from server incidents as an operational risk.

Question 2: Is the blast radius small when the model is wrong? AI output is wrong at some rate, always. I decided not to place it anywhere a miss lands directly in the review section — near billing flows or inside push notifications. It belongs where a miss means little more than a slightly odd sort order.

Question 3: Does it avoid adding recurring maintenance cost? In indie development, the time spent looking after a feature costs more than the time spent building it. Per-OS-version branching, re-checking behavior after every model update, prompt upkeep. Starting with the feature that minimizes this fixed cost is the realistic move.

Sorting the candidates for a wallpaper app

Here are the four candidates I wrote down, run through those questions.

Smart tagging of images — the direct beneficiary of image input support. It closes on-device, and a miss just means slightly off tags; the UI never breaks. It feeds straight into search and category quality. This is my first pick.

Natural-language search — queries like "something that feels like a quiet night." Attractive, but its quality rests entirely on the tagging layer underneath, so I positioned it as stage two, built on top of the first pick.

Generated copy for notifications and widgets — rejected by question 2. Off-key copy is highly visible, and a notification is the single worst place to be wrong.

A chat-style concierge — rejected by question 3. It carries expectation management as a maintenance cost with no end date, and I have an honest doubt about how many wallpaper app users actually want a conversation.

The conclusion is simple: build on-device tagging only. No Private Cloud Compute, no server-side integration in stage one.

Prototype shape — pin the output to a type

The first decision for the prototype was to never accept the model's output as free-form text. A parser for free-form text has no upper bound on how badly things can fail. Foundation Models can pin output to a Swift type, so I define the container for tags before anything else.

import FoundationModels
 
// A fixed, structured container for wallpaper tags
@Generable
struct WallpaperTags {
    @Guide(description: "3-5 mood tags describing the atmosphere")
    var moods: [String]
 
    @Guide(description: "1-3 main subjects in the image")
    var subjects: [String]
}
 
let session = LanguageModelSession()
let tags = try await session.respond(
    to: "Tag this wallpaper's mood and subjects",
    generating: WallpaperTags.self
)

Written this way, the failure mode has a ceiling. The worst case is an array with mediocre contents — the entire class of crashes from JSON parse failures and missing keys disappears at the type level. One caveat: the image-input surface is the newly expanded part of the API, so I am treating the exact shape as provisional until the formal documentation and the summer open-source release confirm it.

Server-side integration belongs to a later stage

Routing Claude or Gemini through the same Swift API is the most ambitious part of the announcement. But it imports a layering question into the app: which processing stays on the device, and which goes out to a cloud. The way I think about that boundary is the same framework I wrote up in Running Gemini's Managed Agents API: Where Cloud Execution Ends and My Local Agents Begin. My order of operations is to ship the fully on-device stage first, and revisit the integration only when a concrete need appears.

Let the agent do the survey, keep the judgment

For the weekend groundwork, I handed an Antigravity agent the job of mapping hook points in my wallpaper apps' image pipeline — which screen finalizes which resolution, and which model layer should own stored tags. It is the same working style as in Replacing a Decade-Old SKPaymentQueue with StoreKit 2 — Migrating 4 Wallpaper Apps with an Antigravity Agent: the agent does the legwork of the survey, and the judgment about what to build stays with me. Now that the marginal cost has dropped to zero, that judgment is where indie developers will differ.

As a next step, check whether your own app falls inside the free tier, write down every candidate feature without filtering, and then use the three questions to cut the list down to one. Deciding what not to build is the safest way to take advantage of this change. Thank you for reading.