Crash log and symbolication when using Xcode Cloud

The key thing to do is make sure to download the archive builds for any version that you distribute, either through the App Store, or if you distribute through other means for testing or enterprise workflows. That way, you have the dSYM files locally — Xcode Cloud stores your archives for 30 days. Download and archive build artifacts covers these details.

— Ed Ford,  DTS Engineer

But what if I don't download the archive builds from Xcode Cloud and don't have them locally? Does that mean that I won't be able to symbolicate crash? I thought the crashes would be symbolicated in the cloud. It's not the case?

When you submit your app to the App Store, there's an option for you to include symbol information as part of the app for that upload. When you do so, crash reports that appear in your Xcode Organizer for that app version will be symbolicated for you already. That's a feature of the App Store, and not specific to builds created and uploaded through Xcode Cloud.

However, that doesn't mean you shouldn't download the archives from Xcode Cloud, that is still a best practice. One valuable part of that is access to the dSYMs, which are incredibly detailed debugging assets. While using the dSYMs for symbolication is one function they serve, they also enable significant debugging capabilities using LLDB that aren't possible without them. The symbol information for symbolication submitted to the App Store is just the symbol information, but not the rest of the information inside the dSYM that make them so important, and is one of the reasons that make downloading the Xcode archive from Xcode Cloud a best practice.

— Ed Ford,  DTS Engineer

Thank you @DTS Engineer. These are great details!

I've follow-up questions to be sure using Xcode Cloud doesn't turn out in being a mistake.

1. If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago.

2. Can you elaborate on the "significant debugging capabilities using LLDB that aren't possible without them". What does that mean?

Basically, what I want is to be able to see the crash logs in Xcode Organizer, and open them in Xcode Project at the commit I used to archive the app to see what caused the crash and to fix it.

I hope it's clear.

Thank you, Axel

If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago.

This is where you should treat Xcode Cloud as separate from what happens after you submit a build to App Store Connect. Xcode Cloud can do an archive your app, and then additionally submit that build to the App Store according to options you configure. You could do both of those at your desk as well, with the same options. So if you ask Xcode Cloud to upload your build to the App Store with symbols, you'll get automatically symbolicated crash reports in Xcode Organizer, the same way as if you submitted the build to the App Store by archiving at desk in Xcode and submitting from your desk, with the option to include symbols enabled.

After this point of submitting to the App Store, you're then in the world of supporting services the App Store infrastrucutre offers you, not related to Xcode Cloud. So for automatic crash symbolication as sent to your Xcode Organizer, which is part of what you get from the App Store side of things, the 30 day retention policy for the Xcode Archive does not dictate anything about the length of time from where you receive crash reports already symbolicated from the field.

Does that help clarify for you?

Can you elaborate on the "significant debugging capabilities using LLDB that aren't possible without them". What does that mean?

Let me give you a real example from my role as a DTS Engineer, working with someone like yourself. The developer had a very peculiar crash from their app, and they correctly suspected they were looking at a bug that was in Apple's code, but they weren't sure because of the peculiar nature of the crash. I asked them for the archive of their app with their dSYM, plus this developer had done other great diligence on the crash to give me some other context. With the copy of their dSYM file from the Xcode archive (i.e. I do not have their real source code) and also the app both loaded into LLDB, I was able to use LLDB to jump through the assembly instructions surrounding the crash and prove out their assumption for the circumstances of the bug (and then give them a workaround too). Because the contents of the dSYM are detailed, but not source code level, I was able to use the additional context they gave me and their crash report to locate the relevant functions in the dSYM, trace their code, and even tell them the line numbers in their own source code that were involved in setting up the conditions for triggering the bug, all without their actual source code. If I didn't have that dSYM file, we wouldn't have been able to precisely locate the bug to get a targeted workaround beyond source code level trial and error guesses.

While the above is an extreme example and is more of the dark arts level of debugging than most people need to work at, I chose it to give you an idea of what is possible, and thus the value of saving the Xcode archive from Xcode Cloud in order to keep the dSYM around. There are many other less extreme debugging tasks you could do with the combination of the dSYM and your own source code for issues in the released version of your app beyond just crash report symbolication. It's better to have the dSYM file than to not.

— Ed Ford,  DTS Engineer