I am stripping symbols in Xcode 4.5, but realised that if we strip them we cannot symbolicate crash reports. So I am trying to create a copy of the unstripped binary before stripping. It seems this isn't possible with the normal xcode symbol stripping settings, so I've tried digging into run scripts. The problems I have there is
a) It seems the run script runs after code signing, so the app fails to run.
b) I can't find a way to run a run script under distribution/release only.
Any suggestions?
You can symbolicate crash reports when the binary is stripped! Stripping the binaries makes them 30-50% smaller. Symbolicating with unstripped binaries would not give you line numbers after symbolication anyway.
During the build process you also get a dSYM package which is then used instead to symbolicate your crash reports including getting line numbers in them!
In addition, whenever you do a new build, you get a new unique pair of app binary and dSYM package, so you should use archive instead of build when you are releasing a beta or production version.
Related
I recently update Xcode to Version 7.1, which included Swift 2.1. I installed Swift 2.1 with no troubles. After attempting to run my project, I realized that I needed to grab the latest version of Realm, since the previous version did not support Swift 2.1. I deleted the old frameworks and imported Realm 0.96.2. Whenever I run, I now get this error:
bash: /Users/userName/Library/Developer/Xcode/DerivedData/appName-ghiroqitgsbvfhdqxsscyokyoouz/Build/Products/Debug-iphoneos/appName.app/Frameworks/Realm.framework/strip-frameworks.sh: No such file or directory
I suspected the problem was with the script that is required if you wish to submit your app the the App Store, so I removed the Run Script Phase, added a new one, and copied the script from the Realm documentation site:
bash "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/Realm.framework/strip-frameworks.sh"
I thought that that would fix it, but it did not. I then thought that the problem may be in the Realm.framework or RealmSwift.framework files, so I removed them and re-imported them (Just in case I messed something up). Nothing changed. Does anyone know if there is a fix to this error?
Thanks!
-CodeIt
From the error message, it seems like, you didn't added Realm.framework and RealmSwift.framework to the Embedded Binaries pane, which you find in the General tab of your project, as shown below:
For further validation, you can check the tab Build Phases. It should look like below:
Note: Make sure that the run script phase comes after the Embed Frameworks phase.
Why is this script needed?
The vendored frameworks are not just single executables, but actually FAT binaries which are archives of linked executables on different architectures. This includes architecture slices for arm64 and armv7, which are necessary for deployment on the phone as well as i386 and x86_64 which are necessary for running the app in the simulator.
The strip-frameworks.sh script main responsibility is to take care of removing unnecessary slices. This reduces the final package size and is necessary for AppStore deployment because iTunes Connect rejects apps with simulator architectures.
More Details
The script works on base of the build setting VALID_ARCHS. Because that is changing the signed executable of the framework, it also needs to take care of code signing. Since introduction of bitcode, it also got further post processing as responsibility. It extracts the included *.bcsymbolmap files from the framework bundle and places them into correct path in the *.xcarchive.
The FAQ topic on Bitcode of PSPDFKit has a good explanation on what BCSymbolMaps are:
A BCSymbolMap is a lot like a dSYM for bitcode. Xcode builds it as part of creating the app binary, and also for every dynamic framework. It's required for re-symbolicating function/method names to understand crashers.
In my case, change the process order in Build Phases to solve
not OK
OK
I'm working on an app with another developer and they just submitted a release to the app store that was built on their computer. In order to make a build on my machine (that belongs to the same git commit), I have to alter the path to one of the libraries we use in my XCode project. Will any changes I make to the XCode project file change the dSYM? If I was able to make a build without modifying the XCode project file, would the dSYM file be the same?
A dSYM file is a "debug symbols file". It is generated when the "Strip Debug Symbols" setting is enabled in the build settings of your project.
When this setting is enabled, symbol names of your objects are removed from the resulting compiled binary (one of the many countermeasures to try and prevent would be hackers/crackers from reverse engineering your code, amongst other optimisations for binary size, etc.).
dSYM files will likely change each time your app is compiled (probably every single time due to date stamping), and have nothing to do with the project settings.
They are useful for re-symbolicating your crash reports. With a stripped binary, you won't be able to read any crash reports without first re-symbolicating them. Without the dSYM the crash report will just show memory addresses of objects and methods. Xcode uses the dSYM to put the symbols back into the crash report and allow you to read it properly.
Ideally, your dSYM file shouldn't be tracked in your git repo. Like other binaries that change on building, it's not useful to keep them in source control. However, having that said, it is important that you keep the dSYM files for each distributed build (betas, press releases, app store distributions, etc.) somewhere safe so that you are able to symbolicate any crash reports you might get. Xcode does this automatically for you when you use the Archive option. The created archive contains your app and its dSYM and is stored within Xcode's derived data directory.
I have an iOS project. In response to Build (with a release configuration selected in the scheme) the dsym for it weighs in at 6.5MB. However, when I Archive (with the same configuration selected in the scheme) it weighs in at only 2.9MB.
This is not an academic problem. The missing data includes all the symbols for my static libraries, which is making my crash logs a lot less useful.
Which settings could account for a difference between a Build and Archive with the same configuration selected?
This is with Xcode 5.0, though I think I've been having this problem for a while.
I believe a few things it does are:
Remove all debugging symbols from the app to the .dsym file
Compresses various articles from ascii to binary (such as strings
files)
Some of the differences may be from the following build flags:
DEPLOYMENT_POSTPROCESSING=YES
STRIP_INSTALLED_PRODUCT=YES
SEPARATE_STRIP=YES
COPY_PHASE_STRIP=YES
The other day, I was going through my xcode archive looking for a specific build, and I saw that they all looked the same! The question is pretty simple, but I haven't been able to find any way to do it. Basically, I want to add the build number to either the name description or comment (it doesnt really matter which one) of the archive so I can identify it later. Keep in mind that I don't want the version number which shows up after you click the archive. That wont work because I have incremental builds that are distributed on an ad-hoc network with testflight with the same version number, but different build numbers. For example, 2.0.8.10 and 2.0.8.11 both show up as 2.0.8. Any ideas?
What are you using to build your archives? Are you using the Xcode GUI via Product -> Archive? Or are you using some kind of build script that calls xcodebuild? If you're using the Xcode GUI, I'm not aware of any way to automate the name--you'll just have to copy in the full build number when you make the build.
If you're using a build script, check out PlistBuddy (ships with OSX, but by default isn't in your PATH, usually it's at /usr/libexec/PlistBuddy). You can use PlistBuddy to read the build number from your target's Info.plist and then insert that value into the name/description of the archive you're building.
I've been trying to submit an app to the app store for a client (my first try) and have been running into various and sundry problems. I finally decided to create a new app name, recreate the developer provision profile and recreate the developers certificate.
I can now run it in simulator and debug on the device, but can no longer run it in release mode - it doesn't even compile. The error message is:
arm-apple-darwin10-gcc-4.2.1: /Users/me/Documents/iphone/QuizApp/CityGuide_Prefix.pch: No such file or directory
The reference to the "CityGuide_Prefix.pch" file would be a holdover from the app I based it on, and apparently did not rename correctly. I don't know why the problem showed up now.
At the beginning of the compile log there is a reference to this file:
ProcessPCH /var/folders/YN/YNuTu4omEDm9bUMfK4s5yU+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/CityGuide_Prefix-etfgludtmplcfzcirudhxormhsna/CityGuide_Prefix.pch.gch CityGuide_Prefix.pch normal armv7 objective-c com.apple.compilers.gcc.4_2
And it also shows up under the gcc compile command under this parameter:
-c /Users/me/Documents/iphone/QuizApp/CityGuide_Prefix.pch -o /var/folders/YN/YNuTu4omEDm9bUMfK4s5yU+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/CityGuide_Prefix-etfgludtmplcfzcirudhxormhsna/CityGuide_Prefix.pch.gch
My question is, how do get rid of this old reference? And why did it work before?
Check the build settings for your target in release mode. You will find a GCC_PREFIX_HEADER directive stating the wrong precompiled header file name (CityGuide_Prefix.pch). Change it to the right value (which you can find inspecting the debug configuration).
If you don't find that directive for your target, check the general project build settings.
Alternatively, you can open your /project.pbxproj file and search for ".pch" (without quotes), in order to fix that value for the release configuration.
You should have a look into the Build Phases of your target and figure out the file is named there under Compile Sources. If so, remove it there.