Decode Swift type names

[lhunath]

Problem Statement

Our error reports are full of mentions such as:

EXC_BAD_ACCESS _TtCVV8HubstaffP33_25DEF6E1EA93D46FE809017E6DD99DCF21NavigatingStackScreen30NavigationBarConfigurationView14ViewController

This is very user-unfriendly and there is no reason to leave obfuscated type names in public-facing titles like this. It would be great if Sentry could decode these type names into something more user-friendly.

Solution Brainstorm

Here's some code to kick-start you on this journey:
https://gitlab.com/spectre.app/ios/-/blob/main/Sources/Util/Describe.swift#L34

[getsentry-release]

Routing to @getsentry/team-mobile for triage. ⏲️

[brustolin]

Hello @lhunath. We are aware of this and are working to resolve it.

[bruno-garcia]

So far Sentry only does demanging on the server through symbolic. @brustolin is exploring a way to demangle client side but we're afraid that might bloat the SDK, unsure at this point.

[armcknight]

What is the rationale to do this client side vs server side?

[lhunath]

do you need access to the runtime for reflection? I wouldn't expect so.

[brustolin]

What is the rationale to do this client side vs server side?

Flexibility. We don't need to wait for a server side update every time we use a class name in a description or extra information.

Local log during debug.

And @bruno-garcia mentioned something about this being necessary for Dynamic Sampling.

do you need access to the runtime for reflection? I wouldn't expect so.

Nope. The mangled name has a logic, we just need to parse it.

You can follow all the findings in this PR #2033

[kevinrenskers]

This was done in #2162, which is part of the upcoming 8.0.0 release. You can test the beta version of this release already.