Using Crashlytics without dSYM in Xcode 14

Question

My project has been using Firebase's Crashlytics for years now, and I've always upload the dSYM files from App Store Connect to Firebase. However, in Xcode 14 Apple has removed the ability to submit apps with Bitcode enabled, meaning dSYM files are not downloadable from App Store Connect.

I uploaded a new version to App Store from Xcode 14 and now I can't upload dSYM files to see any crashes happening in the app. Crashlytics still even has a dSYMs section to upload those files, but there's nothing I can upload

Has anyone found a way around this? Automatic uploading of crashes never really worked for me before without uploading dSYM files, and only shows non-fatal crashes I manually log using Crashlytics.crashlytics().record(error: error) method.

What I've tried:

• I've gone over the Crashlytics setup instructions multiple times and it call seems to be the same before Xcode change.
• Spent days searching on the inte.net but can't find anything that fits this
• Uploading "myapp.app.dSYM" and every other.dSYM file that's from inside the "Package Contents" of each archive (using drag-and-drop into Firebase and the script)

Setup: I've attached an image of my Crashlytics script (from Crashlytics tutorial). I use Cocoapods to install Crashlytics like:

platform :ios, '14.0'

target `My App` do
   use_frameworks!
   pod 'FirebaseCrashlytics'
   pod 'Firebase/AnalyticsWithoutAdIdSupport'
end

Thank you in advance! I've been struggling with this for a while now and hope this can help someone else too!

Answer 1

My team ran into the same issue, with Apples deprecation of bitcode for app builds, we suddenly had no option to download debugging symbols for the build we just released. Over the next couple of days unresolved events started to accumulate and we were worried that we would just have to live with that, but fortunately we found a workaround!

The build script you mentioned in your question is supposed to resolve the symbols generated during the build process and upload them to Firebase. In our experience that works mediocre at best because we always had to upload the symbols manually, but we figured we could use the same script to upload the dSYMs after the fact.

To run the script use the Terminal. In the following example it is assumed that you are at the root of your iOS project:

./Pods/FirebaseCrashlytics/upload-symbols -gsp PATH/TO/GoogleService-Info.plist -p ios PATH/TO/DSYMS_DIR

In our case the final command looked something like this:

./Pods/FirebaseCrashlytics/upload-symbols -gsp GoogleService-Info.plist -p ios ~/Library/Developer/Xcode/Archives/2022-09-30/myapp.xcarchive/dSYMs

For this approach to work it is important to run the script with the dSYMs generated on the machine that uploaded the build to AppStoreConnect, we couldn't get it to work at first because we were rebuilding on a different machine and using the new generated symbols.

Answer 2

An Apple rep weighed in on this recently .

Presumably now local dSYMs should symbolicate properly when uploading them to Firebase Crashlytics directly, rather than first downloading them from App Store Connect (which seems impossible now).

If you're using Fastlane, the gym command exports an environment variable called DSYM_OUTPUT_PATH , which you can use to direct the upload-symbols tool to in your Fastfile :

upload_symbols_to_crashlytics(dsym_path: ENV["DSYM_OUTPUT_PATH"])
clean_build_artifacts

Of course you need to set the rest of the variables for the upload command. If I run into issues I'll edit my answer.

Answer 3

I faced the same issue in Xcode 14 and when I press Download Debug Symbols I have next error No dSYMs were found but when you press (right click) on your archive -> Show In Finder -> Show Package Contents -> there still is dSYMs folder with all dSYMs files that you can upload in to crashlytics.

Screenshot of dSYMs folder in Xcode 14

Answer 4

I've opted to develop and test with XCode 14 and then to compile and upload with the previous version of XCode (13.4.1). This requires me to do another smoke test cycle to ensure nothing I did with v14 fails to compile/work but I continue to get dsym files from App Store Connect. I am not a fan of XCode 14 - at all.

Not sure how much longer this will work though and don't know what the ramifications are of doing this.

Answer 5

Since Xcode 14, Bitcode isn't supposed to be used anymore. Many teams including mine were using Fastlane or any other CI to upload dSYM once it is available to download from the AppStoreConnect. But, this is not the way how it should be done anymore. Now, if you have Bitcode disabled, dSYM is generated just once after the build so its correct to use Firebase' script to upload it during the build phase and don't do anything else .

So what I suggest is:

1. Keep Bitcode disabled on Xcode 14
2. Remove all logic connected to generating/uploading dSYM
3. Add the logic to automatically upload dSYM during xcodebuild as described in Firebase Documentation
4. Don't do anything else and test it by manually triggering the crash

Some other suggestions (things to keep in mind):

• Use SPM, documentation is well written for it

• If you are using Fastlane's build_app action with custom cloned_source_packages_path don't forget to set the path for running the Crashlytics upload script correctly

  eg cloned_source_packages_path: "SourcePackages" along with using xcworkspace will be eg "$SRCROOT/../SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run" or "$SRCROOT/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run" if you are not using xcworkspace

My setup of script (I'm using cloned_source_packages_path: "SourcePackages" and xcworkspace since I still have some of the dependencies from Cocoapods):

Answer 6

We've got the same - after xcode14 (and bitcode disabled) there is no uuid'ed dSYM inside archived folder so fabric have no items to upload.

We tried to upload one large dsym AppName.app.dSYM and farbric was able to process our latest crashlog.