The API is the contract
Two codebases means two sets of hand-written types, and only one of them gets updated.
Products
One backend, three places to install it.
Most mobile projects begin as a second codebase against an API that was never designed for them. Stacks builds native iOS and Android apps and desktop binaries from the same project, against the same typed API client, so a field rename breaks the build instead of the app store release.
What this always turns out to involve.
The work that arrives whether you planned for it or not.
Auth on a device is different
Tokens, refresh, biometrics, and deep links do not behave like a browser session.
Push is infrastructure
Certificates, tokens, and per-platform payloads outlive whoever set them up.
Release engineering
Signing, notarising, and store submission is where a hobby project stalls.
What is already in the box.
All of it in the same install, typed against the rest of your application.
Native builds
The Craft bridge produces iOS and Android apps and desktop binaries from the project, driven by buddy commands.
Shared types
The generated API client is typed from the same models the server uses, so the compiler catches contract drift.
Device auth
Token auth, passkeys, and two-factor come from the same auth package as the web session.
Push notifications
APNs and FCM are notification channels beside mail and SMS, with one class per notification.
Offline-friendly data
Queue-backed sync jobs and realtime channels keep a device current without a bespoke protocol.
Signing and delivery
Build and release steps live in the same CI workflow as the web deploy.
The layers it leans on.
Every one of these ships in the same install. Follow one to see what it covers.
From the command line.
Buddy scaffolds, runs, and ships this the same way it does the rest of the app.
buddy build mobile
buddy dev desktop
buddy deploy
Next door to this.
Projects of this shape usually grow into one of these.