What is the proper "Strip Debug Symbols" settings in iOS for release versions?

Question

I've been getting a bunch of crash logs for my (largely c++) app on iOS. My problem is I can't seem to ever symbolicate these crash reports properly.

What is the "proper" setting for stripping debug symbols for release on iOS? I get that you'd want to strip the debug symbols so the download size of the app isn't ridiculously large.

But the problem is that it seems to make the crash reports virtually unreadable.

Do dSYM files on the xcode archives get sent and eventually downloaded by the users?

Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on xcode)?

Bushel

You could possibly try using a framework like Crashlytics perhaps. – Dozier

It's a third party keyboard, which doesn't get internet access at all. Furthermore it just refuses to open at all, so besides the crash report I can't seem to get any other info out of things – Bushel

Answer 1

Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on Xcode)?

This. Your "release" config (or whichever config you use for distribution) should have the following setting:

Symbols Hidden by Default: Yes

Xcode will still generate a dSYM folder which is what you will use for symbolicating crash logs. There are 3 ways to handle symbolicating:

1. Use Xcode. For this you need to use the Product -> Archive feature whenever you release. Once an archive is created, you can select "Export" then "Save for iOS App Store Deployment". After this you can drag crash logs into the left side of the "Device Logs" window and Xcode will symbolicate them for you.

2. Manually symbolicate using the symbolicatecrash tool located inside your Xcode.app folder. This is useful if you've released code to users but don't have an Xcode archive. You need to be sure that the crash log matches the binary and dSYM or it will not work.

3. Use a third party tool that collects crash reports and symbolicates them for you. Examples include Crashlytics, Bugsense, or HockeyApp.

Hoekstra

Answer 2

For anything if you want to know its proper setting all you have to do is:

Recreate the same exact target type from scratch in Xcode. What I mean by that is, if you want to know the correct settings for an app, then recreate an app from scratch and then go and inspect its settings. If you want to know the default setting for a framework then recreate the dynamic framework from scratch and inspect its settings.

Note: The default settings for an app, vs a framework vs a static library vs other things is different. Also the default value for Release vs Debug is different.

Why is an app vs a framework different?

Because frameworks are dependencies and not the final product. This often means that the app needs different compilation, linkage, stripping setting from another dependency or the main app itself.

Why is Debug vs Release different?

With Debug, the goal is:

• To get the build out fast. This means:
• Don't build for other architectures.
• Don't create a separate dSYM.
• To be able to debug

With a Release build, the goal is:

• Build with most optimizations. Often this reduces speed
• Validate if the build works for other architectures (arm64 vs Intel). This means more time spent to build things.
• Extract out the dSYM (debug symbols) to save on space.
• Don't need to debug, rather just be able to symbolicate crash reports when needed.

Zoniazoning