Best CI/CD for mobile apps in 2026: a practical comparison(要旨)
チームがモバイルアプリをビルドしてリリースするとき、多くはCI/CDプロセスでつまずきます。iOSアプリをビルドしてApp Storeに提出するためだけで500行を超えるYAMLを使っているチームを見てきました。モバイルアプリを継続的に配信するにはドメイン固有の知識が多く必要で、設定の作成・保守・改善はしばしば専任作業になりがちです。
一般的なCI/CDサービスは何でも走らせられるように作られているため、動作はしますがモバイル向けに細やかに最適化されたツールとは言えません。開発者や企業が同じことを実現するために複雑なYAMLを何度も書き直すのを何度も見てきたので、私たちはモバイル特有の機能を上に載せた汎用CI/CDを作りました。
EAS Workflows(Expo)の「CI/CD Workflows」は、ビルドや提出などを10行未満のYAMLで記述できることを目標にしています。iOS/Androidビルドキャッシュなど、開発者が何も変えなくてもビルドが速くなるジョブも用意されています。サービスの詳細は公式ドキュメントやブログを参照してください。
この記事では、2026年時点で人気のあるモバイル向けCI/CDオプションを比較します。各ツールの得意な点、不得意な点、そしてチームや技術スタックに応じた選び方を解説します。なおExpo(EAS)は利害関係があるためバイアスはありますが、他ツールが勝る点は正直に述べます。
モバイルCI/CDを評価する際のポイント
モバイルチームにとって重要な機能は次のとおりです:
- ビルド速度(Apple Silicon)
- iOSビルドは多くのチームでボトルネックです。M1で20分、M4 Proで6分という差は、フィードバックループが保てるか開発者が別作業へ切り替えるかの差になります。
- コード署名と認証情報
- Android/iOSのコード署名は厄介です。サービスJSON、プロビジョニングプロファイル、証明書の保管・更新がチームの足を引っ張ることがあります。
- アーティファクトの保管
- ビルドやOTAアップデート後にレビュアーへ共有したり、アプリストアへ送るためのアーティファクト管理が重要です。
- 設定の複雑さと保守性
- モバイル固有のジョブは設定が膨らみやすく、最適化やバグ対応のコストになります。
- コスト構造
- 課金モデルは分単位、ビルド単位、クレジット制など様々。表面上の料金だけでは実際の運用コストは分かりません。
モバイルCI/CDの比較
EAS Workflows (Expo)
EAS Workflowsは私たち(Expoチーム)が作ったモバイル向けCI/CDサービスです。ビルド、提出、OTAアップデート、E2E、その他のプリパッケージ済みジョブを備えています。
-
得意な点:
-
高品質な部品を組み合わせるようにCI/CDを設計できます。例えば、M4 ProのApple SiliconでiOSビルドを6行程度のYAMLで作成できます。
-
ネイティブ層に変更がない場合はフルビルドをスキップしてrepack(既存のネイティブバイナリに新しいJavaScriptバンドルを載せる)するなど、典型的なiOSビルドを約10分から2分(または秒単位)に短縮できます。
-
設定がコンパクト。例としてフルCIパイプラインは次のようになります:
name: deploy-to-production
on:
push:
branches: [main]
jobs:
build_ios:
type: build
params:
platform: ios
profile: production
upload_to_app_store:
needs: [build_ios]
type: testflight
params:
build_id: ${{ needs.build_ios.outputs.build_id }}
-
事前パッケージされたジョブタイプはモバイル特有のもの:build, submit, update, repack, fingerprint, maestro (E2E testing), testflight, deploy(webホスティング), slack など。プラットフォーム固有の複雑さを抽象化します。
-
欠点:
- EAS Workflowsは主にReact NativeとExpoプロジェクト向けに設計されています。Swift/Kotlinや純粋なWebアプリの場合は他サービスと似た体験になります。
- GitHub ActionsやCircleCIのようなコミュニティ作成プラグイン群はありません。
- 無料で試せますが、料金はStarterが$19/月($45分のビルドクレジット含む)。本番利用を想定するならProductionプラン($199/月、$225分のビルドクレジット、2同時ビルド)が必要になることが多いです。詳細はPricingを参照してください。
-
向いているチーム:
- React Native / Expoプロジェクトで、ビルド、提出、OTAアップデートまで一気通貫のモバイル特化CI/CDを求めるチーム。
Bitrise
Bitriseもモバイル専用のCI/CDプラットフォームで、iOS, Android, React Native, Flutterなどをサポートします。
-
得意な点:
- モバイル向けのプリビルトステップライブラリが最大級です。コード署名ウィザード、自動プロビジョニング、ビジュアルなワークフローエディタにより、深いDevOps知識がないチームでも使いやすいです。
- マトリクスビルド、再利用可能なワークフロー設定、AIによるビルド失敗要約や自動修復機能などが追加されています。
- iOSジョブではM2 Proマシン(EnterpriseではM4 Pro)を提供しており、ビルドやE2Eテストが高速です。
- React Native以外のネイティブフレームワークも幅広くサポートします。
-
欠点:
- fingerprint、repacking、Maestroのテスト解析ダッシュボードのような一部の機能はビルトインで欠けています。
- 最速のMacハードウェアはEnterpriseプランでのみ提供される場合があります。
-
向いているチーム:
- ネイティブとクロスプラットフォームの混在プロジェクトを一つの場所で扱いたい、成熟したエコシステムとビジュアルエディタを求めるチーム。
Codemagic
CodemagicはもともとFlutter向けに作られ、現在はReact Native、iOS、Androidもサポートしています。
-
得意な点:
- M2/M4マシンを提供し、M4 Pro/Maxは上位プラン向けに用意されています。
- iOSの自動コード署名がよく実装されています。
- 従量課金(pay-as-you-go)のモデルは小規模チームにコスト効率が良い場合があります。固定価格プランもあり、利用量次第では大幅にコストを下げられます。
- MicrosoftのAppCenter終了に伴い、CodePushサポートが追加されている点は有用です。
-
欠点:
- fingerprintやrepackによるビルドスキップが組み込みではないため、いつフルビルドが要るかは自分で管理する必要があります。
-
向いているチーム:
- Flutter中心のチーム、あるいは分かりやすい料金体系を求めるReact Nativeチーム。
GitHub Actions
GitHub ActionsはGitHub利用チームのデフォルトCI/CDで、汎用的なツールです(モバイル専用ではありません)。
-
得意な点:
- コードがGitHubにあるなら統合はシームレス。Marketplaceにはコミュニティ管理の数千のActionがあります。
- リンティング、型チェック、ユニットテストなど、非ビルド部分のパイプラインには非常に向いています。
-
欠点:
- iOSジョブはM1/M2 Pro相当の遅めのマシンで動くため、ビルドやMaestroテストが遅くなりがちです。
- 汎用CIのため、ビルド、アップデート、テスト結果などがモバイル向けに整理されたダッシュボードになりません。
- 同じことをEAS Workflowsで6行のYAMLにできるケースを、GitHub Actionsでは80〜150行のYAMLにしてしまうこともあります。
-
向いているチーム:
- すべてをGitHubに収めたい、あるいはパイプライン保守に投資できるチーム。ビルド以外のCI作業をGitHub Actionsでまとめる選択肢としても有効です。
CircleCI
CircleCIは汎用のCI/CDで、macOSエグゼキュータを通じてモバイルをサポートします。
-
得意な点:
- 高い並列化とキャッシュ機能。汎用CIとして多くのジョブを走らせることを前提に作られており、大規模チーム向けに高い同時実行数を提供します。
-
欠点:
- GitHub Actions同様、モバイルサポートは汎用プラットフォーム上に構築する形になります。
- 課金はクレジットベースなので、1回の実行あたりのコストを算出するのが難しいことがあります。
- コード署名、アプリストア提出、OTA更新のためのモバイル特化の抽象化は提供されていません。
-
向いているチーム:
- 既にCircleCIに投資しており、同じプラットフォームでモバイルビルドも扱いたいチーム。
モバイルCI/CDがWebと違う点
- コード署名は必須
- iOSはプロビジョニングプロファイルと配布証明書、Androidはkeystoreが必要で、チームでの管理に時間がかかります。
- iOSジョブにはmacOSハードウェアが必要
- これは回避不能で、iOSビルドはLinuxベースのWebビルドに比べて高コストかつ遅くなりがちです。
- アプリストア提出はデプロイの一形態
- WebのCDNプッシュとは異なり、メタデータ、スクリーンショット、審査キューなどが関わります。OTAでJavaScript変更のみを高速に配信できるかどうかが生産性に大きく影響します。
- チーム向けのプレビュー作成にはビルドが必要
- Webならプレビューリンク作成が簡単ですが、モバイルではビルドやOTA、Play Console/TestFlight共有、あるいはAd-hoc用の端末登録が必要になる場合があります。
これらの追加作業はチームのコミュニケーションコストを押し上げます。
fingerprint と repack で不要なビルドをスキップする
注目すべき手法の一つがfingerprintベースのビルドスキップ(EAS Workflowsは標準で対応)です。多くのコミットはJavaScript層のみを変え、ネイティブ依存に変更がありません。ネイティブ層に変更がない場合、フルビルドをスキップして既存のネイティブバイナリに新しいJSをrepackすることで高速にリリースできます。
これはGitHub ActionsユーザーがEAS Workflowsへ移行する大きな理由の一つです。顧客の中にはCIパイプラインを変えるつもりがなくても、fingerprintとrepackによる効率化のためにWorkflowsを採用した例が多数あります。
repackはフルビルドの10〜15分に対して約2分で済みます。1日20ビルドするチームでは、毎日約3〜4時間のビルド時間を節約できます。Infinite Redは多くのクライアントでこの手法を実装し、CI時間を半分に削減しました。
例:fingerprintワークフロー
jobs:
fingerprint:
type: fingerprint
get_build:
needs: [fingerprint]
type: get-build
params:
fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
platform: ios
repack:
needs: [get_build]
if: ${{ needs.get_build.outputs.build_id }}
type: repack
params:
build_id: ${{ needs.get_build.outputs.build_id }}
build:
needs: [get_build]
if: ${{ !needs.get_build.outputs.build_id }}
type: build
params:
platform: ios
profile: production
上のワークフローは一致するネイティブ層を持つ既存ビルドを探し、見つかれば新しいビルドを自動で作成しますが、ネイティブを再ビルドせずJavaScript層のみをrepackします。ネイティブ層に影響があればフルビルドにフォールバックします。他のモバイルCI/CDツールで標準搭載されているものはほとんどありません。
どのモバイルCI/CDを選ぶべきか
選択は主に次の要因で決まります:プロジェクトのフレームワーク、既に使っているCIプラットフォーム、CI/CDに割ける開発時間。
- React Native / Expoで、ビルド、OTA、E2E、fingerprint & repack、アプリストア提出を一つでカバーしたいならEAS Workflowsを選んでください。
- ネイティブとクロスプラットフォームを混在して出荷し、最も広いステップライブラリとビジュアルエディタを必要とするならBitriseを検討してください。
- Flutter中心、あるいは従量課金や固定プランの選択肢が重要ならCodemagicが向いています。
- すべてをGitHubに留め、非ビルド系のCI作業をまとめたい場合はGitHub Actionsが便利です。
- 既にCircleCIを導入済みで、同プラットフォームでモバイルも走らせたいならCircleCIが自然な選択です。
どのツールにも長所と短所があるため、チームの優先度(速度、管理負担、コスト、複数フレームワーク対応など)に応じて選んでください。