Crash reporting

Crash reporting is on by default — the payload is data the SDK already holds (the exception plus the breadcrumb trail), fully redacted. It is a client veto:

<EverframeProvider config={{ apiKey: 'evf_live_…', crashReporting: { disabled: true } }}>

What is caught

There is no unhandled-rejection handler. A promise rejection nobody handles does not become a report on this SDK; only ErrorUtils is installed on the JS side, and it always reports errorutils.

What happens next depends on whether the process survives. A non-fatal error leaves your app running, so the report uploads immediately. A fatal one — a native crash, or a JS error React Native treats as fatal — kills the process, so the report is written to the outbox and sent on the next launch.

Non-fatal errors are throttled per session, so a render loop does not flood you with reports. Fatal errors always report.

Report a caught exception

Use the hook inside a component, or import captureException from @everframe/react-native outside React:

import { useEverframe } from '@everframe/react-native';

const { captureException } = useEverframe();

try {
  await saveCart();
} catch (error) {
  captureException(error, {
    severity: 'warning',
    context: 'checkout.save-cart',
    metadata: { attempt: 2 },
  });
}

The current source signature is captureException(error: unknown, options?: CaptureExceptionOptions): void. It records handled: true, fatal: false, and mechanism captureException without opening the reporter. Options use the shared info / warning / error severity, short context, and bounded redacted metadata contract. Capture is best effort and returning does not confirm storage or delivery.

This API requires matching JavaScript, generated bridge, and native SDK components. A JS-only update cannot add a missing native method, and previously published SDK versions may expose an older surface. Check the installed package declarations and rebuild the host app when adopting it.

occurredAt vs submittedAt

They differ, and for native crashes they can differ by a lot. Order your triage on occurredAt, not submittedAt, or a crash loop looks like it all happened at once when the user finally reopened the app.

What arrives

{
  "exceptionType": "TypeError",
  "message": "cart.lines is undefined",
  "frames": [
    { "raw": "at Cart (cart.tsx:42:11)" }
  ],
  "mechanism": "errorutils",
  "handled": false,
  "occurredAt": "2026-06-15T11:59:58.400Z",
  "fingerprint": "9f2c1ab30d84e177"
}

The envelope keeps each Raw stack line. For Hermes releases, configure the exact jsBundle identity and upload the final bytecode plus final composed map through the private source-map workflow. When processing succeeds, the error detail opens in Mapped mode; Raw remains available. Intermediate Metro maps cannot translate final Hermes bytecode offsets.

mechanism is a plain string, not an enum, so v2 can add values without older receivers rejecting reports.

Grouping

fingerprint is 16 hex characters computed on the client from the exception type and the top frames — a heuristic, deliberately, so grouping works with no server round-trip and no symbolication step. Treat it as a strong hint, not an identity.

What comes with it

An unattended report’s title is generated from the exception — TypeError: cart.lines is undefined — and its description is empty, since nobody typed one. What makes it useful is everything else: the breadcrumb trail leading to the throw, the console state, the screen the user was on, and the device and app context. There is no screenshot and no replay — the process may already be gone, and the payload is built from the buffers only.

The JS trail survives a fatal error because breadcrumbs live in the native buffer rather than in your JS context — see Breadcrumbs.

Hermes mapping applies to JavaScript frames only. This workflow does not add Apple dSYM processing, Android NDK/ELF processing, or an automatic native iOS crash collector.