The best CI/CD platforms for Capacitor apps in 2026
GitHub Actions, GitLab CI, Codemagic, Bitrise and Xcode Cloud compared for Capacitor: macOS builds, signing, cost and setup effort. Plus the step most pipelines are missing: shipping web changes without a store build.
A Capacitor app needs two kinds of builds. The native build compiles the iOS and Android shells, signs them and uploads them to the stores. The web build is your framework's npm run build. Most CI guides treat them as one pipeline, which is why most Capacitor teams wait for a full native build and App Review to ship a one-line CSS fix.
This comparison covers the five platforms Capacitor teams actually use in 2026, what each is good at, and how to add the missing step: shipping web-only changes straight to users.
If you are leaving Ionic Appflow: Appflow's native builds map onto any platform below. Its Live Updates need a separate replacement. See Ionic Appflow is shutting down.
The short answer
| Platform | Best for | macOS builds | Setup effort |
|---|---|---|---|
| GitHub Actions | Teams already on GitHub who want full control | Hosted Apple silicon runners | Medium: you write the signing steps |
| Codemagic | Mobile-first teams who want Capacitor presets and managed signing | Hosted Apple silicon machines | Low |
| Bitrise | Larger teams wanting a visual workflow editor and many integrations | Hosted Apple silicon machines | Low to medium |
| GitLab CI | Teams on GitLab, including self-managed runners | Hosted macOS runners on paid tiers, or your own Mac | Medium |
| Xcode Cloud | iOS-only builds tightly tied to App Store Connect | Apple-hosted, iOS only | Low for iOS, no Android |
Pricing changes often, so check each provider's current page. The general shape: macOS minutes cost several times more than Linux minutes everywhere, so keep Android builds and web builds on Linux and send only the iOS job to a Mac.
GitHub Actions
The default choice for most teams. Your code is already there, the marketplace has actions for everything, and you can run Linux and macOS jobs in one workflow. The cost is that iOS signing is your job: importing certificates into a temporary keychain, installing provisioning profiles, or using an App Store Connect API key with automatic signing.
We have step-by-step guides for iOS builds and signing and Android builds.
Codemagic
Built for mobile, with explicit support for Ionic and Capacitor projects. Its main advantage is code signing: it can fetch or create certificates and profiles from App Store Connect for you, which removes the most error-prone part of iOS CI. Configuration is a codemagic.yaml in your repo or a UI workflow. A good fit for small teams who want iOS builds working this afternoon.
Bitrise
A mature mobile CI with a visual workflow editor and a large library of steps (testing, signing, store upload, notifications). It suits teams with several apps and people who are not CI specialists. For a single small Capacitor app, it can feel like more platform than you need.
GitLab CI
If your code lives on GitLab, stay there. Android and web jobs run on standard Linux runners. For iOS, use GitLab's hosted macOS runners on a tier that includes them, or register a Mac of your own as a runner. See GitLab CI for Capacitor live updates.
Xcode Cloud
Apple's own CI, included with a number of compute hours in the Apple Developer Program. Signing and TestFlight distribution are handled for you. It only builds for Apple platforms, so you still need a second system for Android, and a Capacitor project needs a custom script to install Node and run the web build before Xcode builds.
The step most pipelines are missing
Whichever platform you choose, look at what actually changes in a typical week. In most Capacitor apps it is the web layer: screens, copy, styles, business logic. The native shell changes a few times a year, when you add a plugin or upgrade Capacitor.
So split the pipeline. Run the native build on tags or when native files change. Run a web release on every merge to main:
# .github/workflows/ota.yml
name: OTA release
on:
push:
branches: [main]
paths-ignore: ['ios/**', 'android/**']
jobs:
ota:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm run build
- run: npx @otakit/cli upload --release staging --fail-on-incompatible
env:
OTAKIT_TOKEN: ${{ secrets.OTAKIT_TOKEN }}This job runs on a cheap Linux runner in about a minute and never touches a Mac. The --fail-on-incompatible flag stops the release if the web build needs native changes that are not in the store build yet, so a missing plugin cannot reach devices. Promote to production when staging looks good:
npx @otakit/cli release <bundleId> --channel production
See the CI/CD docs for token setup and the same flow on other platforms, and automating channel promotion for a gated staging-to-production pipeline.
How to choose
- Code on GitHub, comfortable with YAML: GitHub Actions.
- Want iOS signing handled for you: Codemagic.
- Several apps, mixed-skill team: Bitrise.
- Code on GitLab: GitLab CI.
- iOS only, want Apple to manage it: Xcode Cloud, plus something else for Android.
Then add the OTA job, whatever you picked. Faster native CI saves minutes. Not needing a native build for most releases saves days. OtaKit has a free tier, so you can add it to an existing pipeline today and see the difference on your next release.