When I came to the company every day, one thing I needed to do every day was to open Xcode, pack ipa and upload it to fir. I do the same thing day after day, month after month, year after year. As an aspiring engineer, this is a problem that must be solved, so I decided to solve the problem automatically.
xcodebuild is an automatic build tool released by apple. It can build one or more targets under an Xcode project, and can also build a scheme on a workspace or Xcode project. In general, it is right to use it.
Tips: enter man xcodebuild in the terminal, and you can see the usage in the Description.
You can also see Official documents
When you want to build an Xcode project, just run xcodebuild in the project directory (the directory contains the projectname.xcodeproj file). If there are multiple projects in the directory, you need to specify a project with the parameter - project. The default xcodebuild command will build your first target. Of course, you can also specify it with - targetname.
If you want to build a workspace, you must specify the - workspace and - scheme parameters.
Of course, you can use commands such as - version, - showsdk, - list and so on to get some project related parameters.
The previous article used the PackageApplication package of xcodebuild+ xcrun, but it is not recommended. Next, use arhive and exportArchive to package
In the shell,  indicates that this parameter is optional, < > indicates that the parameter is required
If you don't have much to say, first order:
xcodebuild archive -workspace entry name.xcworkspace -scheme entry name -configuration Build configuration -archivePath archive Package storage path CODE_SIGN_IDENTITY=certificate PROVISIONING_PROFILE=Description file UUID
- -workspace is the project name
- -scheme can be obtained through xcodebuild -list
- -Some configuration parameters can also be obtained through xcodebuild -list. Generally, Debug and Release are used
- -Archivepath path after Archive
- CODE_SIGN_IDENTITY the identity of the certificate
- PROVISIONING_PROFILE description UUID
Let's take a look at xcodebuild -list and see how to get scheme and configuration
Information about project "ThreeDTouchTest": Targets: ThreeDTouchTest ThreeDTouchTestTests ThreeDTouchTestUITests Build Configurations: Debug Release If no build configuration is specified and -scheme is not passed then "Release" is used. Schemes: ThreeDTouchTest
If you do not need to specify the certificate and Provisioning file, you can omit the above two parameters. However, let's talk about how to obtain these two parameters:
Certificate Identity acquisition:
Open your keychain access - > select one of the certificates - > right click - > display profile, and copy the title.
The format is:
iPhone Distribution: Beijing xxoo yyooxx Technology Service CO., Ltd. (UA11AAJJKK8)
Get the UUID of the Provisioning file
In xcode8 Above 0, the location of the Provisioning file is:
/Users / user name / Library/MobileDevice/Provisioning Profiles
Enter the folder above the terminal. The Provisioning file can be decrypted using / usr/bin/security
/usr/bin/security cms -D -i 098a87e3-11fe-463d-75aa-12345678adba.mobileprovision
The terminal outputs the entire plist file, which contains all the information
By the way, you can also use this command to view the project settings:
xcodebuild -target <target> -configuration <configuration> -showBuildSettings
Generate ipa file
PackageApplication is no longer recommended. Here is another packaging method:
xcodebuild -exportArchive -archivePath archive Address of the file.xcarchive -exportPath Exported folder address -exportOptionsPlist exprotOptionsPlist.plist CODE_SIGN_IDENTITY=certificate PROVISIONING_PROFILE=Description file UUID
Similarly, if you don't need the specified certificate and Provisioning file, you can remove the above two parameters, which will match according to your Xcode configuration.
The parameter exportOptionsPlist is a plist file.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>teamID</key> <string>UA11AAJJKK8</string> //TeamID <key>method</key> <string>ad-hoc</string> //ad-hoc packaging <key> compileBitcode</key> //Compile bitcode <false/> </dict> </plist>
The following is an explanation of other fields:
Available keys for -exportOptionsPlist: compileBitcode : Bool For non-App Store 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 "com.apple.developer.icloud-container-environment" 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 : String For non-App Store exports, if the app uses On Demand 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 : String The Developer Portal team 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>. uploadBitcode : 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: Command line client for Fir
As a developer, it is certainly impossible to follow testers every day. Automation is very necessary, so if you can click scripts, you won't lose.
Reprint link: https://www.jianshu.com/p/3f43370437d2