Centralized Build Methods for iOS Applications: Strategies, Tools, and Automation

Abstract Centralized building, as the name suggests, means performing builds together and forms the foundation for continuous integration, continuous deployment, and continuous delivery practices. With the growing prevalence of smartphones, iOS has become a critical platform, and its unique system and frequent app iterations have led to many pitfalls in implementing centralized iOS builds. Based on extensive project practice, this paper proposes two centralized build methods suitable for different project scenarios, aiming to achieve fully automated builds that generate installable artifacts, manage certificates and code efficiently, reduce unnecessary interaction, improve production efficiency, and provide prerequisites for testing and automated deployment.

1. Research Background

Apple operating systems mainly include macOS and iOS. Development languages are Objective‑C, Swift, and JavaScript, compiled with the LLVM framework using Clang as the front‑end compiler.

Current iOS applications are primarily developed with Objective‑C and JavaScript. Apple issues two types of certificates—company and enterprise—to ensure secure transmission and control distribution channels. Certificate management heavily impacts daily development and production, and differs significantly from existing centralized build systems, making centralized iOS builds an urgent need.

2. Technical Terminology

2.1 Compilation

The compilation process generally consists of four stages:

Pre‑process : macro replacement, comment removal, header expansion, producing .i files.

Compiling : transforms .i files into assembly, producing .s files.

Assembly : converts .s files into machine code, producing .o files.

Link : links .o files and libraries to generate the final executable.

2.2 Development Languages

iOS development languages include C, Objective‑C, Swift, and JavaScript.

Objective‑C : an object‑oriented extension of C with a small runtime library, fully compatible with C, compiled by GCC or Clang.

Swift : introduced at WWDC 2014, co‑exists with Objective‑C, compiled by LLVM (front‑end Clang) supporting C, C++, Objective‑C, and Objective‑C++.

JavaScript : used via the JavaScriptCore framework (iOS 7+), enabling hybrid apps where native code and web components coexist, offering fast bug fixes and version iteration without recompilation.

2.3 iOS Build and Release Elements

iOS build typically passes three stages: Xcode debugging, device debugging, and compilation for release. Apple uses provisioning profiles—comprising certificates, identifiers, and devices—to control which devices can run or debug the app.

Certificates : development and distribution certificates issued by Apple, forming the basis of iOS app security.

Identifiers : unique app IDs (Bundle ID) used across Member Center, Xcode project, and iTunes Connect.

Devices : a whitelist of test devices (max 100) that can install the app during debugging.

Provisioning Profiles : combine the above three elements to describe the app’s signing configuration.

3. Problem Description

Compared with open‑platform builds, iOS builds face several challenges:

Complex build process : multiple targets, numerous steps, and varied commands make centralized adoption difficult.

Special build environment : builds must run on macOS with specific Xcode versions; upgrading Xcode for centralized builds is a constraint.

Diverse version‑control tools : projects use Git, SVN, etc., without a unified management mechanism, affecting code quality and traceability.

cumbersome certificate management : each app requires unique certificates and provisioning profiles, hindering large‑scale testing and automated packaging.

To address these issues, the paper proposes two centralized build methods and a systematic analysis of build logs.

4. Solution

4.1 Build Log Analysis

Manual builds and log analysis reveal two typical iOS build scenarios:

Single‑certificate with a single provisioning profile.

Single‑certificate with two provisioning profiles (e.g., for push extensions).

Common Xcode build commands identified include:

CompileC : compiles .m and .c files to .o .

Libtool : creates static libraries ( .a ).

CreateUniversalBinary : merges .a files into a universal binary.

Ld : links objects to produce the final .ipa package.

Xcode’s build control is divided into Build Settings, Build Phases, and Build Rules, each governing different aspects of the compilation pipeline.

4.2 Centralized Build Method Research

Both build scenarios follow a rule‑based approach where invoking a primary target builds the entire project and generates the .ipa . Automation relies on the .xcodeproj file and Xcode command‑line tools.

1) Single‑Certificate Single‑Profile Mode

This straightforward mode requires arranging build commands with the appropriate certificate and provisioning profile. Typical command line:

usr/bin/xcodebuild
-sdk iphoneos12.2
-configuration Release
-project /Users/abc2/APP/ABC.xcodeproj
-scheme ABC
clean
archive
-archivePath /Users/abc2/APP
CODE_SIGN_IDENTITY=iPhone Distribution: AGRICULTURAL BANK OF CHINA
PROVISIONING_PROFILE=XXXX-XXXX-XXXX-XXXX

Additional variant adds a keychain path for certificate access:

usr/bin/xcodebuild
-sdk iphoneos12.2
-configuration Release
-project /Users/abc2/APP/ABC.xcodeproj
-scheme ABC
clean
archive
-archivePath /Users/abc2/APP
OTHER_CODE_SIGN_FLAGS=--keychain=/Users/abc2/_xcodetasktmp.keychain
CODE_SIGN_IDENTITY=iPhone Distribution: AGRICULTURAL BANK OF CHINA
PROVISIONING_PROFILE=XXXX-XXXX-XXXX-XXXX

2) Single‑Certificate Dual‑Profile Mode

This more complex mode cannot use a single‑profile command. The solution splits the process into two stages: first build the archive, then export using an ExportOptions.plist that references both provisioning profiles.

Build stage:

/usr/bin/xcodebuild
-sdk iphoneos12.2
-configuration Release
-project /Users/abc2/APP/ABC.xcodeproj
-scheme ABC
clean
archive

Export stage:

/usr/bin/xcodebuild
-exportArchive
-archivePath /Users/abc2/APP/ABC.xcarchive
-exportPath /Users/abc/iphoneos12.2/Release/_XcodeTaskExport_APP
-exportOptionsPlist /Users/abc/ios/APP/Resources/ExportOptions.plist

The ExportOptions.plist is generated after a successful manual build and contains the mapping of the two provisioning profiles, enabling fully automated packaging.

5. Conclusion

After more than a year of practice, the iOS centralized build solution achieved full coverage for production projects, establishing a standardized build model. Two methods were formalized: “build command + tool parameters + project path + main target + certificate + provisioning profile” for single‑profile projects, and “build command + tool parameters + project path + main target + ExportOptions.plist” for dual‑profile projects.

By injecting certificates and provisioning files during compilation, the process reduces manual hand‑offs, improves developer efficiency, enhances quality, and creates a repeatable, standardized build‑release workflow.

Future work will continue to deepen and expand the centralized build achievements, exploring further automation opportunities.