Native apps. One foundation underneath.
Every nexapps app is written in its phone’s own language: Swift and SwiftUI on iPhone, Kotlin and Jetpack Compose on Android. Underneath, they share one foundation, so a new app starts with sign-in, subscriptions, AI and privacy already done.
Why one foundation
Sign-in, subscriptions and privacy are the parts of an app that are easiest to get wrong and least visible when they are right. Building them once, carefully, means every app gets the careful version.
And the time inside each app goes into the app itself: the screens, the writing and the one thing it is for.
What the apps are made of.
- On iPhone
- Swift and SwiftUI
- StoreKit 2 for subscriptions, SwiftData for what is stored on the phone, and Sign in with Apple for apps that offer sign-in. The first app, Pausa, is built with the first two and has no sign-in. It has not launched.
- On Android
- Kotlin and Jetpack Compose
- The same foundation, written for Android. No nexapps Android app has shipped yet.
- On the server
- Python, FastAPI and PostgreSQL
- One server behind every app, for accounts, subscriptions, AI and analytics. It is in production today, self-hosted, with an encrypted backup every night.
- For AI
- Anthropic
- Called from the server, never from the phone, so no key ever ships inside an app.
What every app gets on day one.
- 01 / 05
A person is signed in before they have signed up.
Every session starts anonymous and durable. There is no account wall between a person and the product, and nothing about the first run depends on a network round trip succeeding.
Sign in with Apple is available when a person wants their data to follow them, not as a gate. The upgrade path preserves the anonymous identity rather than replacing it, so nothing is stranded behind an account that did not exist yesterday.
The failure case is designed for, not assumed away: an unreadable Keychain is recoverable, and switching accounts does not leave a device wedged between two identities.
Built with Sign in with Apple, the iOS Keychain and FastAPI.
- 02 / 05
Trial, subscription, restore, expiry — decided once.
The server decides what someone is entitled to; the app never works it out for itself. Both platforms ask the same question and get the same answer, so the two can never disagree about whether someone has paid.
It also records where a purchase came from, so adding a web subscription later is one more payment source rather than a second system to keep in step.
Restore, expiry and refund all resolve in the same place. A paywall bug is one fix, not one per platform.
Built with StoreKit 2 and Google Play Billing, checked on the server.
- 03 / 05
No model key ever ships inside an app.
Provider credentials live on the backend and nowhere else. An app binary that is decompiled yields no key, because there is none in it.
Prompts are versioned configuration on the server, not strings compiled into a build. Re-tuning how the product writes is a config change, not a release cycle and a review queue.
Usage is metered per app and per person before it reaches a provider, so a runaway cost is a capped one.
Built on Anthropic, called from the server with versioned prompts.
- 04 / 05
One event schema, one endpoint, every app.
Events go to our own endpoint, stamped with the app they came from, and the schema is shared across every app rather than reinvented per product.
No advertising SDK and no attribution SDK ships inside the app. There is no tracking prompt because there is nothing to ask permission for.
The purpose is product measurement — did this screen work, did this flow finish — and the schema is designed so that is all it can answer.
Built with FastAPI and PostgreSQL, on self-hosted servers.
- 05 / 05
The boundary is architectural, not a policy page.
Where private data stops is decided in code, on the device, before anything is sent. The policy document describes that boundary; it does not create it.
In Pausa the daily entries live in an on-device store and never reach our servers. What crosses is a de-identified summary — weekly for the narrative, monthly for the doctor report — counts and averages, never a name and never free text.
A boundary like this is hard to retrofit and cheap to build in from the start, so it lives in the shared layer rather than being decided again in every app.
Built with SwiftData on the phone, and no server copy of an entry.
What the platform deliberately leaves out
- Not shipped
No ad or attribution SDK
No third-party analytics or advertising SDK is embedded in a nexapps app, so there is no second set of eyes on a person by construction rather than by promise.
- Not built
No cross-app profile
Events are stamped with the app they came from and answer product questions. No profile of a person is assembled across apps, because the schema has nowhere to put one.
- Not written
No invisible growth code
Nothing runs in a nexapps app whose effect a person cannot see. Growth that needs to be hidden from the user is growth this studio does not want.
- Checkable
This site, held to the same standard
Zero third-party requests, no cookies, no external font, script or image. That takes about ten seconds to verify with the network tab open, and it is the point.
Every app the studio ships starts here, on the day it starts.