An iOS app with no server — records stay on the device, and a phone move is an encrypted file

A goshuin is the calligraphy stamp a Japanese shrine or temple gives visitors. Once you own several goshuin books, logging them falls behind: the photos exist, but there is no way to sort out afterwards which shrine you visited and when.

Reading the complaints about existing goshuin apps, the top reasons for one-star reviews were “you have to register” and “ads”. So three things were decided first: no accounts, no ads, and no user data held on my server. The surest way to keep the third is to have no server.

Without a server, everything a server used to do has to happen on the device.

1. Moving phones. With no sync, I had to provide a way to carry records to the new phone — and that file contains visit history and photos.
2. Schema changes. On a server you migrate once. On phones, every user's database is stopped at a different version, and each must be able to climb to the latest.
3. Unlocking purchases. With no server to confirm entitlement, any hole in a screen becomes a free unlock.

“The app never talks to a server of mine” is a test, not a spec. An architecture test statically checks that the app code and modules contain no fetch / XMLHttpRequest / WebSocket path. It is not an intention; writing one fails CI.

I decided not to implement encryption myself. JavaScript crypto can't be audited here and offers no side-channel guarantees, so I wrote a native Swift module that calls the OS's CryptoKit and CommonCrypto.

What I gave up: sync, sharing, multiple devices and a web version. The cost is explicit, too. Lose the backup passphrase and nobody can restore it — including me.

Backups use a custom .goshuin format. The key comes from PBKDF2-HMAC-SHA256 at 600,000 iterations (the OWASP 2023 recommendation), and the content is encrypted chunk by chunk with AES-256-GCM. The whole 45-byte header is additional authenticated data on every chunk, so tampering with the iteration count or chunk length fails authentication on decrypt. The plaintext length is checked too, so a truncated tail is detected.

Monetisation is a single one-time purchase and three feature gates: a second goshuin book, bulk filing of photos, and PDF/CSV export. The unlock is checked in two places — the UI and the service layer, and the service layer also rejects calls that don't qualify, so a missed check in a screen does not become a free unlock. All of this runs on the device, so it is not designed to stop a tampered phone.

The code follows ports and adapters with a single composition root. Swap the SQLite and crypto adapters and the domain layer runs in Jest without a simulator.

Crash reports and usage analytics are on by default (they can be turned off in settings). The content of your records is never sent.

158 commits (excluding merges) between 2026-09-08 and 09-25. 40 architecture decision records, each noting the options not taken and the conditions for reversing the decision.

429 test files, plus 11 on-device E2E flows in Maestro (numbered flows only; shared sub-flows excluded). The on-device SQLite carries 6 migration versions and can climb from any of them to the latest.

The display name, landing page and App Store listing ship in 14 languages. The only fixed costs are the Apple Developer Program fee and the landing page's domain, and stopping either is simply “don't renew”.

“We don't hold personal data on our servers” is easy to write in a spec. This is a worked example of making it a promise a test won't let you break. For apps where not holding the data is itself the value — health, children, journals, personal finance — this structure carries over as is.

Having no server removes operating cost, and it also removes legal and review questions you would otherwise have to answer. In exchange, sync, backup and purchase checks have to be built on the device, which is where the engineering effort goes.

The on-device SQLite migrations, encrypted backups and StoreKit 2 one-time purchase are written up with code in designing a serverless, offline-first iOS app with Expo.

I take on offline-first mobile apps as mobile app development.