Skip to main content

Mobile Build

Overview​

モバイル開発のビルド手法をまとめたセクション。

ネイティブAPIのバージョンと最低サポートOSのバージョン​

iOSアプリ、Androidアプリとしてビルドする際にバージョンを指定する。

  • 最低サポートOSのバージョン
  • ビルドSDKバージョン
  • ターゲットSDKバージョン（Androidのみ）

最低サポートOSのバージョン​

最低サポートOSのバージョンはアプリをインストールできる最低のOSバージョン。
このバージョンを低く保つことでより多くのユーザーがアプリを利用できることになりますが、その分古いOSでの挙動についても考慮する必要がある。
iOSについてはAppleのデベロッパーサイトにてバージョン別のシェアが公開されており、この数値を参考にするとよい。
AndroidについてはAndroid Studioの新規プロジェクト作成時にバージョン別のシェアを確認できる。

最低サポートOSのバージョンを決める際には、いくつかの要素を考慮する。
一般的には次のような基準で決定されることが多い。

  1. ユーザーシェア 対象プラットフォームのOSバージョン別のシェアを確認する。
    例えば、iOSやAndroidの各バージョンの利用割合は公表されており、対象ユーザーのほとんどが使用しているバージョン以上をサポートするのが一般的。
    古いバージョンのユーザーが少ない場合は、それらをサポート対象外にすることが多いです。
  2. プラットフォームの公式ガイドライン AppleやGoogleは、定期的に古いOSバージョンのサポートを終了するため、最新のベストプラクティスに従うことが推奨されている。
    特に、App StoreやGoogle Play Storeでの申請には最新のOSバージョンに対応したSDKが必要になる場合もある。
  3. 使用するサードパーティライブラリ 使いたいライブラリが特定のOSバージョン以降でしかサポートされていない場合、そのバージョンを最低限サポートしなければならない。
    また、新しいOSでのみ使える機能を活用したい場合も、最低サポートバージョンを上げることがある。
  4. アプリのパフォーマンス 最新OSでは性能が最適化されていることが多く、パフォーマンス重視のアプリでは新しいOSバージョンをサポート対象とする傾向がある。

ビルドSDKバージョン​

ビルドSDKバージョンはビルド時に使用するSDKのバージョンで、このバージョンを上げることで新しいネイティブAPIを利用することができる。
ただし、このバージョンを上げると古いOSで挙動が変わることがあるため注意が必要。

caution

この挙動の変化は特にAndroidに多く見られる。

アプリバージョンとビルド番号​

Flutterアプリでは、pubspec.yaml に version フィールドを定義することで、アプリのバージョンとビルド番号を管理します。

version: 1.2.3+45
  • 1.2.3: 表示用のバージョン名（ユーザー向け）
  • +45: 内部的なビルド番号（App Store / Google Play での識別に使用）

ビルド番号の重要性​

iOS・Androidともに、アプリをアップデートする際に ビルド番号が前回より大きくなっている必要があります。これを怠るとストアへのアップロードが拒否されます。

  • iOS（CFBundleVersion）
  • Android（versionCode）

FlutterではCLI引数で上書きすることも可能です：

flutter build apk --build-name=1.2.4 --build-number=46
flutter build ios --build-name=1.2.4 --build-number=46

CI/CDにおける自動更新の慣例​

ビルドごとにバージョンやビルド番号を更新する場合、次のようなアプローチがよく使われます：

  • Gitのタグを build-name に使用し、コミット数やCIのビルド番号を build-number にする
  • pubspec.yaml をCIで書き換えるスクリプト（Perlやsedなど）を用意する
  • Dartの pub_version_plus パッケージでCLIからのインクリメントを行う

CIでの例（GitHub Actions）：

- name: Set version from tag
  run: |
    VERSION=${GITHUB_REF#refs/tags/v}
    echo "version: ${VERSION}+${GITHUB_RUN_NUMBER}" > pubspec.yaml

これにより、安定して連番かつ一意なバージョン管理が可能になります。

iOSのビルドSDKバージョンの設定​

iOSには実はビルドSDKバージョンという考え方はない。
Xcodeのバージョンによって使用できるAPIが変わる。
Xcodeのバージョン変更により、Flutterアプリの挙動が大きく変わることはまれだが、バージョンを上げる際は慎重に動作確認する。

AndroidのビルドSDKバージョンの設定​

AndroidのビルドSDKバージョンはアプリのビルド構成ファイル android/app/build.gradle に記述する。
androidエントリのcompileSdkVersionが該当する。

Androidは gradle というビルドツールを使用しており、Androidプロジェクトを構成するために Android Gradle Plugin というプラグラインを使用している。
gradle のバージョン、Android Gradle Pluginのバージョンn

info
  • gradleのバージョン
  • Android Gradle Pluginのバージョン
  • compileSdkVersion

上記はそれぞれは互いに依存関係がある。
compileSdkVersionのみを変更するとビルドできないこともある。
また compileSdkVersionを変更する際はAndroidの公式ドキュメントを参照し、動作の変更点をチェックする必要がある。

ターゲットSDKバージョン​

note

Androidのみに存在する概念。

アプリを動作させたいSDKバージョンを指定する。
SDKのバージョンによって見た目や挙動が変わることがあるためどのバージョンで動作させる想定なのかを明示する設定になる。

tip

Google Play Storeでは、このtargetSdkVersionを毎年新しいバージョンに引き上げることを必須要件として開発者に課している。
targetSdkVersionを更新しなければ、アプリをアップデートできなくなったり、新しいOSのAndroidからはストアでアプリを検索できなくなったりする。

ビルドと証明書の流れ​

1. アプリのビルド ⇨ 証明書の流れ（iOS/Android）​

FlutterやReact Nativeを使ったクロスプラットフォーム開発においても、最終的には各プラットフォーム固有の形式（iOSなら .ipa、Androidなら .apk / .aab）でビルドされます。これらの成果物を配布・公開するためには、「証明書（コード署名）」が必要です。

iOSの場合​

  • flutter build ios や xcodebuild を実行すると、Xcodeプロジェクトがビルドされる。
  • この時点では、まだ最終的なApp Store配布用 .ipa は生成されていない（署名なし or 開発用署名）。
  • App StoreやTestFlightにアップロードするには、「本番用署名」が必要になる。
  • 通常は以下の2パターンで署名を行う：
    • 手動：Apple Developerサイトからプロファイル・証明書を取得し、Xcodeの設定で管理。
    • 自動（推奨）：Cloud-managed certificates を使い、Appleに証明書管理を委ねる。
  • Fastlaneの build_app や gym コマンドを使うことで、証明書の管理・署名・.ipa の生成を自動化できる。

Androidの場合​

  • flutter build apk または flutter build appbundle を使うことで、署名付きまたは未署名の成果物を出力できる。
  • 本番用の署名を行うには、android/app/ 以下に key.properties を設置し、build.gradle の signingConfigs を構成する。
  • CI/CDでは環境変数としてキー情報を渡すことで安全に署名処理ができる。
  • Fastlaneの gradle コマンド経由でビルド・署名・アップロードまで一貫して自動化可能。

このように、ビルドの最終工程における署名処理は、プラットフォームごとに異なるが、Fastlaneを活用することで統一的かつ安全に運用できる。

手法​

モバイルアプリのビルド手法には、目的やプロジェクトの要件によっていくつかの方法があります。大きく分けると、以下のような手法が存在する。

1. ローカルビルド​

自分のPCで直接ビルドを行う方法。

  • メリット

    • すぐに試せる（手軽にビルド＆テストが可能）
    • CI/CDの設定が不要
    • ネイティブの設定やデバッグがしやすい

  • デメリット

    • 環境構築が必要（Xcode, Android Studio, 各種SDKのセットアップ）
    • 複数人で開発する場合に環境差異が出る
    • 自動化されていないので手間がかかる

  • 代表的なツール

    • Xcode（iOS）
    • Android Studio（Android）
    • react-native run-ios / react-native run-android
    • flutter build ios / flutter build apk

2. CI/CDを利用したビルド​

CI/CD（継続的インテグレーション & デリバリー）を使ってビルドを自動化する手法。

  • メリット

    • 複数人の開発環境が統一される
    • 毎回手動でビルドする必要がなくなる
    • 自動テストやリリースのワークフローと連携しやすい

  • デメリット

    • 設定が必要（GitHub Actions, Bitrise, Codemagicなど）
    • ネイティブの設定変更があった場合、適切に対応しないとビルドが失敗する

  • 代表的なサービス

    • GitHub Actions GitHubと連携しやすい。YAMLでワークフロー管理。
    • Bitriseモバイル特化のCI/CD。GUIで設定しやすい。
    • Codemagic Flutter開発に特化。
    • EAS Build (Expo) Expo向けの公式ビルド環境。
    • Fastlane iOS/Androidの自動化ツール（CI/CDと組み合わせて利用）。

3. クラウドビルドサービス​

ローカル環境ではなく、クラウド上でビルドを行う方法。

  • メリット

    • 環境構築が不要
    • Macを持っていなくてもiOSアプリがビルドできる（M1 Mac必須のビルドでも使える）
    • CI/CDの一部として利用できる

  • デメリット

    • 無料枠に制限がある（ビルド回数・時間）
    • クラウド側の障害で影響を受ける

  • 代表的なサービス

    • EAS Build Expo向けのクラウドビルド
    • App Store Connect (Xcode Cloud) Apple公式のクラウドCI/CD
    • Firebase App Distributionテスター向けの配布サービス付き
    • TestFlight Apple公式のベータ版配布サービス

4. Over-the-Air (OTA) 更新​

アプリをストアの審査なしで更新できる手法。

  • メリット

    • JavaScript/TypeScriptの修正を即時リリース可能（React Native）
    • アップデートの手間を減らせる

  • デメリット

    • ネイティブコードの変更は不可
    • Appleのガイドライン変更で利用制限があるかも（将来的なリスク）

  • 代表的なツール

    • CodePush (2025年3月終了予定) App CenterのOTA更新（React Native向け）
    • EAS Update Expoの公式OTA更新
    • Firebase Remote Config一部の機能を動的に変更可能

どのビルド手法を選ぶべきか？

  • ローカルビルド → 開発初期や簡単な確認
  • CI/CDビルド → チーム開発or自動化したい場合
  • クラウドビルド → ローカル環境の依存を減らしたい場合
  • OTA更新 → JavaScriptレイヤーのみの即時更新が必要な場合

特にExpo EAS Build + EAS Updateは、今後React Nativeでのアプリ開発の主流になりそう！

Resource​

Last updated on