A small studio called Oi Studios shipped an iOS health app a few weeks ago with a detail worth sitting with: there is no HTTP client anywhere in the codebase. Not a slow one, not a rate-limited one. None. HealthKit is the data source, SwiftData holds everything on the device, and the only network traffic that exists at all is CloudKit, syncing to the user’s own iCloud account, for the handful of records the user typed in themselves. The company’s servers never see the data, because the company doesn’t have any.
That’s not a gimmick. It’s the correct architecture for this category of app, and most teams don’t build it this way because nobody stopped to ask if they had to.
The backend is usually a default, not a decision
Ask a founder why their fitness or health app has a server, a Postgres database, and an API layer, and the honest answer is usually “that’s how you build an app.” It’s not a considered tradeoff. It’s the template everyone reaches for, carried over from products that genuinely need a server: multi-user features, cross-platform sync, anything that has to exist outside one person’s device.
A lot of health and wellness apps don’t need any of that. The data (steps, sleep, heart rate, glucose readings pulled from a connected sensor) already lives on the phone, usually already in HealthKit. The app’s job is to read it, present it, maybe let the user add a note. There’s no second user who needs to see it, no server-side computation that can’t run on-device. The backend exists because it’s assumed, and once it exists, it becomes the thing you have to secure, patch, back up, and eventually explain to a regulator or a breach notification lawyer.
What the two-partition model buys you
The part of Oi Studios’ design worth copying is the split: data that comes from HealthKit stays local, permanently, full stop. Data the user types in themselves (a journal entry, a symptom note, something with no other source of truth) can optionally sync through CloudKit, which is the user’s own storage, not the company’s. The company never operates a database of anyone’s health records, because the app never sends them anywhere the company controls.
This changes the shape of every hard question a health app usually has to answer. Where’s the data stored? On the phone, and optionally in the user’s own iCloud. Who can subpoena it? Nobody at the company, because the company holds none of it. What happens in a breach? There’s no central store to breach. This is the same instinct behind our local-first software work: the safest place for sensitive data is the one place it already is, and every hop off the device is a decision that should have to justify itself, not a default step in the stack.
Where this approach actually breaks down
We’d be lying if we said this fits every product. The newsletter thread that surfaced this app also mentioned the honest cost: two CloudKit failures that only show up on a clean first launch, and near-zero analytics, because there’s no server-side pipeline collecting events. If your product depends on knowing where users drop off, or you need aggregate data to improve a model, or the whole point of the app is that two people see the same data (a shared care plan, a coach reviewing a client’s numbers), you need some server, and pretending otherwise just means building a worse, DIY version of one.
CloudKit is also an Apple-only answer. An Android build needs its own equivalent design, not a shim that quietly routes everything through a company API because that was easier to write once. And a two-partition model takes actual discipline to hold onto. The first feature request for “just log this event to help us debug” is where most of these architectures quietly grow a backend nobody decided to build.
Why this is worth doing now, not eventually
Health data sits at the intersection of the two things regulators and attackers both care about most this year: personal data with real consequences if it leaks, and a growing pile of it coming off connected devices, wearables, and sensors that talk over Bluetooth to a phone that then decides what happens next. Every one of those integration points is a place where a team has to decide whether data goes to a server or stays put. The default answer, for anything wearable- or sensor-derived, should be the second one unless there’s a specific reason it can’t be.
This isn’t an argument against ever building a backend. It’s an argument for building one on purpose, for the parts of the product that actually need it, instead of as an unexamined default that turns every health or connected-device app into a liability the moment something goes wrong. The Oi Studios app is a useful proof point that “no server” isn’t a compromise for a certain class of product. It’s the more honest design.
If you’re building something that touches personal health data or a connected device and you’re not sure whether it needs a backend at all, that’s a question worth answering before any code gets written. Get in touch and we can work through it.