LASSIC Media らしくメディア
アプリのアプリ内アップデートの実装
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AndroidにはGoogle公式のIn-App Updates（Play Core経由）があり、Flexible更新とImmediate更新の2方式を使い分けられます。
- iOSにはOS標準の強制アップデートAPIが存在せず、開発者が自前でバージョン検知・更新導線を実装する必要があります。
- 古いバージョンの利用継続や重大不具合の放置を防ぐには、両OSの仕組みの違いを踏まえた設計と外注・内製の判断が欠かせません。
目次
アプリ内アップデートとは何か
アプリ内アップデートとは、モバイルアプリが起動時にアプリストア上の最新バージョンを検知し、ユーザーに更新のダウンロード・適用を促す、またはアプリの利用を継続させる前提として更新を求める仕組みを指します*1。Android・iOSともに古いバージョンを使い続けるユーザーは一定数存在するため、重大な不具合の修正やAPI仕様変更への対応を全ユーザーに行き渡らせる目的で導入されます。
本稿では、AndroidのGoogle公式機能であるIn-App Updates（Play Core経由で提供）と、iOSにおける開発者独自の実装アプローチを対比しながら、法人アプリの要件に照らした実装のポイントと外注・内製の判断軸を整理します。アプリストア自体の掲載最適化（ASO）や、CI/CDによる配信パイプラインの自動化とは異なるテーマとして、あくまで「リリース済みアプリのユーザーを最新版へ更新させる」導線設計に絞って解説します。
Android In-App Updates — FlexibleとImmediateの仕組み
Androidには、Google Playが提供する公式のIn-app updates機能があります*2。この機能はPlay Core ライブラリのAppUpdateManagerを通じて利用し、アプリ内から直接、更新の確認・ダウンロード・インストールを扱える点が特徴です。対応OSはAndroid 5.0（API level 21）以降で、Android搭載のモバイル端末・タブレット・ChromeOS端末が対象です*2。なお、APK拡張ファイル（OBBファイル）を利用するアプリはこの機能に対応していません*2。
In-app updatesにはFlexible（柔軟な更新）とImmediate（即時更新）の2つのUXフローが用意されています*2。Flexible更新は新しいバージョンをバックグラウンドでダウンロード・インストールする方式で、ダウンロード中もユーザーはアプリを継続して使用できます。新機能がコア機能でない場合や、更新を必須にしたくない場合に適した方式です。一方Immediate更新はフルスクリーンのUIフローで、ユーザーが更新を受け入れるとGoogle Playがインストールとアプリの再起動までを処理します*2。更新が完了するまでアプリの操作はできず、コア機能に関わる重要な更新に向いています。
実装では、AppUpdateManagerFactory.createでマネージャーを生成し、getAppUpdateInfoで更新情報を取得します*3。取得したAppUpdateInfoのupdateAvailabilityで更新の有無を判定し、isUpdateTypeAllowed(AppUpdateType.IMMEDIATE)またはisUpdateTypeAllowed(AppUpdateType.FLEXIBLE)で、その端末・状況で該当の更新方式が許可されているかを確認したうえでstartUpdateFlowForResultを呼び出す流れです*3。Flexible更新ではダウンロードの進捗をInstallStateUpdatedListenerで監視し、ダウンロード完了後にcompleteUpdateを呼んでインストールを完了させます*3。
更新の緊急度を判定する材料として、AppUpdateInfoにはclientVersionStalenessDays（Google Playで新バージョンが公開されてからの経過日数）とupdatePriority（0〜5の優先度。開発者がGoogle Play Developer APIのinAppUpdatePriorityで設定する値）が用意されています*3。これらを組み合わせ、「公開から一定日数が経過し、かつ優先度が高い場合はImmediateへ切り替える」といった判定ロジックを組めます。ただし優先度の具体的なしきい値設計は各アプリの要件次第であり、公式ドキュメントが特定の日数・優先度の推奨値を示しているわけではない点には注意が必要です。
iOSに標準の強制アップデートAPIが無い理由
iOSとApp Store Connectには、Androidの In-app updates に相当する「アプリ内で更新を強制するOS標準API」は用意されていません。App Store Connect側で開発者が行えるのは、新しいバージョンのビルドを審査に提出し、承認後にリリースする一連の手順です*4。新バージョンは既存のアプリレコードに対して連番のバージョン番号を割り当てて作成し、旧バージョンへ差し戻すことはできません*4。つまりストア側の仕組みは「最新版を公開する」ところまでで、個々の端末に更新を強制的に適用する機能は含まれていません。
ユーザー側の端末設定では、App Storeアプリの「App Update」（自動アップデート）をオンにしていれば新バージョンは自動的にバックグラウンドで更新されます*5。しかし、この設定はユーザー自身がオフにできるため*5、開発者側から特定のユーザーに更新を強制する手段としては機能しません。Apple Developer Forumsでも「ユーザーに更新を強制することはできず、更新はユーザーが選択した場合にのみ自動で行われる」という趣旨のやり取りが交わされており、セキュリティ上の重大なリスクなど限定的な場面を除き、更新は基本的にユーザーの意思に委ねられる仕組みであることがうかがえます*6。
この差は、AndroidとiOSでアプリ配布・更新管理の思想が異なることに由来します。したがって法人向けアプリで「最新版以外を使わせない」という要件を満たすには、iOS側では開発者がアプリ内に自前の仕組みを組み込むほかありません。次の章では、その具体的な実装アプローチを整理します。
iOSでのバージョン検知・更新導線の自前実装
iOSアプリ内アップデートとは、開発者が独自にApp Store上の最新バージョン情報を取得し、現在起動中のアプリのバージョンと比較したうえで、更新画面への誘導や強制的な操作制限を行う実装を指します。OS標準機能がない以上、この一連の処理はすべてアプリ側のコードとして作り込む必要があります。
最新バージョンの取得手段としてよく使われるのが、AppleのiTunes Search APIが提供するLookupエンドポイントです*7。バンドルIDを指定してhttps://itunes.apple.com/lookup?bundleId=（バンドルID）にリクエストすると、該当アプリの情報を含むJSONが返り、その中のversionフィールドで現在App Storeに公開されている最新バージョンを確認できます*7。取得した値と端末にインストール済みのアプリのバージョン（CFBundleShortVersionString）を比較し、差異があれば更新案内を表示する、というのが基本的な実装パターンです。
比較の結果、更新が必要と判定した場合の導線は大きく2つに分かれます。ひとつは「後で」を選べる推奨アップデート表示で、ダイアログやバナーでApp Storeのアプリページへのリンクを提示する方法です。もうひとつは、アプリの主要機能へのアクセスをブロックするモーダル画面を表示し、App Storeへの遷移以外の操作を封じる強制アップデート表示です。後者を実装する場合、どのバージョン差分（メジャー・マイナー・パッチのどこ）で強制に切り替えるかの基準をサーバー側の設定値として持たせ、アプリの再審査なしに緊急度を調整できるようにする設計が実務上重要になります。
なお、この最新バージョン取得とApp Storeへの遷移という自前実装は、Apple Developer Forumsのディスカッションでも複数の開発者が共通して採用しているアプローチとして言及されています*8。OS標準APIがない領域だからこそ、判定ロジックの粒度やUI設計に各社の裁量が大きく残る点が、Androidとの実装難易度の違いにつながっています。
強制アップデート画面の設計で押さえる論点
強制アップデート画面を設計する際にまず失敗コストとして意識すべきは、判定ロジックの誤作動です。バージョン比較の実装を誤ると、実際には最新版であるにもかかわらず更新画面が表示され続け、アプリが一切使用できなくなる事態が起こり得ます。この種の不具合はストアレビューの低評価に直結するため、リリース前の網羅的な検証が欠かせません。
Android・iOSのいずれであっても、強制画面を設けるかどうかはサーバー側の設定で切り替え可能にしておくことが望ましいと言えます。緊急のセキュリティ修正が必要になった際に、アプリの再審査・再申請を待たずに強制フラグをオンにできる設計であれば、対応スピードを確保できるからです。Android側はGoogle Play Developer APIのinAppUpdatePriority設定で優先度を後から変更できますが*3、iOS側は自前実装のため、この可変性を自分たちで設計に組み込む必要があります。
この作業を内製で行うには、Android側でPlay Core APIとActivity Result APIの挙動理解、iOS側でネットワーク層の実装とバージョン比較ロジックの設計、さらに双方でサーバーからの設定値配信の仕組みが必要です。加えて、強制画面を挟むことでアプリのクラッシュ率やレビュー評価に影響が出ないか、リリースごとに検証する体制も求められます。片手間の対応では判定条件の考慮漏れが生じやすく、更新のたびに問い合わせ対応が発生するリスクも見過ごせません。
専門パートナーに依頼する場合、Android・iOS双方の実装パターンを踏まえた設計と、サーバー側の設定配信基盤までを一体で構築できる点が内製との違いになります。内製では担当エンジニアの知見に実装品質が左右されやすいのに対し、外部委託では複数プロジェクトでの実装経験に基づいた判定ロジックの設計を依頼できます。自社のリリースサイクルや保守体制と照らし合わせ、どこまでを内製し、どこから外部に委ねるかを見極めることが、手戻りの少ない導入につながります。
Android・iOSの実装比較
ここまでの内容を踏まえ、AndroidのIn-App Updates（Flexible/Immediate）とiOSの自前実装を比較します。両OSで「何がOS標準で用意され、何を自分たちで作り込む必要があるか」を整理すると、実装工数の見積もりがしやすくなります。
| 観点 | Android：Flexible更新 | Android：Immediate更新 | iOS：自前実装 |
|---|---|---|---|
| OS標準機能の有無 | あり（Play Core／In-app updates）*2 | あり（Play Core／In-app updates）*2 | なし。自前でバージョン検知・導線を実装*4 |
| ユーザーの継続利用 | 可能。ダウンロード中もアプリを使用できる*2 | 不可。更新完了までフルスクリーンで操作をブロック*2 | 画面設計次第。ブロックするか任意にするかを自社で決める |
| 更新の実行主体 | Google Playがバックグラウンドで実行。 ユーザーの再起動操作で反映*2 |
Google Playがインストール・再起動まで自動処理*2 | App Storeアプリへ遷移し、最終的にはユーザーが更新操作を行う*6 |
| 主なAPI・判定材料 | AppUpdateManager／isUpdateTypeAllowed／clientVersionStalenessDays／updatePriority*3 | iTunes Search APIのLookup（version値）とアプリ内バージョン比較*7 | |
| 留意点 | APK拡張ファイル（OBB）利用アプリは非対応。 Android 5.0以上が対象*2 |
判定ロジックの誤作動がアプリ全体の利用不可につながるため検証が重要 | |
外注・内製の判断軸
本稿ではモバイルアプリのアプリ内アップデート実装について、AndroidのIn-App Updates（Flexible/Immediate）とiOSの自前実装の違いを整理しました。要点を3つに集約すると、第一にAndroidはGoogle公式のAPIが用意されており実装の型が明確であること、第二にiOSはOS標準の強制アップデートAPIが存在せず自前でバージョン検知と更新導線を作り込む必要があること、第三に両OSとも強制の緊急度をサーバー側の設定で可変にできる設計が実務上望ましいことです。自社のエンジニアリソースとリリース頻度を踏まえ、どこまでを内製し、どこから外部に委ねるかを見極める判断が求められます。
よくある質問
AndroidのIn-App Updatesを導入するのに追加の審査は必要ですか。
In-App Updates自体はPlay Core ライブラリを組み込んで実装する機能で、Google Play側への特別な追加審査は必要ありません*2。ただし更新優先度（inAppUpdatePriority）の設定はGoogle Play Developer API経由で行うため、リリース管理の運用フローに組み込む必要があります*3。
iOSでも強制アップデートを実現できますか。
OS標準の強制アップデートAPIはありませんが、開発者がアプリ内にバージョン検知の仕組みを実装すれば、実質的に更新を促す画面を表示し操作を制限することは可能です*4*6。ただしユーザー自身がApp Storeで更新を完了する必要があり、Android のImmediate更新のように自動でインストールまで完了させることはできません。
AndroidのFlexible更新とImmediate更新はどちらを優先すべきですか。
新機能がコア機能に関わらない場合はFlexible更新、セキュリティ修正など緊急性の高い変更を全ユーザーに行き渡らせたい場合はImmediate更新が適しています*2。両方を状況に応じて切り替える実装も可能で、更新優先度や公開からの経過日数を判定材料にできます*3。
iOSの最新バージョン取得にiTunes Search APIを使う際の注意点はありますか。
バンドルIDでの検索時、アプリが提供されていない国のストアを参照すると結果が取得できない場合があるため、country パラメータを適切に指定する必要があります*7。取得したversion値とアプリ内のバージョン情報を正しく比較するロジックの実装が前提になります。
強制アップデートの判定条件は誰が決めるべきですか。
セキュリティリスクや重大な不具合の有無を踏まえ、開発チームとプロダクト責任者が判定基準をあらかじめ合意しておくことが望ましいです。バージョン差分や緊急度をサーバー側の設定値として持たせておけば、アプリの再審査を待たずに条件を調整できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Android Developers「In-app updates」（https://developer.android.com/guide/playcore/in-app-updates）
- *2 出典：Android Developers「In-app updates」（https://developer.android.com/guide/playcore/in-app-updates）
- *3 出典：Android Developers「AppUpdateManager」APIリファレンス（https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager）、Android Developers「In-app updates for Kotlin and Java」（https://developer.android.com/guide/playcore/in-app-updates/kotlin-java）
- *4 出典：Apple Developer「Create a new version – Update your app – App Store Connect」（https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version/）
- *5 出典：Apple Support「How to manually update apps from the App Store」（https://support.apple.com/en-us/102629）
- *6 出典：Apple Developer Forums「Best practice to force upgrade app」（https://developer.apple.com/forums/thread/107576）
- *7 出典：Apple Developer「iTunes Search API: Lookup Examples」（https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/iTuneSearchAPI/LookupExamples.html）
- *8 出典：Apple Developer Forums「Force Update for an iOS app in App Store Review」（https://developer.apple.com/forums/thread/722382）
