35

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 internet 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

enter image description here

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

fphelp
  • 1,544
  • 1
  • 15
  • 34
  • Is Xcode generating dSYMs? Check this for reference: https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports?platform=ios#check-xcode – Gerardo Sep 29 '22 at 17:17
  • @Gerardo Yes Xcode is generating dSYMs on every Build, but they do not seem to be the same you used to be able to download from AppStoreConnect, at least they did not resolve all the missing dSYM warnings my team gets from Firebase since the update to Version 14. – timfraedrich Oct 04 '22 at 14:04
  • That is correct, as far as I know, with bitcode enabled Apple recompiles the app and generates a new UUID and dSYMs. That is why they are different from the Xcode generated. The solution you posted is the way to resolve this. – Gerardo Oct 04 '22 at 22:10

6 Answers6

8

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.

sacred0x01
  • 382
  • 2
  • 11
5

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

Kvyatkovsky
  • 61
  • 2
  • In my archive, I only see one big dSYM. I don't see dSYMs for all the pods used in my project. Any ideas why that's the case? – Spencer Müller Diniz Oct 20 '22 at 11:26
  • I tried to upload this dSYMs folder to Firebase Crashlytics, but there is no effect. Crashlytics still say to "missing dSYM files" for that build. – Pavel Volobuev Nov 10 '22 at 19:01
  • I would suggest making a zip file of the dSYMs folder (right-click, Compress ...) and upload that to Firebase Crashlytics. @Pavel – Eric Hedstrom Jan 09 '23 at 16:23
5

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.

timfraedrich
  • 331
  • 1
  • 3
  • 9
  • 2
    Hey! Thanks for the pointers. With Fastlane I was able to specify my build script to output the archive to the CI work folder, and then upload-symbols finds it there automatically – Adar Hefer Oct 09 '22 at 09:27
  • Do you know which archive to upload? Whenever I send a build to App Store Connect and view the archive in finder. There are always 2 builds per archive, usually a few minutes apart. – fphelp Oct 29 '22 at 22:37
5

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.

Adar Hefer
  • 1,514
  • 1
  • 12
  • 18
4

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

    e.g. cloned_source_packages_path: "SourcePackages" along with using xcworkspace will be e.g. "$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):

enter image description here

enter image description here

Robert Dresler
  • 10,580
  • 2
  • 22
  • 40
0

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.

danny
  • 9
  • 2