Sentry-dart: Support for `--obfuscate` and `--split-debug-info` for iOS apps

[bruno-garcia]

This issue is to track the support for --obfuscate and --split-debug-info on iOS apps.

The original request was done on the flutter/flutter issue tracker and since then, Android support was added to Sentry.

For this to happen, Sentry expect symbols on iOS to be in a 'standard' format for that platform. Namely Mach-O files.
The request for the Dart team for this support is tracked here.

Support for desktop is tracked separately, here.

[t-kozak]

Hi Folks from Sentry and Dart teams,

This problem is in a bit of a hot potato state...

The Sentry team:

"expects symbols on iOS to be in a 'standard' format for that platform. Namely Mach-O files."

while the Dart team:

We are not actively working on this at the moment, because high priority uses cases are all covered to the best of our knowledge.

I want to obfuscate my flutter code in release build, and I definitely want to see error stack trace

You can still manually symbolicate and deobfuscate your crashes, we emit enough information for you to do it.

It is fair to assume that due to this state, the problem will not be resolved anytime soon, unless some team opens up for a compromise.

Since the debugging symbols produced for iOS are compatible with the Linux binary format (assuming I understood the various conversations correctly), would it be possible for Sentry to allow us to mark given crash as coming from Flutter, and de-symbolicate reports like these using the android toolchain, regardless of platform (iOS or Android)?

Alternatively, if I'm understanding this wrong, would you reconsider using the __flutter symbolise__ tool in the interim? Or adding a webhook or something that allows us to integrate with any pre- or post- processing flow?

All in all, it's getting difficult to treat flutter as a platform for "large scale", not-a-proof-of-concept products. You cannot expect developers to manually de-symbolicate every crash - it scales terribly. Also, due to the size of the runtime, removal of debugging symbols and obfuscation is really a must rather than nice to have.

Thanks,
Ted

[bruno-garcia]

@jan-auer can we shell out to flutter symbolize?
This is gradually building up to be a big blocker.

[mraleph]

I followed up on dart-lang/sdk#43612

tldr; is that Flutter CLI can be changed to produce necessary dSYMs. No changes in Dart compilation toolchain are required. I have provided the prototype of necessary changes - just looking for somebody to take it over the finishing line, which means clean it up, fix flutter symbolize (which requires contributing some refactoring to package native_stack_traces), add tests per Flutter contribution guidelines, get PR reviewed and landed).

[marandaneto]

@mraleph thanks a lot for your feedback and prototype, we'll take a look into it.

[fzyzcjy]

Hi, is there any updates? This is quite important and commonly used! Thanks!