Feature Request: React Native Offline Support
📌 Summary
We are actively using Openpanel in our mobile analytics workflow. While event tracking works seamlessly in online mode, there is currently no built-in offline support for React Native. In many mobile environments, users may temporarily lose connectivity (e.g., during travel, in rural areas, or when switching networks). This results in dropped events and incomplete analytics.
🚨 Problem
At present, Openpanel in React Native apps requires an active network connection to send events in real time. This creates issues in scenarios where:
- The user is offline when interacting with the app (events are lost).
- Mobile network switches cause brief disconnections during usage.
- Long-running sessions in offline environments (e.g., flights, underground transport) are not tracked.
- Events cannot be retroactively synchronized once connectivity returns.
This gap leads to incomplete datasets and reduced accuracy in user behavior analysis.
✅ Proposed Solution
Introduce offline event queueing for the React Native SDK:
-
Queue Storage
- Store events locally (e.g., in AsyncStorage or SQLite) when no internet connection is detected.
- Events should include all necessary metadata and timestamps.
-
Automatic Synchronization
- On reconnection, the SDK should automatically send queued events to the Openpanel server in chronological order.
- Include retry mechanisms and backoff strategies for failed transmissions.
-
Configurable Options
- Max queue size before discarding oldest events.
- Optional flush interval.
- Developer hooks for
onFlushandonQueueevents.
🔍 Key Benefits
- Data Completeness — Ensures no events are lost due to temporary disconnections.
- Improved Accuracy — Offline behavior is accurately reflected in analytics.
- Better User Experience — Tracking works without requiring constant network checks from the developer.
- Resilience — Handles unstable network conditions gracefully.
🔧 Suggested SDK Integration
-
Extend the React Native SDK with an
offlineQueue: true/falseconfiguration option. -
Expose public methods:
flushQueue()— manually trigger sending queued events.clearQueue()— clear stored events without sending.
Yes, this seems like a very good improvement for the RN SDK. At a glance it looks fairly simple but I think I need to improve ingestion for this.
Currently if you send old events (with a datetime from the past) we won't add it to any session and depending on when the events where made, the generated device id (our identifier) might have change.
So my worries for old events are:
- the device_id might have changed when they arrive (if no profile_id was provided), which mean these events would be attached to a "new" user.
- events with passed dates will not get any session_id (should be fairly simple thing to solve)