Capacitor 9は next dist-tagにありますが、一般利用可能になるまでに進んでいます。アップグレードする必要はありませんが、 Capacitor 9の公式アップデートガイド と プラグインのアップデートガイド 既にツールチェーンのフロアとAPIの削除を明示的に記述し、早期に取り組むべき点を列挙する。
Capacitor 9 に対する準備 準備 チェックリスト: Capacitor 8 (またはブランチ) で行うことができる作業は、最終的な bunx cap migrate ツールチェーンとプラットフォームのフロア (アプリ)
CI、ローカルマシン、ストアパイプラインを __CAPGO_KEEP_0__ の最小要件に基づいて計画する。
エリア
| Area | Capacitor 9 requirement |
|---|---|
| Node.js | 24+ 最新のLTS版を推奨します。npm 11にはNode 24が付属しています。 |
| エリア | 27+ |
| iOS デプロイメント対象 | 16.0+ |
| Android Studio | 2026.1.1+ |
| Android Gradle プラグイン (AGP) | 9.2.1 |
| Gradle ラッパー | 9.5.1 |
Capacitor 9 に対して準備する場合、iOS の場合は Capacitor 8.4 以下の場合、さらに UIScene ライフサイクル Capacitor 9 の Capacitor 8.5 のアップデート以降に実行してください。Xcode 27 はそれを必要とします。8.5 にすでにアップグレードしているアプリは、この追加ステップをスキップできます。
iOS では、Swift 6 (Xcode 27) は @UIApplicationMain; @main in AppDelegate.swift は公式ガイドに記載されているように実行してください。
アプリの同期時点 (プラグインの準備ステップではありません) には Cordova が含まれます
In Capacitor 9、Cordova互換レイヤーは アプリにのみ cap sync Cordovaプラグインがインストールされている場合にのみに接続されます。 CapacitorCordova Androidは、プラグインが存在しない場合にGradleモジュールを削除します。iOSはPodfileまたは Package.swift に追加されなくなります。
これは app-level (__CAPGO_KEEP_0__) をチェックして、プロジェクトに実際のCordovaプラグインが存在しない場合にCordovaシンボルをインポートしているかどうかを確認してください。そういった参照は、オプションでCordovaの接続が適用された後は失敗します。 custom native code iOS:
Android: gradle.properties とAGP 9のデフォルト
AGPアップグレードアシスタントは、AGP 8の動作を維持するために明示的に gradle.properties flags によりビルドは AGP 8 の動作を維持します。 Capacitor 9 アプリケーションは remove AGPを推測するのを停止する android.builtInKotlin=false アップグレードする際には、次のことを期待してください: android.sdk.defaultTargetSdkToCompileSdkIfUnset=false 最小値を上げる targetSdkVersion).
Capacitor 9 への移行の際には、以下の点も考慮する必要があります。
- 明示的な
variables.gradleminimums (compile/target SDK 37,minSdkVersion26、AndroidXの最新バージョン（公式ドキュメントを参照）。 - 削除
targetSdkVersionアプリからbuild.gradleCapacitor 9compileSdkVersion. - Declare
variables.gradleat the top ofapp/build.gradle(Gradle 9.6は、root projectから暗黙の検索を削除しています) - Swap default ProGuardファイル名を交換し、
core-ktxtoandroidx.core:core1.19.0+、スタンドアロンKotlin Gradle プラグインの使用を終了し、削除jcenter().
1.19.0+、独立したKotlin Gradleプラグインの使用を終了し、削除 diff hunksを読むことができます Android セクションで、ブランチに同じクリーンアップを適用し、Capacitor バージョンを上げる前に。
CLI: cap run --url
Capacitor 9 は、ライブリロードのホスト/ポート/HTTPSフラグを単一の引数に統合します。 --url 代わりに:
bunx cap run android -l --host 192.168.1.181 --port 5173開発サーバーが印刷するURLをパスします:
bunx cap run android --url http://192.168.1.181:5173/CLI のアップグレード後、筋肉の記憶が新しい CLI と戦わないように、スクリプトと README Snippets を更新してください。
公式プラグイン: プッシュとスプラッシュの注意点
生産アプリケーションでよく出現する 2 つのユーザー向けの変更:
プッシュ通知 (iOS): 非推奨の alert プレゼンテーションオプションが削除されました。プレゼンテーションオプションで banner と/または list を使用してください。
スプラッシュスクリーン (Android): Default launchFadeOutDuration Capacitor 9.0の変更点 200 msから0 msに変更されました。 fadeによる初回描画のフリーズを非表示にする場合、 launchFadeOutDuration: 200 明示的に設定するまで capacitor.config スタートアップUIを調整するまで
Capacitor 9.0のアップデートガイドのプラグインセクションを AndroidXとGoogle Play Servicesのバージョンアップを確認する 公式プラグインを使用している場合
プラグインメンテナ: Cap 8でCap 8を破壊しないように準備する
If you ship Capacitor plugins consumed on Capacitor 8 と Cap 9用のcodeを用意するには、Cap 9の準備に焦点を当ててください。 APIの廃止__CAPGO_KEEP_0__の廃止はCap-9のみのパッケージング変更に焦点を当てるのではなく、
Cap 8がサポートされている限り、安全に実行できます:
- 置き換え
@NativePluginに@CapacitorPluginおよび、古い@PermissionCallback/@ActivityCallbackパーミッション/アクティビティ結果APIを パターンに移行する( プラグイン9.0ガイド - を参照してください)。
PluginCall.hasOption,Plugin.getConfigValue削除CapConfigコンストラクタとゲッター,PluginCall.save()/isSaved(), そしてJavaの削除リストの下にある “code” の中の変更について。 - iOSでは、互換性のあるクラスと非推奨のヘルパーを使用しなくなり、代わりに
CAPBridge型付きアクセッサとブリッジプロパティをmigrationテーブルから使用すること。CAPBridgeProtocolRunApplicationDelegateProxyCapacitor 9の準備PluginCallCapacitor 9の準備 - Run
bunx @capacitor/plugin-migration-v8-to-v9@lateston a branch and keep only the API edits that still compile against Cap 8 peer dependencies until you publish a major for Cap 9.
Capacitor 8のサポートを続ける間は、__CAPGO_KEEP_0__ 8のプラグインからSPM製品を削除しないでください。 Cordova __CAPGO_KEEP_0__ 8のサポートを続ける間は、__CAPGO_KEEP_0__ 8のプラグインからSPM製品を削除しないでください。 Package.swift while you still support Capacitor 8. Cap 8 のプロジェクトは、プラグインが SPM ベースの場合、依存関係を期待しています; これを早期に削除すると、8 にまだ対応している消費者を破壊します。対処法 オプションの Cordova / 不条件の削除 Cordova 製品 製品として Capacitor 9 限定 (または明示的に Cap 9 以降の Cap としてドキュメント化された semver メジャー) のリリースライン (または)、Cap 8 をサポート停止した後 — プラグイン ガイドで説明されているように、Cap 8 ラインの前準備としてではなく。 同様のルールが、バージョンを上げる
に適用されます。 capacitor-swift-pm to 9.0.0-alpha.x in Package.swift__CAPGO_KEEP_0__ は配信します
CapgoライブアップデートとネイティブCap 9ストアビルド
Capgo が提供する ウェブ バンドル オーバー・ザ・エアのアップデート;ネイティブシェルはまだApp StoreとGoogle Playから来ています。Capacitor 9にアプリを移すとき:
- Ship 少なくとも1つのストアビルド Capacitor 9ネイティブプロジェクト (iOSとAndroid) にコンパイルされたバイナリがネイティブ基準Capgo チャンネルをターゲットします。
- ユーザーがそのビルドを持っているのちにのみ、Cap 9 WebViewとプラグインの動作をテストしたOTAバンドルに頼ることができます。
- 生産チャンネルに
metadata戦略を立てて、それぞれのチャンネルにCap 9バンドルをアップロードしてください。--auto-min-update-versionその意図的なネイティブ基準アップロードのために 省略--fail-on-incompatible(ネイティブパッケージは変更されるべきです)。--fail-on-incompatibleと--auto-min-update-version毎日OTAアップロード後。See ネイティブ+OTAチャネルワークフロー. - チャネルとsemverルールを同期して、Cap 9 APIをまだ古いネイティブシェルを実行しているデバイスにプッシュしないようにします。
あなたが使用している Capgo ビルド コンテキスト: Capgoソリューションズマーケティングページ。役割: ショートUIラベルまたはナビゲーションアイテム。見られる場所: page solutions/white-label.astro。Capgo製品/ブランドと開発者用語を完全に保存する。 before 前に macOS Cap 9 ストアのリリースの前に、pipelineがユーザーがインストールするものと一致するようにします。 macOS; Linux Node 24+ とホストの Android ツールを AGP 9.2.1 / Gradle 9.5.1 に合わせる必要があります。 (Xcode は macOS 限定です)。 実行順序の推奨
インストール済みのツールをアップグレードします。
- CI ホストと開発用マシンに、上記のバージョン (Node、Xcode、Android Studio、JDK) にアップグレードします。 アップグレードしないでください。 しない Cap 9 の値に上げることは、移行ステップの変更に属します。
bunx cap migrate古いネイティブ API を修正します。 - アプリケーション __CAPGO_KEEP_0__ とプラグイン (特にカスタム URL ハンドリングと Android ブリッジの使用) における古いネイティブ API を修正します。 app code とプラグイン（特にカスタム）
AppDelegatedeveloper - Android Gradleを綺麗にする ファイルとスクリプト (
gradle.properties, ProGuardのデフォルト (--url開発用スクリプト)。 - コルダバの使用状況をチェックする アプリケーションレベルでチェックする;Cap 9専用のリリースまでプラグインのSPM Cordova製品を変更しない。
- Cap 9がGA (またはCap 9を承認したとき)、run
next(またはbun add -d @capacitor/cli@nextリリース後)、@latest、そしてbunx cap migrate9.0にアップデートする compare_step_build_text. - Cap 9のネイティブビルドを ストアに公開し、次にCapgoのOTAロールアウトを一時停止または拡大して、対応するチャンネルに再開します。
Capacitor 9は「古いものを返済し、現代のAndroidとAppleツールチェーンに合わせる」ことを中心に進められています。Cap 8でその作業を進めると、アップグレードの差分が小さく、プラグインが8.xを今でも出荷しているチームと互換性があるため、簡単になります。
