u/StillName1654

iOS: writing to local SQLite from a killed-state push notification — is there any way around the JS/native split?

>We have a React Native chat app. All our SQLite reads/writes live in JS (OP-SQLite), driven by a WebSocket sync pipeline (connect → request cursor-based sync → server replays missed messages → write to DB).

On Android, this works great even when the app is killed: setBackgroundMessageHandler boots Headless JS, which can call our normal JS sync code directly, write the message, and exit. Message is in the DB before the user ever taps the notification.

On iOS we're stuck. As far as I can tell:

  • UNNotificationServiceExtension (the killed-state hook) runs as a separate native process and can't call into our JS/Hermes engine at all — no bridge, no way to run our existing sync code there.
  • Silent push (content-available: 1can wake JS, but only if the app is backgrounded, not force-quit — and Apple caps delivery at roughly 2-3/hour/device, which won't keep up with an active chat.
  • We looked at how Signal-iOS does it (their NSE decrypts + writes to their shared GRDB database directly, in Swift) — but that means reimplementing our socket client and insert logic as a second, separate Swift codebase writing into the same SQLite file as our JS code. Feels like a real "two sources of truth" risk, and we couldn't find any RN app doing this in the wild.
reddit.com
u/StillName1654 — 21 hours ago