On my hand is an Xcode project, comprising of a number of static libraries, and an iOS application that consumes them (we do not intend to release the libraries). Part of it is a crash reporting implementation based on Google Breakpad.
An issue that we've found is that we aren't getting line number information in crash reports for the libraries, from our releases. These are generated using xcodebuild archive -project ${PROJECT_PATH} -scheme ${SCHEME_NAME} -archivePath ${OUTPUT_PATH} -UseModernBuildSystem=NO -IDEBuildingContinueBuildingAfterErrors=YES. EDIT: using Xcode 12.
If, instead of archive, I run the xcodebuild build action with the same options (exc. archivePath of course) - or build the project in the IDE -, then I get complete symbol information and everything works (at least testing on iOS Simulator). This seems to be the only difference - of course then I'd still need to produce an .ipa somehow.
The build options are shared between all libraries and application, and include the following:
COPY_PHASE_STRIP = YES
DEPLOY_POSTPROCESSING = YES
SEPARATE_STRIP = YES # tried to change each of these to NO in various permutations; no difference.
STRIP_STYLE = non-global
What is the difference between the steps that the build and the archive actions perform, with regards to stripping?
How can I create the .ipa from the artifact of the xcodebuild build, or otherwise coerce xcodebuild archive to omit / delay stripping, so that I may perform that manually once I've dumped the symbols?
It might be worth mentioning that I've tried combinations of the xcodebuild actions as well, i.e. clean build archive in one or separate steps - makes no difference.
(FWIW, I realise that the PackageApplication command of xcrun was deprecated as of Xcode 8.3.)
Related
I am using xcodebuild commandline tool to generate my ios app(mainly c++ source code). The command is like
xcodebuild -project Application.xcodeproj
I want to ask whether can I separate the build phase and package phase, that is to say, first build the binary executable, then at sometime package the app later.
From Apple technical note, xcodebuild supports various build actions such as build, analyze, and archive that can be performed on your target or scheme. However, build is performed by default when no action is specified. So, when you want to package, specify action archive otherwise just leave it empty as shown in Apple Example in the document.
I am using xcodebuild to generate an archive from a workspace. I use the following command:
xcodebuild -workspace MyProject.xcworkspace -scheme "MyProject"
-destination generic/platform=iOS archive
-archivePath "../PathToArchive/MyProject.xcarchive
(I've spaced it out over multiple lines for readability)
This command generates a MyProject.xcarchive. However it generates a generic "Xcode Archive" rather than an "iOS App Archive." This cannot be submitted to the App Store.
If I archive the exact same workspace and scheme using Xcode.app version 7.0.1 (7A1001) instead of xcodebuild then I get an "iOS App Archive" which can be submitted to the App Store.
Inspecting the contents of these two xcarchives shows the main difference is the bundled Info.plist file. The one generated by Xcode.app contains an additional ApplicationProperties dict with versioning and signing details. The one generated by xcodebuild lacks these details in its Info.plist.
Copying the Xcode.app generated Info.plist into the xcarchive generated by xcodebuild "fixes" the archive, and it can be submitted to the App Store. This is not a solution however, as it means I cannot build on the command line.
Note that doing xcodebuild -version prints:
Xcode 7.0.1
Build version 7A1001
Edit: sometimes xcodebuild appears to generate a correct iOS App Archive instead of a Generic Archive. I'm not exactly sure why this happens. It's not consistent.
Are you using Cocoapods? If so try using the pre release version gem install cocoapods --pre . I had the issue because of a copy pods phase being somewhere it should not have been, please go through https://github.com/CocoaPods/CocoaPods/issues/4021 you should find a solution that fits you.
After a lot of frustration I have discovered the cause of xcodebuild producing incorrect xcarchive packages.
I had to disable the "Parallelize Build" option for the scheme I was building.
After un-ticking this option, the builds take a lot longer, but xcodebuild is consistently producing an "iOS App Archive" rather than a "Generic Archive." With "Parallelize Build" enabled xcodebuild would generate a "Generic Archive" 90% of the time, occasionally generating a correct archive.
Because I wanted my build times within Xcode to remain unaffected, I left the "Parallelize Build" option enabled for my schemes. I duplicated the schemes to be built with xcodebuild and un-ticked the option only for the deployment schemes.
I'm trying to track down a confusing xcodebuild issue. I have a carthage dynamic framework project that includes another dynamic framework. When I do a debug build (which seems to be what carthage does)
xcodebuild -sdk iphonesimulator9.0 ONLY_ACTIVE_ARCH=NO -configuration release
My resultant framework has a /Frameworks directory inside of it.
When I do a debug build this /Frameworks directory does not exist. This is causing issues because you can't submit an app to apple that has embedded frameworks.
I'm sorry this question is a little open ended but does anybody have any ideas what settings I should be looking at in my build file?
When I did an xcodebuild -showBuildSettings i see the following:
FRAMEWORKS_FOLDER_PATH = GDL90.framework/Frameworks
Which I'm assuming is probably the culprit. But i'm not sure how to fix/change this guy. I'm assuming if i made it GDL90.framework/../../Frameworks that would likely get it outside of my framework - but .... a little unclear how to do this.
I cannot build my project for the device although XCode can build without any issue given the same settings.
Here is the build command:
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -workspace /path/to/workspace/myProject.xcworkspace -scheme myScheme -configuration Debug -destination id=myDeviceIdentifier build
Here is the error i get:
xcodebuild: error: The run destination [device name] is not valid for Running the scheme 'myScheme'.
[device name] doesn't match any of myProject.app's targeted device families. You can expand myProject.app's targeted device families to support [device name].
I did check the targeted device family for the project and all of the subprojects, and it is fine.
The problem appears less often after removing a significant count of file references from the project.
Did some of you encounter the same issue and do you know how to fix it?
i could bypass the issue by debugging as universal app, although i am developing for ipad.
this changes TARGETED_DEVICE_FAMILY from 2 (iPad) to "1,2" (Universal) in the project file (project.pbxproj).
there's also a quite simple way to reproduce the issue:
if you create two projects from template. one will work one not.
WORKS: Single View App, Objective C, Universal
DOES NOT WORK: Single View App, Objective C, iPad
more information can be found here:
https://youtrack.jetbrains.com/issue/OC-11204
http://openradar.appspot.com/20526470
please file this issue with apple: http://bugreport.apple.com
Try this steps:
Go to Targets -> Valid Architectures & remove arm64
Set Build active Architectures to No
there might be another workaround by enabling a lot of debug output.
add the following parameter to the command:
xcodebuild …-IDERunDestinationLogLevel=3
somehow if log level 3 is set, building works. with log level 2 it does not.
I'm trying to build my XCode project via the terminal. I'd like use Xcode's Product > Build for > Profiling option. So far I have:
xcodebuild -project "MyGame.xcodeproj" -target "MyGameEditor - Mac" -destination 'name=My Mac 64-bit' -configuration Profile
The project builds but not for profiling. I get an error that configuration 'Profile' does not exist.
Any help is appreciated.
What you are trying to sepcify with -configuration is the build configuration, not the build action. Unless you have added extra configurations to your project, you only have "Debug" and "Release" configurations.
What Xcode does when you tell it to profile is it builds the configuration that your scheme specifies to use when profiling, launches the simulator, installs the app, then launches Instruments.
So you need to do a similar thing with two command line calls, one to xcodebuild, one to instruments.
Some helpful links that should help you figure out what you need to do:
http://blog.manbolo.com/2013/04/09/launching-uiautomation-tests-in-command-line
Can the UI Automation instrument be run from the command line?
It is also worth noting that rather than specifying a target and configuration, you should just specify a scheme which provides both and other optional additional features.