On-device AI for iOS.
No per-token bills.
No data leaving the phone.
Most iOS AI features call a cloud model — a bill that grows with every user, a network round-trip on every request, and sensitive data leaving the device. Apple's on-device stack makes another path real: the model runs on the phone — so responses don't wait on the network, stay fast and consistent on any connection (even none), and cost nothing per token. I help iOS teams take it — cutting the cloud-API cost on an AI feature they already ship, or building a new one that runs entirely on-device.
Not slideware: I shipped WhattaRAG, a production on-device RAG app, in 100% native Swift at ~4 MB — no servers, no accounts, no API costs.
I reply within one business day. If it looks like a fit, we'll set up a 20-minute call.
Who this is for
Two ways teams arrive — both already have an iOS app in production.
"Our AI feature is racking up a cloud bill."
You ship an AI feature — chat, summarization, search, document Q&A — and it calls a cloud model. The bill scales with usage, not value: a power user costs you money. And you may be uneasy about user data leaving the device for a third-party API.
You know it's you if: API spend is a line item someone keeps asking about — or you've thought "what happens when their pricing changes, they deprecate the model, or they have an outage?"
→ Assessment → Migration Sprint
"We want an AI feature and haven't started."
You want an AI capability but don't want to stand up backend infra, manage keys and rate limits, or take on per-user cost and privacy liability before you've even validated the feature.
You know it's you if: "we should have AI in the app" has been on the roadmap for two quarters and keeps slipping.
→ Assessment → Feature Build
For either path, if your app touches health, legal, financial, or field data, on-device is more than a cost play. "Data never leaves the device" is a compliance-and-trust position you can put in front of your own customers — it moves the work from "nice to have" to the reason they choose you. WhattaRAG is built exactly this way: documents never leave the phone.
Not a fit
Said plainly — because knowing when to say no is the point.
- You need frontier-model reasoning (the biggest cloud models) that today's on-device models can't match. The assessment will tell you this honestly rather than sell you a migration that degrades your product.
- You're Android-first or web-first. This is native iOS, built on Apple's on-device stack.
- You're pre-product or pre-idea. Start with an MVP, not an AI retrofit.
The offer
Everything starts with one assessment: fixed price, fixed scope, about a week. If you go on to build, the plan and the price come straight out of it — nothing open-ended.
On-Device AI Assessment
A focused engagement that answers one question honestly: can this AI feature run on-device on Apple's stack, and what's the path? Either way you get a concrete answer — a migration plan with savings math if you already ship an AI feature, or a feature definition and build plan if you're starting fresh.
What you get — a written report, plus a call to walk you through it:
- Feasibility verdict — can the target feature run on-device (which model / embedding / retrieval approach), where the honest limits are, and where a hybrid or cloud fallback is genuinely the right call.
- For a migration — a side-by-side: your current cloud cost (per-token, projected at your real usage) vs on-device (zero marginal cost), the privacy/compliance delta, and the migration path with its risks.
- For a new feature — the feature spec, the on-device approach, and what "good" looks like.
- An implementation plan — a scoped estimate and timeline for the follow-on work.
Why it's paid: it's senior engineering judgment, not a sales call. Paying for it keeps it honest — if on-device is the wrong answer for you, the report says so.
Credited toward the build: the $2,000 is credited in full toward a Migration Sprint or Feature Build if you proceed. Build, and the assessment was effectively free; don't, and you still own a plan you can act on with anyone.
Migration Sprint
Take an AI feature you already ship through the cloud and move it on-device.
Shape: short, fixed-scope, fixed-price — planned from the assessment. Typically 1–3 weeks.
Outcome: the feature runs on-device — cloud-API cost on it goes to zero, data stops leaving the device, per-user cost stops scaling.
Feature Build
Build a new on-device AI feature from spec to shipped.
Shape: milestone-based or ongoing, planned from the assessment. Larger and longer-term than a migration.
Outcome: a shipped on-device AI feature — no backend to run, no keys to rotate, no per-user cost, privacy by construction.
I reply within one business day. If it looks like a fit, we'll set up a 20-minute call, then the assessment is the paid next step.
Proof: I've already shipped the hard version
It comes down to one thing: I've already built and shipped the hard version. WhattaRAG is a live App Store app that does on-device retrieval-augmented generation — embeddings, vector search, and LLM generation — entirely on the phone.
It's real and downloadable
A production app you can install and inspect right now — not a prototype or a demo video. Shipped 2026-06-10.
100% native Swift
No React Native, Flutter, or Electron shell; no JS bridge, no bundled runtime. That's why it's fast and why it's tiny.
~4 MB download
For an app running embeddings + vector search + on-device LLM generation, strikingly small — the heavy lifting rides on Apple's own frameworks, not a bundled model.
Fully on-device
No network calls, no accounts, no telemetry. Documents never leave the phone — it works in airplane mode, which is the same reason responses never wait on the network.
Zero API cost
No per-token bill because there's no token vendor. Cost per user query: $0.
Apple's production stack
The Foundation Models framework behind Apple Intelligence (LLM), NLContextualEmbedding (embeddings), GRDB + Accelerate/vDSP (SQLite storage + vector similarity in Swift) — the exact frameworks your migration or feature would use.
What it proves for you: the on-device path isn't a research bet. A full RAG pipeline — about the most demanding on-device AI workload short of training — already runs in a shipped Swift app at ~4 MB. If that works on-device, your summarization, search, chat, or doc-Q&A feature almost certainly can too. Whatever I'd migrate or build for you, I've already shipped the harder version myself.
Questions you're probably asking
Why on-device instead of just calling a cloud API?
Four reasons, in the order they usually bite: a bill that scales with usage instead of value; user data leaving your control; a hard dependency on one vendor's pricing, uptime, and model lifecycle; and a network round-trip on every request — on-device responses don't wait on the network, so they stay fast and consistent on any connection, even none. On-device removes all four at once. If none of those hurt you, cloud is fine — and the assessment will say so.
Is on-device actually good enough? These models are smaller than the biggest cloud models.
Honestly, for frontier-level open-ended reasoning — no, and I'll tell you that up front. But "on-device" isn't only Apple's built-in model: open-weight models (Llama, Qwen, Phi) now run locally via Apple's MLX and are advancing fast, which widens what's feasible well beyond the small-model stereotype. And most shipped AI features don't need frontier reasoning anyway — summarization, classification, extraction, semantic search, and RAG-style Q&A over your own content run well on-device today; WhattaRAG does exactly this in production. Choosing the right model for your feature is precisely what the assessment decides, before you spend on the build.
Is this the same as Apple Intelligence?
Related, not identical. Apple Intelligence is Apple's own set of consumer features. What I build uses the same on-device foundation — the Foundation Models framework Apple ships for its on-device model, plus the embedding and retrieval stack around it — but pointed at your app's features and your content, not Apple's. Same underlying Apple technology; your product, your data, your use case. (AltoCode isn't affiliated with or endorsed by Apple.)
Is the cost saving real, or does it just move somewhere else?
The per-token bill genuinely goes to zero — there's no vendor to pay, and the compute runs on the user's device, which you don't pay for. You trade a recurring, growing cloud bill for a one-time build cost. The assessment projects your actual numbers so it isn't hand-waving.
How is on-device "more private"? Everyone claims privacy.
Because here it's architectural, not a policy line. No network call means no data to intercept, log, subpoena, or leak from a third party. "Documents never leave the device" is testable — put the phone in airplane mode and the feature still works. That's a very different conversation with your compliance team than "our vendor is SOC 2."
How long does it take?
Assessment: ~1 week. Migration Sprint: typically 1–3 weeks, with a fixed timeline scoped from the assessment before you commit. Feature Builds are larger and milestone-based. No open-ended hourly.
Why a solo developer and not an agency? What about bus factor?
You get senior work directly — no agency margin, no junior coding behind a senior's name. Scope is deliberately fixed and bounded (assessment, then a defined sprint), so each engagement stands alone and leaves you with working code and a documented plan you own — you're never exposed on a long open-ended timeline.
Which devices and iOS versions does this support?
Apple's on-device AI stack needs recent hardware and OS (WhattaRAG targets iOS 26+). This is a real constraint, so the assessment includes your user base's device/OS split — you'll know exactly what coverage you'd get, and where a fallback matters, before building.
Paying for cloud AI — or want a feature without it?
Email me about your feature. I reply within one business day; if it looks like a fit, we'll set up a 20-minute call to confirm on-device is viable and whether the assessment is the right next step. It's a fit check, not free consulting — and not every project is a fit, which I'll tell you plainly.
contact@altocodelabs.com