Flutter

The planned Flutter package will capture errors from Flutter apps on iOS, Android and macOS, and is the only TracePath SDK planned to record video of the screen leading up to a crash.

What it will capture

Wrapping your app at startup installs the handlers for:

• Flutter framework errors: rendering, layout and gesture errors
• Platform errors: native platform channel failures
• Uncaught async errors: unhandled exceptions in asynchronous code, captured through Dart's zone mechanism

Explicit capture calls will cover caught exceptions with their stack traces, and custom messages.

Screen recording

With screen capture enabled, the SDK wraps the app in a repaint boundary and captures frames at roughly 15 fps. On an exception, the last ~10 seconds are encoded to MP4 and sent alongside the error report, and the recording appears in the dashboard next to the stack trace. Touch positions are drawn onto the captured frames — those overlays exist only in the recording, never in the live app.

Frame rate, resolution scale and buffer length are all configurable, because the defaults are a compromise between fidelity and the memory a rolling video buffer costs on a phone.

Privacy masking

A masking widget will let you wrap any subtree whose content must not reach the recording, in two modes: blur, which pixelates the region at an intensity you choose, and blank, which replaces it with a solid colour. Masking applies to the recorded frames only; the user sees no change in the live app.

Plan the masking before you plan the recording. Card numbers, names, addresses and anything else you treat as regulated data need a wrapper, and it is much easier to add while you are building the screen than to retrofit after recordings exist.

Logs and actions

Each captured exception will ship with the last ~10 seconds of session context: two independent rolling buffers, logs and actions, each capped at 200 entries by default, attached to the same session recording that carries the video.

Logs mirror print and debugPrint through a zone print override. dart:developer.log does not flow through that hook and is not captured.

Actions come from three sources:

• Network — every dart:io HTTP request, via an HttpOverrides install, which catches package:http, Dio, Firebase and anything else sitting on the dart:io HTTP client on native platforms. Flutter web has no HttpOverrides, so a wrapper client is planned for that case.
• Navigation — push, pop, replace and remove transitions, recorded by a navigator observer you add to your app's navigatorObservers.
• Custom — anything your app records explicitly, with a category, a name and a data map.

Each channel can be turned off individually.

Symbolication for obfuscated builds

A plain release build keeps readable stack traces, so there is nothing to do. A build hardened with --obfuscate and --split-debug-info does not: traces arrive as bare instruction offsets, and resolving them needs the build's .symbols files uploaded to TracePath.

The upload endpoint already exists and takes plain multipart HTTP with an upload token, the same token used for JavaScript source maps — see Dart symbolication for the contract. What is missing is the client end: the uploader that ships with the package, and the SDK that produces the reports those symbols would resolve.

Planned platform support

Flutter web is out of scope for this package; it is the browser JS SDK's territory, which is not published yet either.

What to do today

The backend your app talks to can be instrumented now with OpenTelemetry — a failing screen is usually a failing endpoint, and the endpoint side is fully supported. Synthetic monitors can watch your API from the outside with no code at all.