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.
Related
I am trying to build an Ios app with Objective-C xcode project
The project is using OneSignalNotificationServiceExtension that is why I am specifying the architecture.
the command:
xcodebuild ARCHS=armv6,armv7 ONLY_ACTIVE_ARCH=NO build
but the compilation fails and It throws an error:
Exiting because upload-symbols was run in validation mode
The reason I am doing this is because I need to use the sonarqube wrapper and it takes the build command as argument:
sonar-wrapper --out-dir=bw-output <<build command>>
but I am only able to build the xcode project using xcode
If there is a better way to integrate sonarqube to this kind of projects let me know please.
Maybe try using Fastlane instead of using the xcodebuild CLI directly, I find Fastlane is much more user friendly. I use it for my CI/CD deployments.
It looks like there is some Sonarqube integration as well:
https://docs.fastlane.tools/actions/sonar/
Website: https://fastlane.tools
I successfully built the project specifying the debug mode, workspace and scheme like this:
xcodebuild -configuration Debug -workspace <<workspace>> -scheme <<scheme>> clean build
why xcodebuild building the same application differently for scheme and target options?
xcodebuild -target uConnect build
Above commands builds with Release config in build folder inside
project.
xcodebuild -scheme uConnect build
Above builds with Debug config in Xcode’s DrivedData folder.
Wanted to understand what difference -target and -scheme options are making here?
As per my understanding it should always build the application in Release mode since we have selected Release at Project>>Info>>Configuration
use Release for command-line builds
Reference:
Screenshot of Scheme Details for reference
Try editing the scheme. You will see that it specifies the Debug configuration when building. It might look like this:
But, as you've said, when you build the target, you've specified the Release configuration.
A target describes a product that Xcode will build, like your app, the tests, an App Clip or an Extension. When using -target, it will use the configuration specified in the drop down at the bottom of your screenshot.
A scheme is a configuration that describes how a specific target will be built under different circumstances. If you go to the scheme editor, you'll see that you can choose which configuration to build when running, testing, profiling, analyzing, and archiving.
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.)
This is my .travis.yml file
language: objective-c
osx_image: xcode7.2
script:
xctool -project ProjectName.xcodeproj -scheme ProjectName build -sdk iphonesimulator
While Travis is running I've got this error:
$ xctool -project ProjectName.xcodeproj -scheme ProjectName build -sdk iphonesimulator
ERROR: Cannot find schemes. Please consider creating shared schemes in Xcode.
TIP: This might happen if you're relying on Xcode to autocreate your schemes
and your scheme files don't yet exist. xctool, like xcodebuild, isn't able to
automatically create schemes. We recommend disabling "Autocreate schemes"
in your workspace/project, making sure your existing schemes are marked as
"Shared", and making sure they're checked into source control.
This problem is easy to solve:
Go to your project scheme and click Manage Schemes...
Tick Shared for your scheme
Click Close, commit and push.
Problem Solved. Now Travis is working without problems.
I also wrote a post in my blog about Travis-CI.
In addition to the answer by Gabriel.Massana, make sure the files are checked into version control (SVN/GIT).
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.