DEV Community: Jin Xu

Shipping a Privacy-First "Super App" With Expo SDK 57, SQLite and Zero Servers

Jin Xu — Tue, 03 Nov 2026 15:35:38 +0000

At one point my phone had a calendar app, a budgeting app, a habit tracker, a notes app, a password manager, a mood journal and a shopping list app. Each wanted its own account. Three wanted a subscription. All of them wanted my data on their servers.

So I built LifeDesk, a single app that covers all of that and more. I gave myself one hard rule: no backend. No LifeDesk account, no LifeDesk server, nothing to breach. This post covers what that rule forced me to figure out.

1. The rule: your phone is the database

Everything lives in one SQLite file on the device (expo-sqlite, WAL mode). Onboarding asks for one thing, your name, and even that never leaves the phone.

This changes a lot. Without a server there's no "fix it in the API": every bug fix that touches data has to ship as a client migration and run correctly on thousands of devices in states you can't see.

2. Stack

Expo SDK 57 / React Native 0.86, expo-router for file-based navigation (~120 screens)
expo-sqlite for storage, expo-secure-store for secrets, expo-crypto for encryption
i18next for 5 languages (EN, VI, ES, FR, ZH)
Firebase used only for force-update config (Remote Config), system push topics and the AI gateway. No user data is stored there.

3. Migrations are your API versioning now

The schema has gone through 20+ versions. What I learned:

Run migrations sequentially and idempotently. Each step checks whether its table or column already exists, because dev builds and interrupted upgrades leave devices half-migrated.
Turn on PRAGMA foreign_keys from the start. I didn't, and later had to write explicit clean-up code for orphaned rows (habit logs, order items, budgets of deleted categories).
Never lose history when a user deletes a category. Records move to a fallback "Other" category instead. People forgive a missing feature. They don't forgive lost data.

4. A vault on a phone: don't derive the key from the PIN

The Vault stores passwords, card numbers and CVVs encrypted with AES-256-GCM. The tempting design is "derive the key from the user's 4-digit PIN". I chose not to:

A 4-digit PIN has only 10,000 possibilities, which is too weak to be a key on its own.
A forgotten PIN would make the data unrecoverable.

Instead, a random per-install key lives in the iOS Keychain or Android Keystore (expo-secure-store). The PIN and biometrics gate access to it. The Vault re-locks the moment you leave it, and it never shows ads.

5. Backup without a server: Google Drive's appDataFolder

The obvious objection to local-first is "what if I lose my phone?". My answer is Google Drive's appDataFolder, a hidden, app-scoped space in the user's own Drive (drive.appdata scope). The app can't see your other files, and I never see your backup.

When a user deletes their account, the app also deletes the Drive backup and revokes the OAuth grant. That's important for both the store policies and user trust.

6. An AI assistant that writes into SQLite

The feature I'm proudest of: you type or say "Lunch 12 dollars" or "Remind me to call mom tomorrow at 7", and the right record lands in the right module.

How it works:

The model returns exactly one JSON object that must match a strict schema.
The prompt includes the user's real category list and today's date, so "next Tuesday" resolves correctly.
If a required field is missing, the AI asks instead of guessing. A short reply like "12k" is merged into the pending request rather than starting a new one.
Every result shows as an action card with "View" and "Edit" buttons, so the user always sees what was written.

Validating everything before it touches the database mattered more than prompt tricks.

7. Paying for it without wrecking UX

LifeDesk is free and ad-supported. My rules:

Banners only on the main tab screens. Never in the Vault or on PIN screens.
Every rewarded ad is opt-in, in exchange for points the user can spend (unlocking PDF/CSV export, freezing a habit streak).
App-open ads are rate-limited, so you don't get an ad every time you switch apps.

8. What I'd do differently

Turn on foreign keys on day one.
Treat backup and restore as a core feature from the first sprint, not a late add-on.
Scope smaller. Nine modules is a lot to polish at once.

Try it

LifeDesk is free on Google Play and the App Store. I'd especially love feedback from people who care about local-first software: what would make you trust an app like this with your data?

I built a P2P disappearing-message app with React Native and WebRTC. Here's what was harder than expected

Jin Xu — Tue, 03 Nov 2026 11:15:09 +0000

Most "private" messengers still ask for your phone number. I wanted something closer to passing a note: share a short code with someone you already know, talk, and when you're done there's nothing left on either phone.

That became IncogSnap, an Android app (iOS coming) built with Expo / React Native. You create a room, get a 6-digit code (or a QR / link), your friend types it in, and the two phones talk directly over WebRTC. No account, no phone number, no email.

This post is about the parts that turned out harder than they looked.

The stack

Expo SDK 57 / React Native 0.86
react-native-webrtc for the peer connection and DataChannel
tweetnacl for crypto
Firebase Realtime Database for signaling only (exchanging SDP offers/answers and ICE candidates)
expo-screen-capture to block screenshots and screen recording

1. "Peer-to-peer" doesn't connect on its own

My first version used public STUN servers only. On the same Wi-Fi it worked every time. Then I tested one phone on mobile data and one on home Wi-Fi, and a large share of connections simply never came up.

Carrier-grade NAT and symmetric NAT are the usual culprits: STUN lets each phone discover its public address, but some NATs won't accept traffic from a peer they haven't talked to first. The fix is a TURN relay as a fallback, over both UDP and TCP:

iceServers: [
  { urls: ['stun:…:3478', 'turn:…:3478?transport=udp', 'turn:…:3478?transport=tcp'], username, credential },
]

The trade-off is worth being honest about: when TURN is used, the relay sees both IP addresses. It can't read anything, because the payload is already end-to-end encrypted before it reaches WebRTC, but "nothing ever touches a server" stops being a true sentence. I removed that claim from the store listing.

2. End-to-end encryption on top of WebRTC

WebRTC already encrypts the transport (DTLS-SRTP), but the keys are negotiated through the signaling channel. If the signaling server were compromised, it could in principle sit in the middle. So each room also does its own key exchange:

Each device generates an X25519 key pair (nacl.box.keyPair()).
Public keys are exchanged, and both sides derive the same shared key with nacl.box.before().
Every message, photo and clip is sealed with nacl.secretbox (XSalsa20-Poly1305) and a fresh random nonce.

To make a man-in-the-middle detectable, both phones show a short fingerprint of the two public keys. My first version used 4 bytes, which turned out to be too short: brute-forcing a colliding key pair at 32 bits is cheap. It's now 8 bytes (64 bits), shown as four groups of four hex characters so two people can read it aloud:

export function sessionFingerprint(a: string, b: string): string {
  const h = nacl.hash(utf8Encode([a, b].sort().join('|')));
  const hex = Array.from(h.slice(0, 8)).map((n) => n.toString(16).padStart(2, '0')).join('').toUpperCase();
  return hex.match(/.{1,4}/g)!.join(' ');
}

3. On mobile, "offline" is the normal state

Pure P2P has an awkward property: if the other phone isn't connected right now, your message has nowhere to go. And on mobile the OS suspends background apps aggressively, so "the other phone isn't connected right now" happens constantly.

A lost message looks exactly like a broken app, so I added a small encrypted mailbox for 2-person rooms:

If the live DataChannel send fails, the message (already encrypted with the session key) is written to rooms/{code}/mailbox/{role}/{msgId} in Firebase.
When the other phone reconnects, it drains the mailbox and deletes each entry.
Firebase only ever holds ciphertext. It never has the key.

To make reconnecting possible, each device stores its room key pair in SecureStore instead of generating a new one on every launch. A room where nobody has been connected for an hour is closed for good: the record and its mailbox are deleted, and both phones wipe their keys.

4. Disappearing timers when two clocks disagree

"Delete this message 5 minutes after it's seen" sounds simple until you remember that two phones never agree on the time, and either user can change the timer mid-conversation.

What worked for me:

The timer value travels with each message, so a message keeps the setting it was sent with, even if someone changes the timer later.
Timer changes are their own protocol message (timer-set) with a timestamp, so both sides apply the same change in the same order.
The countdown starts on each device when that device displays the message, so clock skew between the phones doesn't matter.

5. App Store rules for content you can't read

Apple's guideline 1.2 requires apps with user-generated content to offer reporting, blocking and a way to act on abusive users, even if you can't see the content. With no accounts and E2E encryption, all of it has to work around that:

Text runs through an on-device word filter before display.
Report sends the reported user's anonymous ID and a reason to a moderation queue, never message content.
Block ends the chat and prevents that ID from ever connecting to this device again.
A confirmed ban is enforced both by the app (checked at launch and on resume) and by the database rules, so a banned ID can't create or join rooms.

What I'd do differently

Test across networks on day one. Same-Wi-Fi testing hid the NAT problem completely.
Write the privacy copy last. Every architecture change (TURN, mailbox, push) made a previously true sentence false. I now treat the privacy policy as part of the code review.
Design for "offline" first. The mailbox should have been in v1.

Try it

IncogSnap is free on Android (ad-supported, no ads inside chats or the camera):
https://play.google.com/store/apps/details?id=com.bzotech.incogsnap

It's closed source for now. I'm considering publishing the crypto and protocol module, so if you'd find that useful, tell me in the comments. I'm also happy to go deeper on any of the WebRTC or crypto parts.