stable

Native mobile & PWA

Verified mobile support: PWAs and browser apps are the proven path; WebView wrappers are expected but untested; React Native is not supported today.

noy-db's runtime requirements are deliberately small: a JavaScript engine with the Web Crypto API (crypto.subtle) and, for browser persistence, IndexedDB. Which mobile paths satisfy that today, honestly labeled — proven (covered by the test suite), expected (same runtime, not covered), or not supported:

PathStatus
PWA / browser app✅ Proven
WebView wrapper (Capacitor, Tauri mobile, …)⚠️ Expected, untested
React Native / Expo❌ Not supported today
Fully native (Swift / Kotlin)❌ Not a target — noy-db is a JS library

Can I build a PWA?

Yes — this is the strongest mobile story. A PWA is a browser app, and the browser is a first-class noy-db runtime: persist with to-browser-idb, and every envelope in IndexedDB is ciphertext (open DevTools → Application → IndexedDB and check — the same experiment as See the ciphertext). Offline-first is the default behavior, not a mode: reads and writes need no network, and sync catches up when you're back online.

Since 0.4.0-pre.12 the shell plumbing has a package of its own: in-pwa covers storage persistence with an explicit grant/deny signal, install-prompt capture, display-mode detection, and an online watcher shaped for the sync engine. It holds no keys and sees no plaintext, so it adds nothing to the threat model.

Eviction is the risk worth designing for. iOS ITP evicts script-writable storage — IndexedDB included — of non-installed web content after about seven days without interaction. Installed home-screen apps are safer, and navigator.storage.persist() exempts an origin where granted. guardLocalVault() probes the store before the vault opens and fails closed: if the partition was evicted, the app routes into re-enrollment instead of presenting a silent empty vault as truth.

The service worker stays app-level, and in-pwa deliberately ships no service-worker runtime — only a recipe you copy and version yourself, because a worker that cached vault responses would create a second, unmanaged copy of ciphertext outside the store contract.

Opening the same app from LINE is a related but separate shell: see in-liff, including why storage never travels between the two.

Proven by: storage showcase 03 (browser-idb), the framework binding showcases (37–49), and the multi-tab coordination transport by-tabs.

Can I build a native iOS or Android app with noy-db?

Via a WebView wrapper: expected to work, not yet covered by the test suite. Capacitor-style apps embed a real browser engine (WKWebView / Android WebView), which provides the same Web Crypto and IndexedDB the PWA path uses — so the runtime contract is satisfied. It is labeled expected rather than proven because no showcase currently runs inside a wrapper shell; verify in your target WebView before committing to it.

React Native / Expo: not supported today. This is a plain gap, not a caveat: RN's JS engines don't ship crypto.subtle or IndexedDB, no to-* store targets React Native storage, and nothing in the hub or the showcase suite exercises RN. Making it work would take two parts — a Web Crypto implementation backed by native crypto, and an RN storage adapter written against the published @noy-db/hub/to store contract (the same seam all seventeen extended stores bind). If this path matters to you, say so on the issue tracker — it's the kind of gap that gets prioritized by demand.

Fully native apps (Swift/Kotlin, no JS runtime) are out of scope: noy-db is a TypeScript library, not a portable core with FFI bindings.

See also