Skip to content
Everframe Docs
Documentation

Crash reporting

Caught errors can be reported explicitly. Native iOS still has no automatic crash collector or dSYM processing.

Updated

The iOS SDK does not file unattended native crash reports today. You can report an error you catch in application code, but fatal native failures still need your existing crash reporter.

Report a caught error

The current source tree exposes a synchronous, nonthrowing handled-error API:

import EverframeKit

do {
    try saveCart()
} catch {
    Everframe.shared.captureException(
        error,
        options: CaptureExceptionOptions(
            severity: .warning,
            context: "checkout.save-cart",
            metadata: ["attempt": 2]
        )
    )
}

The one-argument captureException(error) form defaults to error severity. Both forms record handled: true, fatal: false, and mechanism captureException without opening the reporter. The SDK takes a bounded, redacted snapshot, writes to its encrypted outbox on a best-effort basis, and returns before delivery is confirmed. capture.crash: false suppresses this explicit path.

Frames describe Thread.callStackSymbols at the capture call, not necessarily the original Swift throw site. This API does not symbolicate dSYMs or make signals, runtime traps, memory faults, failed preconditions, or Objective-C exceptions catchable.

The options overload is source-branch API. Previously published SDK versions may expose an older surface; coordinate the iOS SDK version before adopting it.

What happens on an uncaught exception

At start() the SDK installs an NSUncaughtExceptionHandler. When an Objective-C exception goes uncaught it:

  1. Records an error breadcrumb — the exception reason as message, with data.name and a data.stackDigest of the top frames.
  2. Calls whatever exception handler was installed before Everframe, so a crash reporter you already ship receives the exception exactly as it did before.

It never blocks or replaces the previous handler, and it never throws. Because the process ends immediately afterwards, that crumb lives in memory only; it is not written to the outbox and does not surface as a report of its own.

Swift runtime traps, signals (SIGSEGV, SIGABRT, SIGBUS), watchdog terminations and out-of-memory kills are not seen at all — an exception handler cannot observe them.

capture.crash

CaptureConfig.crash defaults to true. On a native host, setting it to false suppresses captureException; it still does not add or remove an automatic native crash collector. The React Native bridge also uses this gate for its JavaScript crash path.

// Turns off explicit handled-error capture. Native fatal crashes are not collected either way.
EverframeConfig(appId: "evf_live_…", capture: CaptureConfig(crash: false))

What to do for fatal crashes

Keep your existing crash reporter. If a crash is visible in Xcode Organizer but not in Everframe, that is expected — Everframe carries reports users file and handled errors your code explicitly captures, with the breadcrumb trail, console, network and replay available to those report paths.

Automatic reports from uncaught errors are available on Android and React Native.