Our AppCenter setup provides a turnkey CI/CD integration for mobile apps, including automated iOS and Android builds, YAML pipelines, Device Farm testing, and post-build scripts using environment variables. When developing a mobile app with SwiftUI, Firebase integration, and push notifications, manually building each version for iOS and Android takes up to 4 hours per day. Two weeks into the project, the team spends 30% of its time on repetitive operations: code signing, environment configuration, and uploading to TestFlight. We set up CI/CD in Microsoft AppCenter so that every build runs automatically: on a Git push, with UI tests on real devices and delivery to testers. The entire process takes 2–5 days, not weeks. In that time, you get a reliable pipeline that reduces release time by 70% and cuts testing infrastructure costs by up to 50%. Typical setup cost is $500–$1500, with annual savings up to $20,000 in manual labor.
Why AppCenter Is a Convenient Choice for CI/CD?
AppCenter solves three key tasks: build, testing on real devices (Device Farm), and distribution. Unlike Jenkins or GitLab CI, you don't need to manage infrastructure — the service provides macOS and Windows virtual machines, as well as iOS/Android devices. According to Microsoft documentation, AppCenter supports all popular frameworks: SwiftUI, Jetpack Compose, Flutter, and React Native. The only limitation is complex matrix builds and custom images, which we address by combining it with an external CI (e.g., GitHub Actions).
Configuring a Build Using YAML
AppCenter supports appcenter.yml — the most flexible way to describe a pipeline. Follow these steps for an iOS app with manual signing:
- Define trigger branches (e.g., main, release/*).
- Specify the VM image (macos-latest).
- Add tasks to install Apple certificate and provisioning profile.
- Run CocoaPods installation.
- Use Xcode build task with signing options.
Example YAML:
trigger: branches: include: - main - release/* pool: vmImage: macos-latest steps: - task: InstallAppleCertificate@2 inputs: certSecureFile: distribution.p12 certPwd: $(P12_PASSWORD) - task: InstallAppleProvisioningProfile@1 inputs: provisioningProfileLocation: secureFiles provProfileSecureFile: MyApp_AppStore.mobileprovision - script: | cd ios && pod install --repo-update displayName: 'Install CocoaPods' - task: Xcode@5 inputs: actions: 'build' scheme: 'MyApp' xcWorkspacePath: 'ios/MyApp.xcworkspace' exportPath: '$(Build.ArtifactStagingDirectory)' exportOptions: 'plist' exportOptionsPlist: 'ios/ExportOptions.plist' signingOption: 'manual' signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)' provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)' If YAML is not available, we use appcenter-post-build.sh — it runs after a successful build. For example, to send the build to a QA group:
#!/usr/bin/env bash appcenter distribute release \ --app "$APPCENTER_APP_ID" \ --file "$APPCENTER_OUTPUT_DIRECTORY/MyApp.ipa" \ --group "QA Team" \ --release-notes "Build $APPCENTER_BUILD_ID" curl -X POST "$SLACK_WEBHOOK_URL" \ -H 'Content-type: application/json' \ --data "{\"text\":\"New build $APPCENTER_BUILD_ID is available\"}" The APPCENTER_* variables are built-in environment variables available during the build step.
Protecting Secrets and Managing Environments
In Build Configuration → Environment Variables, keys are added. Sensitive values are marked as "Secret" — they are encrypted and not displayed in logs. Standard set:
| Variable | Purpose |
|---|---|
P12_PASSWORD |
Password for iOS certificate |
KEYSTORE_PASSWORD |
Password for Android keystore |
FIREBASE_APP_ID |
App ID in Firebase |
SLACK_WEBHOOK_URL |
URL for Slack notifications |
AppCenter guarantees that secrets do not appear in build logs.
Testing on Real Devices
Device Farm runs XCUITest and Espresso on physical iPhones and Android smartphones. Command to upload tests:
appcenter test run xcuitest \ --app "MyOrg/MyApp-iOS" \ --devices "MyOrg/top-ios-devices" \ --test-series "main" \ --locale "ru_RU" \ --build-dir DerivedData/Build/Products/Debug-iphoneos Device Farm Details
Devices are selected in the UI — you can prioritize specific models and OS versions. This is faster than setting up your own farm: savings up to 30% on testing budget.
| Platform | Available Devices | Limitations |
|---|---|---|
| iOS | iPhone 12-14, iPad Pro | Max 30 min per test |
| Android | Samsung Galaxy S21-S24, Pixel 5-7 | Up to 5 devices in parallel |
Problems AppCenter Setup Solves
The first problem is manual code signing for iOS. Each release requires updating provisioning profiles and certificates. We automate this process with InstallAppleCertificate and InstallAppleProvisioningProfile, eliminating build errors.
The second problem is lack of testing on real devices. Simulators don't always reproduce bugs related to memory or network. Device Farm runs tests on 5+ physical devices, increasing coverage by 40%.
The third problem is delays in distribution. Manually sending a build to testers via TestFlight takes up to an hour. A post-build script sends the IPA/APK directly to AppCenter groups, notifying the team in Slack within a minute.
Project Structure in AppCenter
Each app gets its own "app" inside the organization. Typical hierarchy:
MyCompany (Organization) ├── MyApp-iOS (App) │ ├── Build (CI) │ ├── Test (Device Farm) │ ├── Distribute │ └── Diagnostics (Crashes) └── MyApp-Android (App) ├── Build (CI) ├── Distribute └── Diagnostics This structure simplifies access management — testers see only their apps.
AppCenter CI Limitations and How We Work Around Them
AppCenter does not support matrix builds (multiple configurations in one job) or custom Docker images for Android. In such cases, we keep only distribution and crash analytics in AppCenter, implementing the complex pipeline via GitHub Actions. You get the best of both worlds: the flexibility of an external CI and the convenience of AppCenter for delivery to testers.
What's Included in the CI/CD Setup?
Upon completion, you receive:
- A working AppCenter pipeline with triggers on main/release branches
- Configured iOS signing (certificates and provisioning profiles)
- UI tests on Device Farm (up to 5 devices per platform)
- Automatic distribution to tester groups (TestFlight/Google Play on request)
- Environment variables for secrets (API keys, certificates)
- Post-build scripts for notifications and distribution
- Documentation of the process and support contacts
- 1 hour of training for your team
Timeline and Pricing
The estimated timeline is 2 to 5 days, depending on project complexity. Pricing is calculated individually after an assessment. Our team has 5+ years of mobile development experience and has implemented CI/CD for 20+ projects. Order the setup — get a CI/CD setup consultation today.