dsym file

Out of curiosity: Why would you like to do it? I'm wondering if maybe there's something else that imposes a problem for you. I build dev tooling for iOS applications in the CI pipeline. The apps we test do not always have symbol information available, so we build the tools to symbolicate the crash reports. To test our tooling we need to be able to generate crash reports without symbols. The process we use: Create a crash report without symbol information First, make sure to build the binary without symbol information by setting DEPLOYMENT_POSTPROCESSING=Yes in the Xcode build settings. Apple developer tooling is very eager to help you symbolicate crash reports. So helpful that it can be unclear how to create crash reports without symbol information. There are several options: Build without generating a dSYM file. Note that this only works when you did't build the same app (with the same binary uuid's) on that machine before. Build on another machine, download the .app but not the .dSYM Note

We're also running into an issue that appears to be related to Xcode 16.0, the primary issue is that Firebase Crashlytics has missing dSYMs. However, during dSYM upload / processing, it finds and successfully uploads a dSYM: In the Xcode 16.0 console I see the same message as mentioned above: warning: (arm64) /Users/user/Library/Developer/Xcode/DerivedData/SomeApp-dih...wzn/Build/Products/Debug-iphonesimulator/SomeApp.app/SomeApp empty dSYM file detected, dSYM was created with an executable with no debug info. I tried changing the build settings for our targets, directly in Xcode's build settings as well as using externalized configuration (.xcconfig). Enabled for debug and release: DEBUG_INFORMATION_FORMAT = dwarf-with-dsym DEBUG_INFORMATION_VERSION = compiler-default CLANG_DEBUG_INFORMATION_LEVEL = default For debug: COPY_PHASE_STRIP = NO For release: COPY_PHASE_STRIP = YES Snippet from the automated build log: 14:08:19 14:08:19 Platform: ios 14:08:19 14

@JohanBiometric, I've been away for a little bit, so I'm just catching up to your follow-up here now. One of the things that I see confusing the understanding of things here is that Middleman Framework has its MACH_O_TYPE build setting set to static. That's not invalid, but for the sake of discussion, let's have you configure everything as such: All framework code has MACH_O_TYPE set to Dynamic Library App target lists the frameworks as Embed & Sign in the General tab Middleman Framework target has reference to Camera framework described as Do Not Embed in the General tab. This configuration will result in the following file structure inside of the Xcode archive (abbreviated for clarity in this discussion): SampleApp3.xcarchive ├── dSYMs │ ├── CameraHandlingFramework.framework.dSYM │ ├── MiddlemanFramework.framework.dSYM │ └── SampleApp.app.dSYM └── Products └── Applications └── SampleApp.app ├── Frameworks │ ├── CameraHandlingFramework.framework │ └── MiddlemanFramework.framework ├── In

0 com.Mycmp.MyApp.MyAppAgent 0x00012a74 -[AppMainController sendPacketForLoginStatus] + 1644+1644 in the raw crash log is not a line number.It is offset from the nearest symbol CrashReported had found - most likely (but not always) the start of function which crashed.To actually map crash address to file name and line number, you do need to symbolicate it, provided you do have dSYM files (symbolic information) from the crashed build.consult man atos or TNs like https://developer.apple.com/library/ios/technotes/tn2151/_index.html for more details

A .app bundle is not an executable, it is a folder with a specific structure. The executable code is in the bundle's Contents/MacOS directory. You don't want to add anything to that. You could put the symbol file into the bundle you distribute to users, but there is really no reason to do so. It is just dead weight to users, it is only useful to you. If you really want to put it into the bundle, you could copy it to some location in the bundle before signing and notarization. You'd do this by adding a post-build script to the Build Phases of your target in Xcode. A more reasonable approach is to simply archive the .dSYM files for every release you make, and use the appropriate dSYM when you receive a crash log. You can symbolicate the crash logs by hand or using Xcode. See https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report

I do expect a binary inside the framework. The problem arises when someone else uses the framework in an app. Then, Xcode complains that there is a mismatched dSYM file, but our framework is a static framework and does not have a dSYM. (as you can see in the picture). This is how I generate each framework: xcodebuild clean build analyze -scheme Sentry -configuration Release -project Sentry.xcodeproj -sdk iphoneos MACH_O_TYPE=staticlib GCC_GENERATE_DEBUGGING_SYMBOLS=NO And then I use xcodebuild -create-xcframework to combine them. My main point is: something changed from Xcode 15 to 16 because this only happens in the 16. What changed and how to solve it? If you can take a look at the framework, I would really appreciate it: https://github.com/getsentry/sentry-cocoa/releases/tag/8.36.0 (Sentry.xcframework.zip is the static one)

Is my assumption incorrect that a debug version of the app when it crashes should have shown the information of code (class, function, line) ? Not universally; it very much depends on how your build is configured. However, if you have the .dSYM file that matches this crash report then should you be able to symbolicate it. Adding Identifiable Symbol Names to a Crash Report - https://developer.apple.com/documentation/xcode/diagnosing_issues_using_crash_reports_and_device_logs/adding_identifiable_symbol_names_to_a_crash_report has a bunch of info on this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I would suggest you try it yourself …That’s a bit hard to do given that I don’t receive crash reports from the App Review team (-:Seriously though, most symbolication problems are caused by the lack of the relevant .dSYM file, either because it’s out-and-out missing, or because Spotlight can’t find it. I posted about this recently. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Hi @DTS Engineer – Static frameworks containing privacy manifests need to be embedded, so that the privacy manifest resource is copied into the app bundle. When embedding a static framework, Xcode 15 is smart enough to strip out the static archive, replace it with an empty dylib, and copy in the resources. This explains why Paul was able to download the SDK as a static framework, but you saw the same SDK as a dylib within the app bundle. When Xcode 16 sees this Xcode-generated empty dylib, it looks for the corresponding dSYM file, but it's not there and emits the warning. I believe the fix is within Xcode– when Xcode detects a static framework is being embedded and generates the empty dylib, it also needs to generate an empty dSYM to go along with it.

Thanks Eskimo but this did not work for me even though I have the archive stored. Any tips to get this working so I can get my logs symbolicated?Xcode will automatically symbolicate all crash reports that it encounters, if it has the .dSYM and application binary that produced the crash report. Given a crash report, the matching binary, and its .dSYM file, all you need to do for symbolication is to add the crash report to the Xcode Organizer.Connect an iOS device to your MacChoose Devices from the Window menuUnder the DEVICES section in the left column, choose a deviceClick the View Device Logs button under the Device Information section on the right hand panelDrag your crash report onto the left column of the presented panelXcode will automatically symbolicate the crash report and display the results

With help from various sources, figured out a way:This is assuming Xcode 8.2.1 is installed as Xcode.appCreate a new folder on your desktop and call it symbolication
Put the .dsym files into the symbolication folderdownload the crash report(I used CustomerID.crash as the format of these files)In the terminal, type: cp /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash ~/desktop/symbolication/symbolicgtecrash cd ~/desktop/symbolication export DEVELOPER_DIR=/Applications/Xcode.app/Contents/DeveloperThen for each file to symbolicate, type: ./symbolicatecrash CustomerID.crash > CustomerID_symbolicated.crash(where CustomerID is the customer id used when saving the crash report)