ZaatarLABS Get in touch →
← All posts
Smart Budget

I said I'd revisit this when iOS 27 shipped

Ask Anything is back in Smart Budget 2.0 — just not on the on-device model I said I was waiting for.

5 min

The comment I left for myself

The July post about building on Apple's on-device model ended with a section called "the feature I built, finished, and then hid." Ask Anything — a conversational interface to your own spending data — was finished, compiling, and commented out. Every entry point carried the same tag:

// ASK-ANYTHING-DEFERRED-IOS27: chat sheet presentation
// disabled. Implementation kept intact in
// Intelligence/Chat/* + Views/Insights/AskAnythingSheet.swift
// — revisit when iOS 27 / a larger on-device model lands.
// The 3B model in iOS 26 was unable to reliably extract
// intent + filters even with constrained DynamicGenerationSchema

iOS 27 has shipped. The feature is back in Smart Budget 2.0, out now on the App Store. But not the way that tag implied.

What the tag assumed

When I wrote "revisit when iOS 27 / a larger on-device model lands," I had a clear picture of what revisiting would look like: a bigger model, same on-device architecture, uncomment the sheet presentations, ship. The whole point of the three-stage pipeline — understander extracts intent, deterministic Swift runs the query, string template narrates the result — was that the model was local. No API key, no network call, no server that could ever see your transactions. The on-device constraint wasn't a compromise; it was the premise.

The problem with the 3B model in iOS 26 wasn't speed. It was reliability under the conditions that matter in a finance app. Even with DynamicGenerationSchema constraining the output, even at temperature 0.1, the intent extraction was wrong often enough that I couldn't stake "ask me anything about your money" on it. In a budgeting app, a wrong intent classification doesn't produce a slightly off answer. It produces a confident wrong answer. And a confident wrong answer about your finances destroys the feature — not gradually, immediately, the first time it happens to you.

So the tag sat there, waiting for a model that could close the reliability gap.

What I actually shipped

Money Advisor — that's the name it ships under — doesn't use the on-device model. It runs on Apple's Private Cloud Compute.

That's a different architecture, and I want to be direct about what that means. Private Cloud Compute is Apple's infrastructure: your question about your spending leaves the device, gets processed on Apple's hardware, and the answer comes back. Apple says nothing is stored and the computation is ephemeral — that's Apple's claim to own, not mine to vouch for. But it is a network call. I'd held the line on that for the entire iOS 26 cycle, and I crossed it for this feature, on the strength of Apple's privacy story around PCC.

Why cross it at all? Two reasons.

The first is capability. Apple's Private Cloud Compute gives you access to a model that can handle natural language intent reliably enough to stake user trust on. The model's role hasn't changed — take a question about money, extract a structured intent, hand it to deterministic Swift that runs against the actual transaction database. What changed is where the model lives.

The second is the alternative. A third-party cloud API was never on the table for a finance app. So the realistic options were: on-device with an unreliable model, or Apple's private infrastructure with a privacy story I'm comfortable enough with to ship. I chose the latter for this feature.

What stayed the same

The deterministic layer underneath Money Advisor is the same architecture the July post described. The model understands language; Swift runs the numbers. "How much did I spend on groceries?" becomes a typed intent with a period and a category, which becomes a Core Data query, which becomes a result rendered by a template. The model never touches the actual transaction data, never does arithmetic, never writes a sentence about a specific merchant.

That wasn't a choice I revisited. The lesson from the on-device work — that a language model will hallucinate transaction details the moment you let it narrate from raw data — applies just as much to a more capable cloud model. The pipeline shape is right. The execution environment changed.

The code that's still there

The original AskAnythingSheet, the on-device extraction path, all of Intelligence/Chat/ — still in the codebase, still commented out, still tagged. If Apple ships an on-device model that closes the reliability gap, the path is there. I'm not betting against it.

What I misjudged in July was that iOS 27's answer to the problem would necessarily be a larger on-device model. Apple offered a different answer first, and it was good enough to ship against.

What this means if you're building something similar

The on-device versus cloud question for LLM features isn't binary, and the right boundary isn't the same for every feature. "No data ever leaves this device" is a strong promise, and it's the right one for transaction data sitting at rest. But a natural-language question about your spending has a different privacy profile than the underlying ledger. Whether Apple's Private Cloud Compute is a boundary you're willing to cross for a given feature is a judgment call — about the feature, the data involved, and the provider's guarantees.

What I'd tell myself from July: frame the constraint more precisely before you defer. "Revisit when iOS 27 lands" is a time condition. The real condition was "revisit when a model capable of reliable intent extraction is available within a privacy boundary I'll ship against." Those aren't the same thing, and the second one leads you to the right answer faster.

The on-device model was genuinely useful across the rest of the app — the insight cards, receipt scanning, the categoriser all run on it and work well in 2.0. For one specific job, at one specific reliability bar, it wasn't enough. That's a narrower critique than I left in July, and it's the accurate one.

Written by Omar Al Homaidi · ZaatarLABS · @zaatarlabs