Feature request: de-obfuscate Flutter mobile Dart stack traces

Problem

Flutter mobile apps built with flutter build apk|appbundle|ios --release --obfuscate --split-debug-info=<dir> ship native ARM/ARM64/x64 machine code with obfuscated symbol tables. Every $exception event captured by posthog_flutter arrives with stack frames that look like:

#0 abs 0000007baea24207 _kDartIsolateSnapshotInstructions+0x4768c7
PostHog/posthog#1 abs 0000007baec025f7 _kDartIsolateSnapshotInstructions+0x654cb7

These can be decoded by flutter symbolize -d <arch.symbols> -i stack.txt, but PostHog has no way to ingest the .symbols files, so the UI shows the raw obfuscated trace making PostHog error tracking effectively unusable for any team that obfuscates its release builds (which is the standard recommendation for Flutter apps shipping to the App Store / Play Store).

This is acknowledged today as a "future feature" on the Flutter error tracking docs:

No de-obfuscating stacktraces from obfuscated builds (--obfuscate and --split-debug-info) for Dart code

What's being asked

Add Dart AOT symbol upload + decode support, parallel to the three formats PostHog already handles:

Concretely:

• posthog-cli sourcemap upload (or a new subcommand) accepts .symbols files for one or more of: app.android-arm.symbols, app.android-arm64.symbols, app.android-x64.symbols, app.ios-arm64.symbols.
• Server-side parser for the Dart .symbols binary format (the same format the Dart SDK ships with the flutter symbolize reference implementation).
• Stack-frame remapper that recognises _kDartIsolateSnapshotInstructions+0xN frames in incoming $exception events and substitutes the decoded Dart source location.

Workaround today

CI-archive the .symbols files as build artifacts and manually decode via flutter symbolize when investigating an error works, but is per-investigation friction (download artifact → match version → run CLI → paste back). Practical for low error volume; doesn't scale.

Why this matters

• It's the standard Flutter release-build hardening recommended by the official Flutter docs.
• The "future feature" framing on the docs page suggests the team is aware; this issue is mostly to register demand and provide a concrete spec.
• Sentry and Firebase Crashlytics both support this for Flutter today it's important for teams choosing PostHog as their error tracker.

Timeline ask

Is this on the roadmap with a rough ETA? We're trying to decide whether to build a self-hosted decode pipeline as an interim workaround vs wait for upstream. A rough signal even "no concrete plans" would be enough to make the call.

Happy to test against a beta build of posthog-cli / posthog-flutter once available, and contribute end-to-end verification.

Start with the posthog-cli sourcemap upload entry point and compare the existing dart2js, Android mapping.txt, and iOS dSYM handling. Read Flutter's flutter symbolize reference implementation for the Dart AOT .symbols format, then verify upload, parsing, and remapping of _kDartIsolateSnapshotInstructions frames in $exception events.