A RAG that speaks your language
General models are confidently out of date on fast-moving platform APIs. We're building a retrieval layer over current documentation and best practices to fix that — starting with Swift and Kotlin, and extending to your own repository.
Why this is needed
A model's knowledge is frozen at training time, but platform SDKs are not. Every year brings new concurrency rules, new view modifiers, new recommended patterns — and the old ones don't disappear from the training data, they just stop being right. The result is the failure mode every platform developer recognises: an answer that looks plausible, compiles under an older toolchain, and quietly teaches you a pattern the vendor deprecated two releases ago.
Retrieval fixes the part that scale alone doesn't. A bigger model has read more of the internet, including more outdated posts. Grounding the answer in current documentation is what makes it current.
Swift and SwiftUI
FirstThe platform where the gap between what models know and what Apple recommends is widest.
Swift changes fast, and the changes are the kind that matter: structured concurrency and actors,
@Observable replacing ObservableObject, view modifiers that come and go,
and a set of Human Interface Guidelines that no amount of general training data captures reliably.
Grounding answers in current Apple documentation and guidelines is the difference between an assistant that helps and one you have to fact-check. That's what this layer is for, and it's why Swift is first.
Kotlin and Jetpack Compose
NextDeclarative UI with the same currency problem, plus a concurrency model that's easy to get subtly wrong.
Compose moves quickly and its idioms have shifted more than once — state hoisting, side-effect APIs,
the interaction between recomposition and coroutine scopes. Coroutines and Flow compound
it: code that looks correct can leak a scope or collect on the wrong dispatcher, and a model working
from stale examples will reproduce exactly those mistakes.
The retrieval layer targets current Android guidelines and Compose APIs for the same reason it targets Apple's.
More languages
PlannedThe approach isn't Swift-specific — it applies wherever the SDK moves faster than the training data.
Swift and Kotlin come first because mobile platforms have the sharpest version churn and the strictest platform conventions. The same treatment extends to any ecosystem with the same problem, and the catalogue grows the same way the model catalogue does: included in the plan, with nothing for you to migrate.
Your repo, your RAG
PlannedAnswers grounded in your actual codebase, not a generic style guide.
Knowing the framework is half the problem. The other half is knowing your code — your modules, your naming, the architecture decisions someone made three years ago and never wrote down. Indexing your repository means answers follow your conventions instead of inventing new ones.
It will be opt-in and under your control: the index is encrypted, lives only in the EU, and you can delete it whenever you want. That follows from how the rest of the service already works — EU-only processing and zero logs aren't a setting here, they're the architecture.
Why it matters more with unlimited tokens
Retrieval costs tokens. Every grounded answer carries retrieved documentation alongside your prompt, which on a metered API means a good answer literally costs more than a bad one — a pricing model that quietly penalises the thing you actually want.
On a flat plan that tension disappears. Retrieve aggressively, keep the context full, iterate until it's right: the bill doesn't move. The two halves of this product are built for each other, which is why the arithmetic is worth a look even before the RAG ships.