Flutter 3.44 iOS構築は、新規プロジェクトと依存関係が単純な既存アプリなら2026年中に移行し、複雑な案件はCocoaPodsを残した二重構成で検証するのが安全です。今週は、まず移行ブランチを作り、Release Archiveまで通るかを確認してください。

最終更新：2026年8月14日。Flutter公式の3.44リリース情報、Swift Package Manager移行資料、Add-to-App資料、CocoaPodsの公式告知を確認しています。

01

この記事を読むべき開発者

Flutter 3.44へ更新する予定ですが、プラグインや署名設定への影響が分からない独立開発者向けです。

複数のFlavor、拡張ターゲット、Add-to-App、リモートMac上のCIを維持している小規模チームにも適しています。単に「CocoaPodsを消せるか」ではなく、公開用ビルドを安全に戻せるかを判断します。

02

Flutter 3.44 iOS構築の移行判断はプロジェクト別に分ける

Flutter 3.44では、iOSとmacOSのネイティブ依存関係管理にSwift Package Managerが標準採用されました。一方、非対応プラグインがある場合はCocoaPodsへ戻る経路も残されています。(docs.flutter.dev)

プロジェクトの状態 2026年の判断 先に確認すること
Flutter 3.44で新規作成 原則として移行 追加プラグインのSwift Package Manager対応
既存アプリ、一般的なプラグイン中心 移行ブランチで実施 Debug、Release Archive、実機動作
プライベートPodや複数ターゲットあり 併用して検証 ターゲットごとの依存関係とBuild Phase
Add-to-App 個別評価 ホストXcodeプロジェクトと相対パス
プラグイン作者 Package.swiftを整備 リソース、テスト、下流アプリでの構築

新規アプリには、過去のチュートリアルに合わせてCocoaPodsを手動で戻す理由は通常ありません。ただし、重要なSDKがSwift Package Managerに対応していない場合は例外です。

CocoaPodsのレジストリは2026年12月2日に読み取り専用へ移行する計画が公表されていますが、公式告知では日程が変更される可能性も示されています。既存ビルドが直ちに停止するという意味ではありません。(blog.cocoapods.org)

03

新規アプリは標準構成を維持し、既存アプリは比較して決める

新規プロジェクトでは、古いPodfile、Ruby環境、独自のインストールスクリプトが少ないため、Swift Package Managerの標準構成を使う方が管理対象を増やしにくいです。

確認すべきなのは、依存関係の取得が成功したかだけではありません。次の4段階を分けて記録してください。

  • パッケージまたはPodの依存関係を解決できる
  • Debug構成でコンパイルできる
  • Release Archiveを生成できる
  • 署名済みアーカイブを提出前検証まで進められる

シミュレーターが起動しても、Release用の設定、ネイティブリソース、実機署名、拡張ターゲットのリンクが正しいとは限りません。依存関係の移行では、最後のArchiveで初めて問題が出るケースを想定します。

既存アプリでは、現在公開できるコミットを基準にして移行ブランチを作成します。元のPodfile、ロックファイル、CIスクリプトは、公開用ビルドが安定するまで削除しないでください。

第一段階：依存関係の棚卸し

pubspec.yamlにあるプラグインを一覧化し、iOS側に次の要素がないか確認します。

  • 独自のPodspec
  • プライベートPod
  • Objective-Cのネイティブコード
  • リソースバンドル
  • XCTestなどのネイティブテスト
  • App Extension専用の依存関係

Flutter公式のプラグイン開発資料では、Swift Package Manager向けにPackage.swift、ネイティブソース、リソース配置、テスト構成を確認するよう案内されています。(docs.flutter.dev)

第二段階：依存関係を意図的に混在させる

Swift Package Managerに対応していないプラグインがある場合、すぐに削除する必要はありません。Flutter 3.44では、対応状況によってSwift Package ManagerとCocoaPodsが混在する可能性があります。

検証項目 移行前 移行後
依存関係の取得 Podfileと既存ロック情報 Swift Package Manager中心、必要に応じてPod
Debugビルド 現行構成で確認 同じFlavorと端末で比較
Release Archive 公開実績を基準にする 同じ署名設定で再現
署名 Provisioning Profileを固定 Bundle IdentifierとEntitlementsを比較
回退 元ブランチへ戻す PodfileとCI復元手順を確認

移行完了の条件を「Podfileを消したこと」にしないでください。公開アプリで必要なのは、同じ依存関係、同じ署名、同じ提出工程を再現できることです。

注意：Flutter 3.44の自動移行が成功しても、製品版の構築が成功したとは限りません。依存関係の解決、コンパイル、Archive、署名、提出前検証を別々の証拠として残してください。

04

プラグイン密集型とAdd-to-Appは二重構成で進める

プライベートPod、複数Flavor、App Extension、自作のBuild Phaseを含むプロジェクトでは、一度に構成を置き換えると原因を追いにくくなります。

まず、公開を止めない旧構成を保存します。次に、移行ブランチでターゲットを1つずつ確認します。Runnerだけ成功しても、Notification Service Extensionや共有フレームワークが失敗すれば実運用では使えません。

Add-to-Appは通常のFlutterアプリと同じ手順で扱えません。Flutter公式資料でも、既存のiOSアプリへFlutterモジュールを組み込む場合、Swift Packageとして統合する方法と、ホスト側のXcodeプロジェクト設定を確認する流れが分けて説明されています。(docs.flutter.dev)

確認対象は次の通りです。

  • Flutterモジュールの相対パス
  • ホストアプリのBuild Configuration
  • Flutter関連パッケージの生成場所
  • 複数のFlutter Engineを使う構成
  • ホスト側の署名と埋め込み設定
  • iOSネイティブテストのリンク状態

プラグイン作者は、Package.swiftへネイティブ依存関係を追加するだけでは不十分です。リソースをSwift Packageの想定ディレクトリへ移し、exampleアプリをSwift Package Manager有効状態で構築し、テストターゲットも確認します。対応が未完成なら、CocoaPods用の定義を直ちに削除しない方が下流利用者にとって安全です。(docs.flutter.dev)

05

FAQ：移行前に確認したい実務上の分岐

CocoaPodsを残すべきケース

Swift Package Managerに未対応の重要プラグインがある場合、CocoaPodsは当面の回退手段になります。公式資料でもFlutterはCocoaPodsを後方互換のためにサポートしていると説明されています。(docs.flutter.dev)

ただし、新規依存関係を無計画に追加する状態は避けてください。新しいパッケージを追加するたび、Swift Package Manager対応の有無、ライセンス、リソース、Release構成を記録します。

署名が壊れたように見えるケース

依存関係の統合方式を変えると、フレームワークの埋め込み、リンク設定、Build Phaseが変わることがあります。署名エラーが出た場合は、証明書だけを再作成するのではなく、次の順番で確認します。

  1. Bundle Identifierが移行前と同じか確認する
  2. Entitlementsの差分を比較する
  3. 埋め込み対象のFrameworkとPackage Productを確認する
  4. Release Archiveを生成する
  5. 署名済みアーカイブを提出前検証する

Appleの署名情報を新しく作る前に、プロジェクト設定の差分を保存してください。不要な証明書更新を先に行うと、原因の切り分けが難しくなります。

06

リモートMacで公開用ビルドを再現する5段階

手元のMacにあるキャッシュが、移行漏れを隠していることがあります。そこで、リモートMacでは新しい作業ディレクトリを使い、次の順番で検証します。

  1. リポジトリを新規取得し、対象ブランチを固定する
  2. Flutter SDK、Xcode、Ruby、署名情報のバージョンと配置を確認する
  3. flutter pub get後に、依存関係の解決結果を保存する
  4. Debug、実機、Release Archiveを同じFlavorで実行する
  5. 署名、提出前検証、回退ブランチの復元を確認する

Xcode 15.0以降が前提となるFlutter公式のAdd-to-App移行資料もあるため、リモートMacのXcode世代はプロジェクト要件と合わせて固定してください。(docs.flutter.dev)

一時的な移行検証だけなら、常時稼働のビルド機を先に用意する必要はありません。環境を分離して試すなら、Mac miniのレンタル構成を確認する方法もあります。既存のCIと同じSDK、証明書、環境変数を再現できるかを優先してください。

今週実行するチェックリスト

  • [ ] 現在公開できるコミットへタグを付ける
  • [ ] Podfile、ロックファイル、CI設定を保存する
  • [ ] プラグインをSwift Package Manager対応と未対応に分ける
  • [ ] 移行ブランチで依存関係の解決結果を保存する
  • [ ] DebugだけでなくRelease Archiveを生成する
  • [ ] 実機で起動し、主要なネイティブ機能を確認する
  • [ ] 署名と提出前検証を実行する
  • [ ] 旧構成へ戻せることを確認する
  • [ ] 失敗箇所を依存関係、コンパイル、署名、提出に分類する

移行後も常時ビルドが必要なら、Mac miniを使った常駐環境の選択肢を確認し、固定環境と一時検証環境を分けて考えてください。

07

2026年の判断は「移行するか」ではなく「戻せるか」

新規プロジェクトと、主要プラグインがSwift Package Managerに対応している既存アプリは、Flutter 3.44の標準構成へ移行する価値があります。

一方、プライベートPod、複数ターゲット、Add-to-App、独自スクリプトがある場合は、CocoaPodsを残したまま二重構成で検証してください。依存関係が解決しただけで移行完了とせず、Release Archive、署名、提出前検証、回退まで通った時点を完了条件にします。

現在の開発環境だけで試すと、キャッシュ、空き容量、既存証明書、ローカルRuby設定が結果を隠すことがあります。Macを購入して専用の検証機にすると初期費用と保守対象が増え、共有CIや一般的なクラウド環境ではmacOS固有の署名やXcode設定を自由に扱えない場合があります。

そのため、既存の環境を壊したくない場合は、まずVpsMeshのリモートMacで本番に近いFlutter 3.44 iOS構築を再現し、移行前後のArchiveと署名結果を比較する方法が現実的です。検証だけなら一時利用、継続的なiOS打ち包みが必要なら常駐構成というように、作業期間と運用頻度で分けて選んでください。