Search results for

dsym file

75,477 results found

Post

Replies

Boosts

Views

Activity

Reply to Upload Symbols Failed on Xcode 16
Steps to Resolve the Issue Here are some steps you can take to ensure that your dSYM files are included in your archive: 1. Check Build Settings: • Go to your project settings in Xcode. • Select the target for your app. • Navigate to the Build Settings tab. • Search for Debug Information Format and ensure it is set to DWARF with dSYM File for both Debug and Release configurations. 2. Clean the Build Folder:
Topic: Developer Tools & Services SubTopic: Xcode Tags:
Sep ’24
iOS static library debugging symbols not included in the app's dSYM file when archiving
Problem description: I have an Xcode workspace that references two Xcode projects. The first Xcode project (lib.xcodeproj) builds an iOS static library while the second project (app.xcodeproj) builds an iOS app that consumes the static library. app.xcodeproj references lib.xcodeproj, i.e. lib.xcodeproj is listed in app.xcodeprojs Link Binary With Libraries build phase. So, the setup is as follows: MyApp.xcworkspace t| t+-app.xcodeproj---+ t|tttttttt | Referenced via build phase t+-lib.xcodeproj <-+ If I open this workspace in Xcode and build an archive out of it (Productmenu -> Archive) everything compiles as expected and I end up with an .xcarchive. The same applies if I build via command line (xcodebuild archive -workspace MyApp.xcworkspace ...). However, dumping the content of the dSYM file that is generated as part of the archive reveals that it does not contain the debugging symbols of the static library (lib.xcodeproj). To be more specific, executing the command dwarfdump MyApp.xcarchived
Topic: Developer Tools & Services SubTopic: Xcode Tags:
1
0
5.3k
Oct ’20
Reply to XCode Slow After Big Sur update
Hello Folks, I find the problem. Interestingly when I check the compiling tab I found out dSYM files were taking too much time, it was 0.7 seconds on Catalina, but it takes 90 seconds in Big Sur. Then I changed Debug Information Format from DWARF with dSYM File to just DWARF and now build times are as used to be. I hope it solves your problem
Topic: Developer Tools & Services SubTopic: Xcode Tags:
Mar ’21
xcodebuild -create-xcframework copies dSym file to different folder
I have following framework binaries: Device.framework Device.dSYM Simulator_x86.framework Simulator_arm.framework I first create a fat binary from the 2 simulator files: lipo -create -output /Output/Simulator /Simulator/Simulator_x86.framework /Simulator/Simulator_arm.framework Then I use xcodebuild to create xcframework like this: xcodebuild -create-xcframework -framework /Input/Device.framework -debug-symbols /Input/Device.dSYM -framework /Output/Simulator -output Release/App.xcframework In the resultant xcframework, some time the dSYM directory gets copied to ios-arm64 directory and sometimes to ios-arm64_x86_64-simulator which clearly seems to be some bug.
Topic: Developer Tools & Services SubTopic: Xcode Tags:
0
0
534
Jan ’23
Reply to XCode 16.0 does not symbolicate crash log
[quote='767309021, baraupp, /thread/767309, /profile/baraupp'] Because the image is not available, I cannot symbolicate the crashlog from the commandline using atos either. [/quote] Do you have the dSYM file? If you're not sure, consult the document you cited to determine if you have the dSYM file on your system or not, since that's required to symbolicate the crash report. —Ed Ford,  DTS Engineer
Topic: Developer Tools & Services SubTopic: Xcode Tags:
Oct ’24
Reply to Instruments Time Profiler macCatalyst app / assembler?
If Instruments is showing memory addresses instead of function names in the call tree view, it usually means Instruments can't find the dSYM file that contains the debugging symbols that are needed to show function names in Instruments. Choose File > Symbols in Instruments and you should see a button to locate the dSYM file. You can get more detailed information in the Troubleshooting section at the end of the article at the following URL:swiftdevjournal.com/measuring-your-apps-memory-usage-with-instruments/
Topic: Developer Tools & Services SubTopic: Instruments Tags:
Jan ’20
Reply to App Crash only on App Review
I have Realm source code but I am not sure how to proceed further. OK, let’s see if we can fix that. Looking at your crash report excerpt I see this: 2 Realm … RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1776 3 Realm … RLMAddObjectToRealm + 264 4 RealmSwift … Realm.add(_:update:) + 279776 … That means that somewhere in the Binary Images section of the crash report there must be Realm and RealSwift binaries. Each of those will have an associated UUID. To symbolicate your crash report you need to find the .dSYM files whose UUID matches those UUIDs. If you built those binaries from source code, the build process should have creating corresponding .dSYM files. If it didn’t, you need to adjust your build settings so that it does. If you use binaries built by someone else, you’ll need to get the .dSYM files from them. You can check you have the right files by matching up UUID, as discussed in Adding Identifiable Symbol Names to a Cra
Topic: Developer Tools & Services SubTopic: Xcode Tags:
Jul ’22