The TestFlight SDK recommends setting Strip Debug Symbols During Copy to YES in Xcode Build Settings to enable the best crash reporting possible. I noticed that it's set to YES by default.
Should I change it to YES? Why or why not?
I work at TestFlight. Short answer is: set it to YES.
Long answer:
#Kerni is correct. Before we started symbolicating server side, we needed that data to symbolicate on device.
So if you upload your dSYM to TestFlight, you can strip them. If you don't want to upload your dSYM for some reason, you can leave them in and TestFlight can symbolicate on device.
Basically the README was not updated. Sorry #Manni! I will update it for the next release. (I'm going to remove that entire section).
Sorry about the confusion!
If the default setting is YES, there is no need to do anything else.
In general this setting makes sure that debug symbols are not part of the distributed binary which reduces the file size by 30-50%. The debug symbols should instead be written to the dSYM DWARF file, which can later be used to symbolicate crash reports.
The TestFlight SDK recommends to set this setting to NO, not to YES:
To enable the best crash reporting possible we recommend setting the following project build settings in Xcode to NO for all targets that you want to have live crash reporting for. You can find build settings by opening the Project Navigator (default command+1 or command+shift+j) then clicking on the project you are configuring (usually the first selection in the list). From there you can choose to either change the global project settings or settings on an individual project basis. All
settings below are in the Deployment Section.
Deployment Postrocessing
Strip Debug Symbols During Copy
Strip Linked Product
Bugsense (http://www.bugsense.com/pages/faq) also recommend this setting with this explanation:
Why do I get memory dumps instead of the stack trace for my iOS app?
iOS apps usually don’t include debugging information or this information is included in a special file with the extension dSYM
(debugging SYMbols). To turn on (and include in your binary) debugging
information for your iOS app you must set to NO a project setting
called “Strip Debug Symbols” for all project configurations.
Related
I have some problems with uploading dSYMs to crashlytics using Xcode 14. I saw a lot of similar questions and discussion on apple forum, but none if them are the same as my case.
Since in Xcode 14 bitcode is deprecated we can't download dSYMs from TestFlight. As i understand as long as flag "enable_bitcode" is set to no, dSYMs from my local archive (which was used to upload app to TestFlight) should be valid for crashlytics, but unfortunately there is a mismatch in dSYM uuid.
So in Firebase Console there is an information that for version X build Y there are missing dSYMs with UUID idX1 and idX2, but unfortunately when i check archive that was uploaded to Testflight there is no dSYMs with uuids idX1 or idX2.
Do i miss sth? I will appreciate any help.
When bitcode is disabled, these are usually the steps to follow:
Make sure that Xcode is generating dSYMs.
Follow these configuration steps to automatically upload dSYMs when building the app.
Increase the version/build number (this is to easily distinguish the new tests).
Do a small code change. This will trigger Xcode to generate a new UUID and related dSYMs.
Build the app and cause a test crash following these steps.
If everything went well, the correct dSYMs should be uploaded to Crashlytics. But, if you see "missing dSYMs" for the this version/build number, it would be interesting to see if something went wrong when uploading the dSMYs.
Typically, the run script will do some validations but will do the upload asynchronously. To override this behavior and do it as part of the build process you can use this other run script:
"${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/upload-symbols" --build-phase --debug
The --build-phase flag will indicate the script to upload the dSYMs during build time, this will make the build to take a bit longer but will give you the opportunity to obtain more information about this process. Also, the --debug flag will make the script to provide verbose output.
Things to look in these debug logs:
The UUIDs of the dSYMs files.
The App Id. Make sure this is the correct one. In some scenarios there can be multiple GoogleServices-Info.plist files and the script could be using the wrong file.
Errors in the upload process.
This was working perfectly - before I upgraded to Xcode 10 that is. My app has a Quicklook and a Spotlight plugin integrated into it. These plugins are built separately and then, in the Build Phase, copied (two Copy Files) with the following settings:
Destination: Wrapper
Subpath: Contents/Library/<QuickLook|Spotlight>
Code Sign on Copy
Now, when I attempt to Archive in order to submit my App to the Mac App Store, my application archive to 'Other Items' instead of 'MacOS Apps'.
If I remove my plugins then it will archive correctly - but (obviously) I don't want to do that since this functionality is critical.
Has anyone seen this problem before? Can anyone suggest a solution?
You're getting generic Xcode build.
This may happen, if you're using nested applications, static libraries, frameworks or headers.
You should set Skip install toYES in build settings for your plugins.
More here
To be a bit more precise than just randomly setting Skip install on any target:
Check the contents of the .xcarchive, Xcode reports it as a generic archive when there's more than one item in Products/Applications. It should contain only your application.
After finding the extra items there, you can then know for which target you should set "Skip Install" to Yes.
After migrating to Xcode 9, I noticed that it constantly fully builds my project. I found that it is somehow related to the "show live issues" setting. Disabling that setting stops builds, but it makes development inconvenient.
I would like to disable this continuous build loop, or make it work without launching all build scripts.
My custom build scripts contain linting and formatting, so what happens is, I try to edit a file, but Xcode starts building, thus launching the formatting routine that changes exactly the same file I am trying to edit.
Open any .storyboard file in your project and go to the Editor menu, uncheck 'Automatically Refresh Views'.
After upgrading the Xcode version to Xcode 9.0, I also faced a similar issue and my CPU usage was jumping upto 50% just because of Xcode. However I could solve it by following the steps below.
In the Toolbar go to:
File -> Project Settings / Workspace settings change Build System to Standard Build Settings under Shared Workspace Settings. Also under Per-User workspace Setting change Build System to Standard Build System.
The release notes also say the following.
"Xcode 9 includes a new build system written from scratch in Swift. It
is designed for higher reliability, and it catches project
configuration problems that the standard build system does not. The
performance of the build system (not including compilers, linkers, and
other build tools) has been dramatically improved."
So there could be a possibility that there are still bugs in the new build system.
I have a Xcode project that outputs a Mac app that is distributed outside the Mac App Store. It works fine. Now, the client wants it in the Mac App Store. To achieve this I've disabled several features of the original app. Now, I'm facing the question: how to integrate the build process of the Mac App Store app in a painful-less way? For the Non-Mac App Store app we use Jenkins.
I thought it could be possible to keep the non-Mac App Store project settings and then enable/disable/modify it with command line. Errrrr!. I'm wondering if anyone else have faced the same situation and how did you solve it?. Or maybe I'm opening Pandora's box wit my current approach.
To list the stuff I need to enable/disable:
Disable source code. Solution: ifdefs
Enable the app-sandbox. Solution: adding 'com.apple.security.app-sandbox' to entitlements.
Delete dependencies in the 'Target dependencies'. Solution: ????.
Delete libraries in the "link binary with libraries". Please, note that the libraries are already listed in Xcode project settings, I want to delete them.
Change the signing profile. Solution: Add a new scheme with the right values (Mac App Store).
FYI. I'm using Xcode 5.1.1.
To modify Xcode project settings from command line, you could try a python module pbxproj.
You can pip install pbxproj to have it.
And here's an example provided in the official repo:
from pbxproj import XcodeProject
# open the project
project = XcodeProject.load('myapp.xcodeproj/project.pbxproj')
# add a file to it, force=false to not add it if it's already in the project
project.add_file('MyClass.swift', force=False)
# set a Other Linker Flags
project.add_other_ldflags('-ObjC')
# save the project, otherwise your changes won't be picked up by Xcode
project.save()
I'm not sure about Xcode 5.1.1. But if you're already using a new scheme to change the signing profile, why can't you use it to delete the dependencies and linked libraries? These can be changed in the Build Phases for this specific target. Or you have some more context to explain why you can't do this?
I want to distribute my app, i put code signing and everything and my last step was to set the build to release. I went to edit scheme and put build configuration to release and then my product turned red for some reason. I couldnt open it in finder therefore i cant send it. If I change it back to build mode it isnt red and I can open it in finder. What do I do?
I have tried heaps of things but cannot get it to work!
Please help,
thank you
You simply need to need to build you product on release mode. Change the build configuration as you made and build, exactly the same way you did in debug mode.
In Xcode 4 and older 3.x version, however, you probably shouldn't build directly in release mode but use the archive feature.