iOS Builds and Internal Release From Command Line
By: John Ohue
Tags: Continuous Delivery, iOS, Mobile, Xcode

iOS Developers tend to handle build archiving, testing and release with Xcode’s Organizer.

Archiving, testing and release can also be done with Xcode command-line tools. These same command-line tools, are the foundation of automated build systems and can be leveraged to build, test, and upload iOS applications.

What you will need .

Xcode Command-line tools. This ships with Xcode. However if you need to install it from Terminal simply run the below command.

xcode-select --install

From this point, everything you need to do will be done from our project’s directory.

cd path-to-project

2. Your Project Setup with appropriate Schemes. The most conventional being the debug and release schemes. You can check the schemes and configurations available on your iOS project by running this command in our project’s directory and pointing to the xcodeproj file.

xcodebuild -list -project OurProject.xcodeproj

3. Your AppID , Provisioning Profile, Certificate for Distribution and Development are some of the other things that will be needed to release you application from terminal.

4. The Project’s xc.workspace file.

Chances are you have already released to Test-flight or to the app store before and you already have all of the above. If this is not the case, you would have to setup your project to be able to continue with the next steps.

5. An exportOptions property list file : This Key-Value pair file defines the rules for the .ipa file. We can create our plist file in Xcode by adding a new Property list file to our project, name it OptionsPlist, and then add the following ;

teamID as key , type String and your team ID gotten from your https://appleid.apple.com account as value. The second property would have method as key, type String and app-store as value.

<?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>method</key> <string>app-store</string> <key>teamID</key> <string>YOUR_TEN_CHARACTER_TEAM_ID</string> </dict> </plist>

STEPS TO TAKE

Naturally the first step to release a build is managing the versioning. This can be done from the General Pane inside Xcode. To do this from the command line, we can use agvtool, an xcode command line tool to bump our build number.

You only have to setup agvtool once and subsequent use of the agvtool would not require this step.

1. Enabling the agvtool

For this, In order to enable agvtool, we need to ensure that Current Project Version is set to an integer and Versioning System is set to Apple Generic in our target build settings.

You can easily find these by searching with the ‘versioning’ keyword.

Also, set Bundle versions and Bundle versions string, short values under Info tab to 1.

2. Bumping Version Number with agvtool

With agvtool setup, we can increment and set our build numbers as we desire from the command line.

Run the following command to set a particular version to our project, Semver style

agvtool new-marketing-version 'X.Y.Z'

We can subsequently set the build number to 1 if we so desire. Testflight manages this so it is not compulsory.

agvtool new-version -all 1

3.Build, Archive and Release from the Command line

xcodebuild is another command line tool and can be used to build for testing and archiving. This step generates your app’s derived data.

For the next steps we are going to need to know the Scheme we are trying to build and the particular configuration. This information can be gotten by running this command in terminal.

xcodebuild -list -project OurProject.xcodeproj

Although Custom Configurations and Schemes can be added to our project , by default, we have Debug and Release Configurations and our default Scheme as the project’s name. Let us use the debug configuration for our subsequent steps.

xcodebuild -scheme OurProject -configuration Debug -workspace OurProject.xcworkspace/ build

The next step would be to archive the build. This step yields a .xcarchive file

xcodebuild -scheme OurProject -configuration Debug -workspace OurProject.xcworkspace/ archive -archivePath $PWD/build/OurProject.xcarchive

For this next Export step,.

Our .ipa file can now be exported from our .xcarchive file by running the command

xcodebuild -exportArchive -archivePath $PWD/build/OurProject.xcarchive -exportOptionsPlist OptionsPlist.plist -exportPath $PWD/build

altool is another command line tool that we would use to upload our .ipa file. The altool, like other command-line tools ship with xcode and we do not have to download it. The default path to altool is /Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Support/altool

This path would be needed to point to altool when we need to upload our .ipa file to Itunes connect. For this step we would need our apple id Username and Password.

$pathToAlTool --upload-app -f $PWD/build/$OurProject.ipa -u $username -p $password

After following the steps, your build should be ready to process on Itunes Connect.

Using a Bash Script

The above steps have been made into a bash script. We can skip the 2nd and 3rd steps and simply download this in your root directory .

You will need to know your AppScheme , the proposed version Number, username and App Specific Password.

(The App specific password can be gotten from appleid.apple.com. This can be used in place of your team password).

Run the script by running this command from terminal and follow the prompts.

./internalRelease.sh

Next Steps

Subsequently, we would look at how this script can be integrated into a full Continuous Delivery/ Continuous Integration Process with a build server of our choice and discuss adaptability to other Automation Build Systems.