Do .dSYM resources contain any other information except DWARF information? I have created a release build of an app. Now if I run dwarfdump on it, it says the executable has no DWARF info (says it's "empty"), which is what I would expect. But if I then run dsymutil on it, it creates non-empty symbol files. These are binary files so I don't know what's in them. Can anyone enlighten me on this? Are there any viewers for these files?
Yes, there is additional information. Note that the .dSYM file is actually a directory. Inside you will find:
SomeApp.app.dSYM/Contents/Info.plist
SomeApp.app.dSYM/Contents/Resources/DWARF/SomeApp
Be aware that you need to keep the exact .dSYM and .app bundle that was created when you made the release build. Even if the code hasn't changed, the .dSYM from a separate build won't match up because apple generate a unique id for each build you do.
Related
Xcode is generating one dsym, which has the name of my app as the filename (e.g. MyApp.app.dSYM), but it's not generating the other dsyms with the UUIDs that Firebase is constantly telling me that I'm missing. (e.g. 92248A4B-6CA2-3B54-9787-C007E25C018F.dSYM)
I've followed the instructions, but something is still wrong. This was working when we were using Fabric, but since we updated to use Firebase directly, nothing is really working properly anymore.
I've followed the instructions on how to change the Build Settings to make sure the dSYMs get generated, but my Build Settings were already updated like that when I following the migration instructions from Fabric to Firebase. Here is a screenshot of my Build Settings:
Here is a screenshot of my Run Script Build Phase:
In the Archive Build Log, the only reference to generating dSYMs is for the one MyApp.app.dSYM that I get, but I need the others generated too.
GenerateDSYMFile
/Users/kenny/Library/Developer/Xcode/DerivedData/MyApp-dttbmiamkojuotbcyjgzerxhcqun/Build/Intermediates.noindex/ArchiveIntermediates/MyApp/BuildProductsPath/Release-iphoneos/MyApp.app.dSYM
/Users/kenny/Library/Developer/Xcode/DerivedData/MyApp-dttbmiamkojuotbcyjgzerxhcqun/Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/MyApp
(in target 'MyApp' from project 'MyApp')
cd /Users/kenny/inaday2/svn-MyApp/trunk/apps/iOS/MyApp
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil
/Users/kenny/Library/Developer/Xcode/DerivedData/MyApp-dttbmiamkojuotbcyjgzerxhcqun/Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/MyApp
-o /Users/kenny/Library/Developer/Xcode/DerivedData/MyApp-dttbmiamkojuotbcyjgzerxhcqun/Build/Intermediates.noindex/ArchiveIntermediates/MyApp/BuildProductsPath/Release-iphoneos/MyApp.app.dSYM
Settings look okay, attaching the script I am using and process. Hope these info helps.
To have all the dsyms you need to first upload the build to Testflight and then from Tesflight, you need to download the final processed dSYM.zip.
A folder appDsyms.zip will be downloaded, once this is decompressed, you will see list of dSYM's
Post that use below script to upload the same to crashlytics.
So there are few changes done in Firebase Crashyltics the way dSYM mapped to the build we upload.
Initially, there was a manual option as well to upload but now that's abandoned and the only way by running the script from your terminal.
Pods/FirebaseCrashlytics/upload-symbols -gsp YOUR_PLIST_FULL_PATH -p ios ~/PATH_TO_DSYM_ZIP_OR_FOLDER
**Example[Below is my working script to upload dSYM to crashlytics]:**
Pods/FirebaseCrashlytics/upload-symbols -gsp MY_PRROJECT_NAME/Support/Firebase/Prod/GoogleService-Info.plist -p ios ~/Downloads/appDsyms
I am trying to map my understanding of "DWARF" vs "DWARF with dSYM file" debugging info formats to what I see in the crash information for different iOS build configurations.
I was trying to fix a problem, where crashes on the build with debug configuration were not symbolicated by default. These were my build settings before the problem was fixed -
Strip Linked Product - Debug - No, Release- Yes
Strip Debug Symbols during Copy - Debug - No, Release - Yes
Debug Information Format - Debug - DWARF, Release - DWARF with dSYM file
What got it to work was setting the Debug information format to "DWARF with dSYM File" for debug configuration as well.
My questions is - why do I need to to set the format to "DWARF with dSYM File" if I am specifying that the product should not be stripped of its symbols into a dSYM file (in the strip linked product setting)?
My (probably incorrect) understanding was that if I set it to DWARF, then all the debug information would be inside the app binary and I do not need a separate dSym file for symbolication? Please help me with a better understanding of this.
On Apple's platforms, DWARF is never baked into the executable (except for unwind info). Enabling DWARF debug info just means that the .o files contain DWARF-formatted debugging info. The linker doesn't bring that into the executable, though.
If you request a dSYM file, a separate build step uses dsymutil to collect the debugging info from the .o files into a dSYM bundle or file.
Debuggers can use a map in the executable to look up the debug info in the .o files when needed, assuming you're debugging on the build machine. That's why you don't typically need a dSYM file for a Debug build. Symbolication doesn't have the executable, just a UUID for it. It could find the dSYM using the UUID, but it doesn't have the information to find the .o files.
See this answer by an Apple developer involved in implementing this stuff. Also, this older wiki article he wrote.
I download one ipa file from appstore,and want to get list of the static lib that linked,any one can help me ?
First of all, it would be interesting to read this official manual by Apple (OS X ABI Mach-O File Format Reference).
Second: how do you download IPA from AppStore? I doubt it's practically possible. Anyway, if you somehow managed to get IPA, then you can use otool command line tool to get static imports. Look inside IPA file (it's standard zip-archive), find the binary file there (it usually has the same name with IPA, e.g, MyApp.ipa -> MyApp.app -> MyApp), extract this binary file and then run the command
otool -L MyApp
I get the errors:
Warning: Multiple build commands for output file /Users/me/Library/Developer/Xcode/DerivedData/myapp-csoyvdzaugzkszeagjrtzrfssudr/Build/Products/Debug-iphonesimulator/myapp.app/icon-72.png
Warning: Multiple build commands for output file /Users/me/Library/Developer/Xcode/DerivedData/myapp-csoyvdzaugzkszeagjrtzrfssudr/Build/Products/Debug-iphonesimulator/myapp.app/Default-Landscape#2x~ipad.png
Warning: Multiple build commands for output file /Users/me/Library/Developer/Xcode/DerivedData/myapp-csoyvdzaugzkszeagjrtzrfssudr/Build/Products/Debug-iphonesimulator/myapp.app/Default-Landscape~ipad.png
When I try to run my app in the simulator. I understand this is because of duplicate files. But when I remove either of the duplicates I get the errors:
error: /Users/me/Documents/Cordova27/myapp/myapp/Resources/icons/icon-72.png: No such file or directory
Does anyone know how to fix this at all? Have tried cleaning and restarting XCode to no avail.
open the Copy Bundle Resources Build Phase. find the twice files in that list and Delete the duplicate reference.
Remove both,Add again.[Drag and drop at the icon field in the summary page]
I moved bunch of images to a different folders and hit the same issue. To solve, basically go to build phases >> Copy Bundle Resources and remove earlier references as shown in the picture below.
Note: Another thing to check is to see if you have multiple references of the files in the left panel (you will see 2 files with the same name)
If you set the splash/launch icon from Xcode (Targets -> Summary ...), the Xcode has an annoying feature that will copy your png file into the root folder, and after that you will get the warning for "Multiple build commands". What you need to do is, delete your png file used for splash/launch and also check the copy bundle resources in Target section and make sure your file has been removed from there. It will appear in red if the file is removed from your project and not removed from Copy bundle resources.
My problem was also in Copy Bundle Resources, but my cause was fast lane. All of my fastlane files name.txt, keywords.txt, marketing.txt, etc. were copied from each of my support languages into the bundle.
Go to your target Build Settings. In the search tool, enter the name of each fastlane file. In this case, you can delete all fastlane files. These are used for uploading your bundle to the App Store and so the files don't need to be in the bundle at all.
Add a new image(PNG) only via Copy Bundle Resources. Remove duplicates same way.
I tried strings over application binary..but it is showing following error:
strings: object: malformed object (unknown load command 19)
Any other way to read hardcoded information from an iOS application's binary file
The IPA file is not the binary. It's a ZIP archive which you have to extract in order to obtain the app bundle directory, in which resides the actual executable.
Even that executable isn't well-formed. It's encrypted with the AppleID of the user who has downloaded it. You need to decrypt it before being able to run strings on it (you can use some popular iOS application cracking tools for this purpose).
To get hard coded Strings from ipa follow below steps :
Get Clutch from here.
Decrypt the app using Clutch (Clutch <ipaToDecrypt>)
Unzip the decrypted ipa, and get the app bundle directory.
Locate the executable within it, and run strings command against the binary.
(strings <app-binary>)
This is pretty old but I had a particular issue where I was trying to find the hard-coded strings in an app for which Bitcode was enabled and I'd built an archive for exporting to the AppStore.
The final .ipa file unzips as usual, containing the binary at Payload/appname.app/appname, but strings and similar tools are not able to process this.
Instead I used the following commands:
segedit Payload/appname.app/appname -extract __LLVM __bundle llvm.xar
xar -xf llvm.xar
llvm-dis 1
You'll need to install the llvm tools (e.g. brew install llvm) to get llvm-dis.
This produces a file called 1.ll which clearly contains the hard-coded strings I was looking for (along with quite readable pseudo-source). If there's nothing in 1.ll, see if there's files named 2, 3, 4 etc. and run llvm-dis on them.
However for an ipa that has actually been downloaded from the AppStore, you will unfortunately need to use a jailbroken device where you can run clutch etc.