Flutter 3.47 iOS CIでSwiftPMをどう検証する？2026チェックリスト

Flutter 3.47のiOS CIは、プラグインがSwiftPMに対応しているかを先に確かめ、クリーンなMac環境で依存関係の解決からアーカイブまで検証してから切り替えてください。手元のMacで一度ビルドできただけでは、キャッシュや既存設定の影響を排除できません。

Flutter iOSアプリの保守担当者、Macのビルド工程を受け持つCIエンジニア、プラグインの配布方式を判断する開発者向けです。Flutter 3.47への更新で、依存管理とリリース工程をまとめて受け入れたい場合に役立ちます。

最終確認日：2026年10月31日。Flutterの安定版情報、SwiftPMの連携・移行資料、iOSデプロイ資料、AppleのCIガイドを照合しています（Flutterのリリースノート、Flutterアプリ開発者向けSwiftPM資料、AppleのSwiftパッケージCIガイド）。

Flutter 3.47の既定動作と、プロジェクトの実際の設定を分ける

Flutter公式資料では、Flutter 3.44以降、iOSとmacOSの依存管理方式としてSwift Package Manager（SwiftPM）が既定になっています。Flutter 3.47は2026年10月31日時点で安定版として掲載されています（公式リリースノート、アプリ開発者向けSwiftPM資料）。

ただし、既定の方式が変わったことと、既存プロジェクトがすでにその方式で動いていることは別です。過去に追加した設定、プラグインの対応状況、移行時に人手で変更したファイルによって、実際の依存経路は異なることがあります。まず同じコミットで生成・更新されるプロジェクト設定とFlutter CLIのログを確認し、チームの移行記録とも照合してください。

注意：CocoaPodsへのフォールバックが用意されていることは、すべてのプラグインがSwiftPMで使えることを意味しません。実際の経路は、プラグイン資料と対象コミットのビルドログで確かめます。

プラグインの対応状況から移行範囲を決める

Flutterプラグインを使うアプリでは、アプリ本体だけでなく、プラグイン側が宣言するネイティブ依存も確認します。Flutterのプラグイン開発資料とSwiftPM移行資料を参照し、プラグインの説明、マニフェスト、リポジトリで管理されているロックファイルを対象コミット上で照合してください（プラグイン開発ガイド、プラグイン作者向けSwiftPM移行資料）。

特に見落としやすいのは、開発者のMacに残ったキャッシュが依存不足を隠すことです。ロックファイルがバージョン管理に含まれているかを確認し、CIでは新しい作業環境から同一コミットを取得して再解決します。ローカルでは通るのにCIだけ失敗するときは、プラグインの互換性だけでなく、認証付きGit依存やCI上のGit設定も切り分けてください。

add-to-appはホスト側を含めて別に検収する

既存のネイティブiOSアプリにFlutterモジュールを組み込むadd-to-appは、通常のFlutter iOSアプリと同じ手順だけでは受け入れられません。Flutter公式のプロジェクト設定ガイドに沿って、ホスト側のXcodeプロジェクト、Flutterモジュール、パッケージ解決の入口をそれぞれ確認します（iOSプロジェクトへのFlutter統合ガイド）。

CocoaPodsを使った旧構成から移行する場合、既存設定を一括で削除するのではなく、公式ガイドに照らして対象範囲を決めます。設定を整理した後は、ホストアプリを含む構成で依存解決、ビルド、アーカイブを再試行してください。Flutterモジュール単独での成功を、ホストアプリの検収結果として扱わないことが重要です。

Mac CIで依存解決から署名まで記録する

受け入れの対象は、依存の解決だけではありません。AppleはSwiftパッケージを使うアプリやパッケージのCI手順を案内しているため、その資料を基に、環境の用意、認証、依存解決、ビルド成果物をチームの工程に合わせて確認します（AppleのSwiftパッケージCIガイド）。

• [ ] FlutterとXcodeのバージョン、対象コミット、ロックファイルの状態を記録します。
• [ ] 新しいMac作業環境で依存関係を解決し、成功・失敗のログを保存します。
• [ ] アプリのテストを実行し、失敗時は依存解決エラーとテスト失敗を区別します。
• [ ] 対象のビルド構成でアーカイブを作成し、成果物とログを保管します。
• [ ] コード署名の結果と配布に必要な条件を確認し、秘密鍵やトークンがログに出ていないことを点検します。

XcodeのコマンドはプロジェクトのスキームやCI構成に合わせて指定し、チームのローカル設定をそのまま前提にしないでください。非公開のSwiftパッケージや認証が必要なGit依存がある場合は、CIで使う資格情報とGitツールの設定を別に確認します。FlutterのiOSデプロイ資料も参照し、依存解決の成功と配布可能なアーカイブの完成を別々の証拠として残します（FlutterのiOSデプロイ資料）。

検証結果に応じて切り替え範囲を選ぶ

• プラグインがSwiftPMに対応し、クリーンなMacで依存解決、テスト、アーカイブ、署名まで確認できた場合は、対象プロジェクト単位でSwiftPMへの切り替えを進めます。
• 一部のプラグインがCocoaPodsを必要とし、フォールバックを含むビルド経路とアーカイブを確認できた場合は、その依存だけを記録して移行範囲を限定します。
• クリーン環境で依存を解決できない場合や、ホストアプリの署名まで証拠を揃えられない場合は、全体切り替えを保留し、原因を解消して再検証します。

CocoaPodsリポジトリについて、Flutter公式文書は2026年12月2日を読み取り専用化の予定日として示しています。この日付は2026年10月31日時点では将来の予定であり、すでに読み取り専用になった事実として扱ってはいけません。移行計画では公式資料を再確認し、予定の変更や実施状況を確かめたうえで判断してください。

よくある確認事項

FAQでは、SwiftPMが既定になった時期、未対応プラグインのフォールバック、クリーン環境での解決、IPAのアーカイブと署名を個別に確認しています。どのケースでも、ローカルの成功だけで判断せず、対象コミットのログと成果物を根拠にしてください。

まず代表的なFlutterプロジェクトを1つ選び、Mac環境で依存復元、テスト、アーカイブ、署名まで通してから、移行対象を広げるのが安全です。社内に検証用Macがなく、短期間だけMac CI環境を用意したい場合は、RUVCLOUDの料金と利用条件を確認し、Mac環境の申し込み案内と比較できます。既存のMacを継続利用できるチームには自前のビルド機が向く場合もありますが、Macを持たない環境ではLinuxだけでiOSのXcodeアーカイブと署名を完結できません。短期検証や一時的なビルド環境が必要な場合は、RUVCLOUDのリモートMacを選択肢に加え、必要な利用期間とCIへの接続方法を確認してください。