dsym file

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

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

I presumed this was due to lack of debug symbols The thing is, the info in Adding Identifiable Symbol Names to a Crash Report let’s you test that presumption: Get the code’s UUID from the Binary Images section of the log. Use dwarfdump to confirm that you have a .dSYM file with the right UUID. Use mdfind to confirm that it’s visible to the symbolicator. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

@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