Why Native Modules

Why we need native modules

The Mobore SDK ships small iOS and Android native components because some capabilities are not reliable or even possible from JavaScript alone. Native modules let us capture crashes, measure performance accurately, and deliver data in the background with strong reliability.

What native modules are used for

• Crash reporting: Capture hard crashes (Objective‑C/Swift exceptions, Unix signals, ANRs) and persist reports so they can be uploaded on next launch. JS error handlers cannot catch process‑level crashes.
• Network instrumentation: Instrument NSURLSession (iOS) and OkHttp/platform stacks (Android) to collect precise timings, status codes, redirects, and TLS/DNS timing. Some libraries bypass fetch, so JS‑only hooks would miss data.
• Device and app context: Fetch accurate device model, OS, app version/build, locale, memory, storage, battery, and carrier via native APIs to power filters and breakdowns.
• Connectivity signals: Listen for Wi‑Fi/cellular changes to annotate sessions and network spans.
• Background queue and offline caching: Persist spans and crash reports to disk and retry with backoff, even after app restarts.
• Lifecycle and performance signals: Observe app cold/warm starts, view/controller/activity lifecycles, frame drops, and UI/JS thread stalls where supported.

What is included

• @mobore/rum-react-native: The core bridge and instrumentation.
• Peer dependencies used by the SDK:
  • @react-native-community/netinfo (connectivity)
  • react-native-device-info (device/app metadata)

Platform specifics (high level):

• iOS: Crash handler, NSURLSession instrumentation, background delivery.
• Android: Crash handler, OkHttp/network instrumentation, frame timing hooks, background delivery.

Permissions and privacy

• No extra user permissions are required beyond standard network access.
• The SDK does not access contacts, photos, microphone, or location.
• Data is limited to telemetry needed for RUM/crash analytics as documented in Supported → Data captured.

Expo and bare React Native

• Expo (managed): Supported via config plugins. If you need native modules, run a prebuild to generate iOS/Android projects.
• Bare React Native: Install and build as usual (see Onboarding).

Configuration and opt‑out

You can disable any auto‑instrumentation while keeping the SDK for manual spans only. For example, in RumProvider or manual initialization you can toggle crash reporting, network, lifecycle, and device context collection.

If you remove peer modules like react-native-device-info or @react-native-community/netinfo, related features will be disabled or degraded.

Build notes

• iOS symbolication: Upload dSYMs when archiving to get human‑readable crash stack traces.
• Android NDK symbols (if applicable): Provide mapping/symbols for native crash decoding.

If you have constraints that prohibit native modules, you can run in a JS‑only mode, but crash reporting and certain reliability/performance features will be unavailable.