IOS auto build command – xcodebuild

Think of the day when you came to the company, one thing you need to do every day is to open Xcode, pack IPA and upload it to fir. Day after day, month after month, year after year, doing the same thing, as aspiring to become an excellent engineer for me, this is a problem that must be solved, so decided to solve the problem automatically.

brief introduction

Xcodebuild is a tool for apple to publish automated builds. It can build one or more targets in a Xcode project, and can also build scheme on a workspace or Xcode project. In general, it’s the right thing to use.

Usage Note

Tips: at the end of the input man xcodebuild, you can see the introduction of Description usage. You can also see official documents

When you want to build a Xcode project, run xcodebuild in the project directory can (the directory contains the projectname.xcodeproj file on the line), if the directory has a number of projects, you need to specify a project with parameter -project. The default xcodebuild command will build your first target. Of course, you can also specify with -targetname.

If you want to build workspace, you must specify the -workspace and -scheme parameters.

Of course, you can use some commands, such as -version, -showsdks, -list, to get some of the parameters associated with the project.

Earlier articles were packaged using the xcodebuild+ xcrun PackageApplication, but it was not recommended. Use arhive and exportArchive below to pack

Archive package

In shell [[]] indicates that this parameter is optional; < > indicates that arguments are necessary

Don’t say much, just give the order first:

Xcodebuild archive -workspace.Xcworkspace -scheme project project name name -configuration -archivePath archive build configuration package storage path CODE_SIGN_IDENTITY= certificate PROVISIONING_PROFILE= description file UUID
  • -workspace, this is the name of the project
  • -scheme can be obtained through xcodebuild -list
  • -configration some parameters can also be obtained by xcodebuild -list, generally use Debug, Release
  • Path after -archivePath Archive
  • Inentity for CODE_SIGN_IDENTITY certificates
  • PROVISIONING_PROFILE description file UUID, take a look at xcodebuild -list, and see how to get scheme and configration
Information about project "ThreeDTouchTest" ThreeDTouchTest ThreeDTouchTestTests ThreeDTouchTestUITests Build: Targets: Configurations: Debug Release If no build configuration is specified and -scheme is not passed then "Release" is used. Schemes: ThreeDTouchTest

If you don’t need to specify the certificate and the Provisioning file, you can omit the above two parameters. But let’s just say, how do you get these two parameters?:

Certificate Identity access:

Open your keychain to access -> select one of the certificates -> right-click -> display the profile and copy the title.

Format is:

IPhone, Distribution:, Beijing, xxoo, yyooxx, Technology, Service, CO., Ltd. (UA11AAJJKK8)

IOS auto build command - xcodebuild

Get the Provisioning file UUID

Above xcode8.0, the location of the Provisioning file is:

/Users/ user name /Library/MobileDevice/Provisioning Profiles

A folder entered above the terminal. Using /usr/bin/security, you can decrypt the Provisioning file

/usr/bin/security, CMS, -D, -i, 098a87e3-11fe-463d-75aa-12345678adba.mobileprovision

Output the entire plist file at the terminal, which contains all the information

Yes, and this command allows you to view the project settings:

Xcodebuild, -target, < target> -configuration < configuration> -showBuildSettings

Generating IPA files

PackageApplication is no longer recommended. Here’s another way to pack:

.xcarchive -exportPath xcodebuild -exportArchive -archivePath address is archive file folder address -exportOptionsPlist exprotOptionsPlist.plist CODE_SIGN_IDENTITY= certificate PROVISIONING_PROFILE= UUID description file

Similarly, if you do not need the specified certificates and Provisioning files, you can remove the above two parameters, it will match your Xcode configuration.

ExportOptionsPlist this parameter is a plist file.

< XML? Version= "1" encoding= "UTF-8" > < DOCTYPE?! plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "" > < plist version= "1" > < dict> < key> teamID< /key> < string> UA11AAJJKK8< /string> //TeamID < key> method< /key> < string> ad-hoc< /string> //ad-hoc < key> compileBitcode< package; /key> / / bitcode < false/> is compiled;; < /dict> < /plist>

Here are some explanations for other fields:

Available keys for -exportOptionsPlist: compileBitcode For non-App Store: Bool exports, should Xcode re-compile the app from bitcode Defaults to YES.? EmbedOnDemandResourcesAssetPacksInBundle: Bool For non-App Store exports, if the app uses On Demand Resources and this is YES, asset packs are embedded in the app bundle so that the app can be tested without a server to host asset packs. Defaults to YES unless onDemandResourcesAssetPacksBaseURL is specified. iCloudContainerEnvironment For non-App Store exports, if the app is using CloudKit this configures the "" entitlement. Available options: Development and Production. Defaults to Development. Manifest: Dictionary For non-App Store exports, users can download your app over the web by opening your distribution manifest file in a web browser. To generate a distribution manifest, the value of this key should be a dictionary with three sub-keys: appURL, displayImageURL fullSizeImageURL., The additional sub-key assetPackManifestURL is required when using on demand resources. method: String Describes how Xcode should export the archive. Available options: app-store, ad-hoc, package, enterprise, development, and developer-id. The list of options varies based on the type of archive. Defaults to development. onDemandResourcesAssetPacksBaseURL For non-App Store: String exports, if the app uses On D Emand Resources and embedOnDemandResourcesAssetPacksInBundle isn't YES, this should be a base URL specifying where asset packs are going to be hosted. This configures the app to download asset packs from the specified URL. teamID The Developer Portal team: String to use for this export. Defaults to the team used to build the archive. thinning String For non-App Store: exports, should Xcode thin the package for one or more device variants? Available options: < none> (Xcode produces a non-thinned universal APP), < thin-for-all-variants> (Xcode produces a universal app and all available thinned variants or a model), identifier for a specific device (e.g. iPhone7,1). Defaults to < none> uplo. AdBitcode: Bool For App Store exports, should the package include bitcode Defaults to YES.? UploadSymbols: Bool For App Store exports, should the package include symbols Defaults to YES.?

Upload to Fir

This is even simpler. Please refer to the command line client of Fir


As developers, it’s impossible to run with testers every day. Automation is very necessary, so the script will be sure to not suffer.

Reference document

Official document

Mac Security tool usage summary

IOS automatically packs and releases scripts