Apple recently demanded I upgrade my iPhone to the latest iOS version (11.2), and, as usual, Xcode then refused to connect to it unless I upgraded Xcode, which, of course, I could only do, if I upgraded my version of Mac OS.
So, after wasting half a day downloading and installing updates, I'm now on Xcode 9.2, and my code, which built beautifully before, fails to build with an error of:
ld: warning: directory not found for option '-F/Applications/Xcode.app/Contents/
Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.2.sdk/
Developer/Library/Frameworks'
(Note: I've added spaces in that folder path myself, to make it readable here.)
The error message is true though.
If I attempt to go into that folder, I can get as far as the iPhoneOS11.2.sdk folder, then there's no Developer sub-folder in it.
I have Googled this problem, and lots of people recommend checking your "Library Search Paths" and "Framework Search Path" settings... but in my case, both of these were blank. I didn't have any folders specified in my build settings.
Interestingly, in that screenshot above, I noticed that the System folder does have a Library\Frameworks subfolder so (out of desperation) I copied the System folder into a folder called Developer.
Ridiculously, this seems to have fixed the problem, but surely I'm missing something here...
Has anyone else had this problem, specifically since upgrading Xcode ?
After making this change to the folder structure, I did still have 1 other error. Xcode was now complaining that:
embedded dylibs/frameworks are only supported on iOS 8.0 and later
Again, this error hadn't appeared before I upgraded Xcode, but the fix was to change the iOS Deployment Target in my "Project" build settings and in each of the Target build settings.
What really bugs me about Xcode is that I don't want/need any of the new iOS 11 functionality. This is a legacy in-house app, which we've been using since iOS 7. This stuff should just build, after an Xcode update, but with each release, we get new problems, as obscure as the ones highlighted here.
This Xcode stuff is truly terrible... please can I go back to my warm-and-cosy Microsoft environment now...?
You can use your old Xcode to support 11.2
To support you need to run below command:
sudo ln -s PATH_OF_NEW_XCODE_DEVICESupport_TO_11.2 PATH_OF_EXISTING_XCODE_DEVICESupport
Example:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/11.0 /Applications/Xcode821.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
I am attempting to manually symbolicate a crash log since Xcode 7 will not do it for me. Yet, I come to this result:
What does this mean and what can I do with this? I have used atos as well and it just gives me the same address! I am sure I have the right dSYM, .app, and log as well.
Thanks!
When you see __hidden_ in crash log for function names, this means you enabled bitcode during ipa export from archive. In order to be able to symbolicate crash log you should use module map files from archive:
Here are the commands you need to run in terminal:
dsymutil --symbol-map PATH_TO_BCSYMBOLMAPS_DIR PATH_TO_DSYM
for all symbol map files.
After this command you can use atos command as you have tried:
dwarfdump --arch YOUR_ARCH myApp.dSYM --lookup YOUR_LOOKUP_ADDRESS
To symbolicate a crash log, you require XCArchive. Inside the xcarchive, we are interested in two things:
dSYM file: It contains the debug information for the binary. MyApp.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp
BCSymbolMap file: It contains the human readable names for symbols. MyApp.xcarchive /BCSymbolMaps/.bcsymbolmap
The archive may have multiple dSYM and BCSymbolMap files if it has frameworks. We have to identify the correct BCSymbolMap file for the binary. For this, we need to extract the build UUID of the build using the dwarfdump tool.
dwarfdump --uuid MyApp,xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp
output:
UUID: B63B409F-FA67-334C-BDC0-28AE2BFD488A (arm64) MyApp.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp
Resolve the obfuscated symbols in the dSYM file, using the dsymutil tool. Using the above symbol file:
dsymutil -symbol-map MyApp.xcarchive/MyApp.xcarchive/BCSymbolMaps/ B63B409F-FA67-334C-BDC0-28AE2BFD488A.bcsymbolmap MyApp.xcarchive/dSYMs/MyApp.app.dSYM
This command will symbolicate the dSYM file in-place. Now, if we open the crashlog in XCode, it will be able to resolve the symbols properly. Please note, XCode might need a minute to do this, so be patient. The symbols will appear automatically when it’s done.
If the crashlog was already opened in XCode before it was symbolicated, one might have to request re-symbolication from XCode. To do that, right-click on the crashlog in the device logs window and select Re-Smybolicate Log from the context menu.
A user emailed me a crash log for an app I submitted to the App Store. I have the original app store submission archive in Xcode still, but his crash report will not symbolicate. Clicking "resymbolicate" doesn't do anything. I can't find the symbolicatecrash script using mdfind, is it still a part of Xcode 4.5? Is there any way to symbolicate this crash log?
If you haven't already tried this, upgrade your mac to OSX 10.8.2 or newer. I was running OSX 10.7.5, and upgrading immediately fixed my sybolication woes.
I had tried pretty much everything to get my crash logs to symbolicate. I never had problems before, but a few months had passed since I'd looked at a crash log; at some point during that period I upgraded to Xcode 4.5.2. It seems to me that something with the Xcode 4.5.2 symbolicatecrash perl script does not work correctly on a mac running OSX 10.7.5. In symbolicatecrash, it calls atos to symbolicate an address; it couldn't find the matching symbols, even though I knew for a fact that I had the correct xcarchive. Anyhow, spring for OSX 10.8.2 or newer and hopefully that'll work for you.
Place the dsym and the log in one folder, and then try to open the crash log.
The fix for me was:
To go to the xarchive folder with terminal.
Run: mdimport .
And xcode can now re-symbolicate properly.
The problem is that spotlight is not indexing the archives folder for some stupid reason (lion 10.7)!
I'm looking to try and symbolicate my iPhone app's crash reports.
I retrieved the crash reports from iTunes Connect. I have the application binary that I submitted to the App Store and I have the dSYM file that was generated as part of the build.
I have all of these files together inside a single directory that is indexed by spotlight.
What now?
I have tried invoking:
symbolicatecrash crashreport.crash myApp.app.dSYM
and it just outputs the same text that is in the crash report to start with, not symbolicated.
Am I doing something wrong?
Steps to analyze crash report from apple:
Copy the release .app file which was pushed to the appstore, the .dSYM file that was created at the time of release and the crash report receive from APPLE into a FOLDER.
OPEN terminal application and go to the folder created above (using cd command)
Run atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. The memory location should be the one at which the app crashed as per the report.
Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508
This would show you the exact line, method name which resulted in crash.
Ex: [classname functionName:]; -510
Symbolicating IPA
if we use IPA for symbolicating - just rename the extention .ipa with .zip , extract it then we can get a Payload Folder which contain app. In this case we don't need .dSYM file.
Note
This can only work if the app binary does not have symbols stripped. By default release builds stripped the symbols. We can change it in project build settings "Strip Debug Symbols During Copy" to NO.
More details see this post
After reading all these answers here in order to symbolicate a crash log (and finally succeeding) I think there are some points missing here that are really important in order to determine why the invocation of symbolicatecrash does not produce a symbolicated output.
There are 3 assets that have to fit together when symbolicating a crash log:
The crash log file itself (i.e. example.crash), either exported from XCode's organizer or received from iTunes Connect.
The .app package (i.e. example.app) that itself contains the app binary belonging to the crash log. If you have an .ipa package (i.e. example.ipa) then you can extract the .app package by unzipping the .ipa package (i.e. unzip example.ipa). Afterwards the .app package resides in the extracted Payload/ folder.
The .dSYM package containing the debug symbols (i.e. example.app.dSYM)
Before starting symbolication you should check if all those artifacts match, which means that the crash log belongs to the binary you have and that the debug symbols are the ones produced during the build of that binary.
Each binary is referred by a UUID that can be seen in the crash log file:
...
Binary Images:
0xe1000 - 0x1f0fff +example armv7 <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff dyld armv7s <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...
In this extract the crash log belongs to an app binary image named example.app/example with UUID aa5e633efda8346cab92b01320043dc3.
You can check the UUID of the binary package you have with dwarfdump:
dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example
Afterwards you should check if the debug symbols you have also belong to that binary:
dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example
In this example all assets fit together and you should be able to symbolicate your stacktrace.
Proceeding to the symbolicatecrash script:
In Xcode 8.3 you should be able to invoke the script via
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log
If it is not there you may run a find . -name symbolicatecrash in your Xcode.app directory to find it.
As you can see there are no more parameters given. So the script has to find your application binary and debug symbols by running a spotlight search. It searches the debug symbols with a specific index called com_apple_xcode_dsym_uuids. You can do this search yourself:
mdfind 'com_apple_xcode_dsym_uuids = *'
resp.
mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"
The first spotlight invocation gives you all indexed dSYM packages and the second one gives you the .dSYM packages with a specific UUID. If spotlight does not find your .dSYM package then symbolicatecrash will neither. If you do all this stuff e.g. in a subfolder of your ~/Desktop spotlight should be able to find everything.
If symbolicatecrash finds your .dSYM package there should be a line like the following in symbolicate.log:
#dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )
For finding your .app package a spotlight search like the following is invoked by symbolicatecrash:
mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"
If symbolicatecrash finds your .app package there should be the following extract in symbolicate.log:
Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH
If all those resources are found by symbolicatecrash it should print out the symbolicated version of your crash log.
If not you can pass in your dSYM and .app files directly.
symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log
Note: The symbolicated backtrace will be output to terminal, not symbolicate.log.
With the latest version of Xcode (3.2.2), you can drag and drop any crash reports into the Device Logs section of the Xcode Organiser and they will automatically by symbolicated for you. I think this works best if you built that version of the App using Build & Archive (also part of Xcode 3.2.2)
I did this successfully, using the following steps.
Step 1: Create a folder in desktop, I give name it to "CrashReport" and put three files ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash") in it.
Step 2: Open Finder and go to Applications, where you will find the Xcode application, right click on this and Click "Show Package Contents", after this follow this simple path.
"Contents->Developer->Platforms->iPhoneOS.platform->Developer->Library->PrivateFrameworks->DTDeviceKit.framework->Versions->A->Resources"
OR
"Contents->Developer->Platforms->iPhoneOS.platform->Developer->Library->PrivateFrameworks->DTDeviceKitBase.framework->Versions->A->Resources"
OR
For Xcode 6 and above the path is
Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources
Where you find "symbolicatecrash" file, copy this and paste it to "CrashReport" folder.
Step 3: launch the terminal, run these 3 Command
cd /Users/mac38/Desktop/CrashReport and press Enter button
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" and press Enter
./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM and press Enter Now its Done.. (NOTE: versions around 6.4 or later do not have the -A option -- just leave it out).
Steps to symbolicate a crash report automatically using XCode:
UPDATED FOR XCODE 9
Connect any iOS device to your Mac (yes a physical one, yes I know this is stupid)
Choose "Devices" from the "Window" menu
Click your device on the left and VIEW DEVICE LOGS on the right
Wait. It might take a minute to show up. Maybe doing Command-A then Delete will speed this up.
Critical undocumented step: rename the crash report that you got from iTunesConnect from .txt extension to .crash extension
Drag the crash report into that area on the left
And then Xcode will symbolicate the crash report and display the results.
Source: https://developer.apple.com/library/ios/technotes/tn2151/_index.html
I use Airbrake in my apps, which does a fairly good job of remote error logging.
Here's how I symbolicate them with atos if the backtrace needs it:
In Xcode (4.2) go to the organizer, right click on the archive from
which the .ipa file was generated.
In Terminal, cd into the xcarchive for instance MyCoolApp 10-27-11 1.30 PM.xcarchive
Enter the following atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp'
(don't forget the single quotes)
I don't include my symbol in that call. What you get is a block cursor on an empty line.
Then I copy/paste my symbol code at that block cursor and press
enter. You'll see something like:
-[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)
You're back to a block cursor and you can paste in other symbols.
Being able to go through your backtrace one item without re-entering the first bit is a nice time saver.
Enjoy!
I also put dsym, app bundle, and crash log together in the same directory before running symbolicate crash
Then I use this function defined in my .profile to simplify running symbolicatecrash:
function desym
{
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}
The arguments added there may help you.
You can check to make sure spotlight "sees" your dysm files by running the command:
mdfind 'com_apple_xcode_dsym_uuids = *'
Look for the dsym you have in your directory.
NOTE: As of the latest Xcode, there is no longer a Developer directory. You can find this utility here:
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
Just a simple and updated answer for xcode 6.1.1 .
STEPS
1.Xcode>Window>Devices.
2.Select a device from a list of devices under DEVICES section.
3.Select View Device Logs.
4.Under the All Logs section you can directly drag drop the report.crash
5.Xcode will automatically Symbolicate the crash report for you.
6.You can find the Symbolicated crash report by matching its Date/Time with the Date/Time mentioned in your crash report.
Even though I had been developing apps for a few years now, this was my first time debugging a binary and I felt like a complete NOOB figuring out where all the files were i.e. where is *.app *.dSYM and crash logs? I had to read multiple posts in order to figure it out. Picture is worth a thousand words and I hope this post helps anyone else in future.
1- First go to itunesconnect and download your crash logs.
NOTE: Is most cases you may get something like "Too few reports have been submitted for a report to be shown." Basically not enough users have submitted crash log reports to Apple in which case you can't do much of anything at that point.
2- Now if you had not changed your code since you had submitted your binary it to Apple then Launch Xcode for that project and do Product --> Archive again. Otherwise just find your latest submitted binary and right click on it.
In Xcode 4.2.1, open Organizer, then go to Library/Device Logs and drag your .crash file into the list of crash logs. It will be symbolicated for you after a few seconds.
Note that you must use the same instance of Xcode that the original build was archived on (i.e. the archive for your build must exist in Organizer).
Using Xcode 4, the task is even simpler:
open Organizer,
click on Library | Device Log in the left column
click on "Import" button on the bottom of the screen...
and voilà. The log file is imported and Symbolized automatically for you. Provided you Archived the build using Xcode -> Product -> Archive first.
The magical Xcode Organizer isn't that magical about symbolicating my app. I got no symbols at all for the crash reports that I got back from Apple from a failed app submission.
I tried using the command-line, putting the crash report in the same folder as the .app file (that I submitted to the store) and the .dSYM file:
$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"
This only provided symbols for my app and not the core foundation code, but it was better than the number dump that Organizer is giving me and was enough for me to find and fix the crash that my app had. If anyone knows how to extend this to get Foundation symbols it would be appreciated.
In my case, I was dragging crash reports directly from Mail to the Organizer. For some reason, that prevented the crash reports from getting symbolicated (I'd love to know why).
Copying the crash reports to the Desktop first, and then dragging them from there to the Organizer got them symbolicated properly.
Very specific case, I know. But thought I'd share just in case.
Here's another issue I have with symbolicatecrash – it won't work with Apps that have spaces in their bundle (i.e. 'Test App.app'). Note I don't think you can have spaces in their name when submitting so you should remove these anyway, but if you already have crashes that need analysing, patch symbolicatecrash (4.3 GM) as such:
240c240
< my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
> my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
< my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
> my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";
For those using Airbrake, there's a solid response above but it wouldn't work for me without tweaking:
Works for some memory addresses but not others, not sure why...
Create new dir on desktop or wherever
Find archive in question in Xcode organizer
Double tap to reveal in finder
Double tap to show bundle contents
Copy .dSYM file and .app file into new dir
cd into new dir
Run this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo'
Terminal will enter an interactive move
Paste in memory address and hit enter, it will output method name and line number
Alternatively, enter this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo'
To get info for one address only
The combination that worked for me was:
Copy the dSYM file into the directory where the crash report was
Unzip the ipa file containing the app ('unzip MyApp.ipa')
Copy the application binary from the resulting exploded payload into the same folder as the crash report and symbol file (Something like "MyApp.app/MyApp")
Import or Re-symbolicate the crash report from within Xcode's organizer
Using atos I wasn't able to resolve the correct symbol information with the addresses and offsets that were in the crash report. When I did this, I see something more meaningful, and it seems to be a legitimate stack trace.
I had to do a lot of hacking of the symbolicatecrash script to get it to run properly.
As far as I can tell, symbolicatecrash right now requires the .app to be in the same directory as the .dsym. It will use the .dsym to locate the .app, but it won't use the dsym to find the symbols.
You should make a copy of your symbolicatecrash before attempting these patches which will make it look in the dsym:
Around line 212 in the getSymbolPathFor_dsymUuid function
212 my #executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);
Around line 265 in the matchesUUID function
265 return 1;
This is simple, after searching a lot i found clear steps to symbolicate whole crash log file.
copy .app , crash_report and DSYM files in a folder.
connect the device with xcode
Then go to window -> select devices -> view device logs
Then select this device, delete all logs .
drag and drop your crash on device log section . it will automatically symbolicate the crash . just right click on report and export it .
happy coding,
Riyaz
I prefer a script that will symbolicate all my crash logs.
Preconditions
Create a folder and put there 4 things:
symbolicatecrash perl script - there are many SO answers that tells it's location
The archive of the build that match the crashes (from Xcode Organizer. simple as Show in Finder and copy) [I don't sure this is necessery]
All the xccrashpoint packages - (from Xcode Organizer. Show in Finder, you may copy all the packages in the directory, or the single xccrashpoint you would like to symbolicate)
Add that short script to the directory:
#!/bin/sh
echo "cleaning old crashes from directory"
rm -P *.crash
rm -P *.xccrashpoint
rm -r allCrashes
echo "removed!"
echo ""
echo "--- START ---"
echo ""
mkdir allCrashes
mkdir symboledCrashes
find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
cd allCrashes
for crash in *.crash; do
../symbolicatecrash $crash > ../symboledCrashes/V$crash
done
cd ..
echo ""
echo "--- DONE ---"
echo ""
The Script
When you run the script, you'll get 2 directories.
allCrashes - all the crashes from all the xccrashpoint will be there.
symboledCrashes - the same crashes but now with all the symbols.
you DON'T need to clean the directory from old crashes before running the script. it will clean automatically. good luck!
I found out most of proposed alternatives did not work in latest XCode (tested with Xcode 10). For example, I had no luck drag-dropping .crash logs in Xcode -> Organizer -> Device logs -view.
I recommend using Symbolicator tool https://github.com/agentsim/Symbolicator
Git clone Symbolicator repository and compile and run with Xcode
Copy .crash file (ascii file, with stack trace in begging of file) and .xarchive of crashing release to same temporarly folder
Drag and drop .crash file to Symbolicator icon in Dock
In 5-30 secs symbolicated crash file is produced in same folder as .crash and .xarchive are
In order to symbolicate crashes, Spotlight must be able to find the .dSYM file that was generated at the same time the binary you submitted to Apple was. Since it contains the symbol information, you will be out of luck if it isn't available.
I got a bit grumpy about the fact nothing here seems to "just work" so I did some investigating and the result is:
Set up: QuincyKit back end that receives reports. No symbolication set up as I couldn't even begin to figure out what they were suggesting I do to make it work.
The fix: download crash reports from the server online. They're called 'crash' and by default go into the ~/Downloads/ folder. With that in mind, this script will "do the right thing" and the crash reports will go into Xcode (Organizer, device logs) and symbolication will be done.
The script:
#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode
if [ ! -e ~/Downloads/crash ]; then
echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
exit 1
fi
cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx
datestr=`date "+%Y-%m-%d-%H%M%S"`
mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"
Things can be automated to where you can drag and drop in Xcode Organizer by doing two things if you do use QuincyKit/PLCR.
Firstly, you have to edit the remote script admin/actionapi.php ~line 202. It doesn't seem to get the timestamp right, so the file ends up with the name 'crash' which Xcode doesn't recognize (it wants something dot crash):
header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');
Secondly, in the iOS side in QuincyKit BWCrashReportTextFormatter.m ~line 176, change #"[TODO]" to #"TODO" to get around the bad characters.
atos is being deprecated so if you are running OSX 10.9 or later you may need to run
xcrun atos
Warning: /usr/bin/atos is moving and will be removed from a future OS
X release. It is now available in the Xcode developer tools to be
invoked via: xcrun atos
I like to use Textwrangler to pinpoint errors in an original app upload binary rejection. (The crash data will be found in your itunesConnect account.) Using Sachin's method above I copy the original.crash to TextWrangler, then copy the symbolicatecrash file I've created to another TextWrangler file. Comparing the two files pinpoints differences. The symbolicatecrash file will have differences which point out the file and line number of problems.
For those looking for a working solution in 2022
Steps to Symbolicating iPhone App Crash Reports
Convert apple provided crash log in .txt format to .crash
Xcode > Window > Devices and simulators
Must select a connected & running ios device. (not a simulator, or offline device)
Select All Logs section, drag & drop the .crash file
Note that, the other solutions having symbolicatecrash is deprecated and its usage shows:
⚠️ symbolicatecrash is deprecated; it will be removed in future releases of Xcode ⚠️
We use Google Crashlytics to supervise crash logs, the feeling is very timely and convenient to use.
Document links：
https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms
All about Missing dSYMs
Fabric includes a tool to automatically upload your project’s dSYM. The tool is executed through the /run script, which is added to your Run Script Build Phase during the onboarding process. There can be certain situations however, when dSYM uploads fail because of unique project configurations or if you’re using Bitcode in your app. When an upload fails, Crashlytics isn’t able to symbolicate and display crashes, and a “Missing dSYM” alert will appear on your Fabric dashboard.
Missing dSYMs can be manually uploaded following the steps outlined below.
Note:
As an alternative to the automated dSYM upload tool, Fabric provides a command-line tool (upload-symbols)) that can be manually configured to run as part of your project’s build process. See the upload-symbols section below for configuration instructions.
...