How to run upload symbols to upload dSYMs as a part of Xcode build process?
Ok, so I'm trying to automatically upload dSYMs. I'm following instructions from this official documentation: https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports
I'm stuck at "Run the upload symbols script manually" section.
There are 3 ways to upload dSYMs. I'm trying to follow the first one - including the following line in your build process:
find ${DWARF_DSYM_FOLDER_PATH} -name "*.dSYM" | xargs -I \{\} ${PODS_ROOT}/Fabric/upload-symbols -gsp MyProjectFolder/GoogleService-Info.plist -p ios \{\}
For now I've tried the following:
- I go to Project->Scheme->Edit Scheme.
- I click on Build->Post actions
- I start small - I only want to show "echo" in build process:
- I run Product->Build
- I go to View->Navigators->Show Report Navigator
- There's not indication that echo was run.
Where to put this script?
How to find if it is being run or not?
Answer
TL;DR: dSYMS generated at build time has little value in the "bitcode enabled" era, you need to download dSYMs from Apple and upload them to your 3rd party crash reporter service as a post-build step after Apple has processed your upload.
Background
Symptom
Missing dSYMs / failed symbolication in 3rd party crash reporting console. I thought despite following Crashlytics install instructions the script was failing.
Bitcode - the fundamental issue
Turns out the 3rd party crash-reporting systems (like Crashlytics, or New Relic) have a fundamental problem with the current best practice for app distribution, which is bitcode-enabled apps. Historically these 3rd party crash report systems relied on build-time steps to upload build-time generated dSYMs. But since bitcode-enabling means the app store recompiles your apps, your build-time generated dSYMs, that you are trying to upload, are effectively useless.
As background, bitcode-enabled apps are "thinned" and thus re-compiled by Apple such that each device only gets the download bits it needs. You want to enable bitcode. It is a good thing. But, bitcode-enabled distribution messes up symbolication. No matter what dSYMs you generate at build time, the dSYMs won't actually correlate to crashes from App Store or TestFlight installed builds, as your crashes will be from App-store recompiled versions of your apps with new corresponding dSYMs.
So don't worry about the upload script working or not at build time. In fact, that step could be removed from your build process as it is just wasting your time and bandwidth.
The only case it might be useful is if you want to symbolicate crashes from locally-installed release versions instead of debugging them directly in Xcode.
Solutions
The solution is to wait "some time" (reportedly several minutes, via NewRelic documentation, in my experience a sleep of 120 seconds after fastlane upload but before I ran fastlane's download_dsyms action failed sometimes, a sleep of 300 seconds works reliably) after uploading your app (likely the duration of time the App Store says your build is "Processing"), then download the dSYMs from there and use your 3rd party crash reporters command-line upload script
Manual download / upload
The current recommended solutions from the 3rd party crash reporters (both NewRelic and Crashlytics documentation at least) is to either go to the App Store Connect page for the build and download dSYMs then upload, or using XCode's Organizer for the archive hit the "Download Debug Symbols" button, then upload them.
This does work, with manual dSYM downloads pushed out to your crash reporting vendor you will get symbolicated reports. It is a manual process though using either the Xcode GUI or the App Store Connect interface.
Fastlane automation
You may automate the process with Fastlane though, which is I believe the proper solution.
https://docs.fastlane.tools/actions/download_dsyms/#download_dsyms
https://docs.fastlane.tools/actions/upload_symbols_to_crashlytics/