We use HockeyApp to distribute our iOS and Android builds. When we deploy a new version via HockeyApp, we upload the .ipa and .apk files, respectively, alongside the .dSYM.zip file for iOS builds. When viewing exceptions or any code that issues a Debug.LogError statement generated in development builds (with these BuildOptions:
BuildOptions.Development | BuildOptions.AllowDebugging | BuildOptions.StrictMode | BuildOptions.CompressWithLz4), we get stack traces in both HockeyApp and Unity Services’ Performance tab. There still aren’t any line numbers, but beggars can’t be choosers.
However, when we deploy a production build, we lose out on those stack traces. Is this by design? Our production builds are built with simply
BuildOptions.StrictMode | BuildOptions.CompressWithLz4, and are then uploaded directly to Apple for submission, but we still upload both the production .ipa and the .dSYM.zip files to HockeyApp for the express purpose of capturing exceptions. We build both our development and production builds using “Slow and Safe” script optimization.
Without the stack trace, it’s pretty tricky to figure out where an exception is occurring, but this is crucial information in production builds, as I’m sure we can agree.
This issue has plagued us for as long as IL2CPP has been around, but I could’ve sworn I’d seen a note about it being fixed in 5.6 or 2017.1. We just switched our Android build to IL2CPP from Mono2x, so while I used to be able to reasonably rely on the stack traces we’d see in HockeyApp/Unity Services for the Android build up until this point, we might lose out on them entirely from now on.
Am I missing something simple here?