Flutter 3.47 iOS ビルド失敗：2026年、どう直す？

📌 Flutter 3.47への更新後、iOSアプリのBuildやArchiveが失敗する場合の復旧手順をまとめます。安定版パッチ、Swift Package Manager、プラグイン、CocoaPods、リモートMacでの公開確認まで、作業順に切り分けます。

同じコミットが旧環境では成功し、Flutter 3.47とXcode 27への更新後にiOSビルドで失敗しています。

最短の解決策： まず関連する修正を含む最新のFlutter 3.47安定版パッチへ更新し、同じコミットで依存関係の解決とArchiveを再実行します。直らない場合だけ、プロジェクト種別、Swift Package Manager、プラグイン対応状況を確認し、CocoaPodsへの一時的な回帰を判断します。

この記事は、Flutter 3.47 iOS ビルド失敗に困っている個人開発者向けです。Xcode 27やリモートMacで無人ビルドを管理する担当者、Add-to-AppやSwiftPMとCocoaPodsが混在する小規模チームにも適しています。

最終更新：2026年9月16日。Flutter公式changelog、AppleのXcode 27公開資料、FlutterのSwiftPM資料を確認しています。

失敗現場の保存

最初に修復作業を始めると、最後に表示されたエラーだけが残り、原因の比較ができなくなります。先に、旧環境で成功した記録と、更新後に失敗した記録を分けて保存してください。

脱敏化した記録では、次のような差分を残します。

旧環境：同一コミット / 依存関係解決 成功 / Build 成功 / Archive 成功
更新後：同一コミット / 依存関係解決 成功 / Xcode Build 失敗

ここで重要なのは、失敗地点を一つに決めつけないことです。依存関係の解決、通常のBuild、Release、Archive、署名、アップロードは別の工程です。最後の署名エラーだけを見て、依存関係を削除するのは危険です。

Flutterの実際のパッチ版、Xcodeの版、実行コマンド、実行ユーザー、最初に発生した有効なエラーを保存します。ログに含まれるプロジェクト名、リポジトリ名、Bundle ID、Team ID、アカウント名、ホスト名、パスは置き換えてください。

パッチ版の確認

Flutter 3.47.0、3.47.1、3.47.2以降を同じものとして扱わないでください。Flutter公式changelogでは、SwiftPMを有効にしたiOS・macOSビルドの失敗や、Xcode 27でiOS Add-to-AppがFlutter Swift packageをビルドできない問題が、3.47.2の修正項目として記載されています。後続の3.47.3も同じ一覧で確認できます。Flutter公式changelogで、使用中の安定版パッチを確認してください。

Xcode 27は2026年9月14日に正式公開されています。AppleのXcode公開資料とXcode Release Notesを照合し、手元の実行環境と一致しているか確認します。

確認対象	残す情報	判断
Flutter	実際の3.47系パッチ版、チャンネル	旧パッチなら先に安定版を比較
Xcode	Xcode 27の版、選択中のDeveloper Directory	GUIとSSHで一致するか確認
コマンド	`flutter build ios`、`xcodebuild`、Archive手順	実行入口の違いを分離
成果物	依存解決、Build、Archiveの各ログ	最初の失敗地点を特定

Flutter 3.47への更新後にiOSがビルドできない場合、すべてが同じ回帰ですか。

いいえ。公式に修正されたSwiftPM関連の問題はありますが、すべてのビルドエラーが同じ原因とは限りません。パッチ版、プロジェクト種別、プラグイン、実行経路を同じ条件で比較し、最初の有効なエラーから切り分けます。

更新は独立したブランチ、または確実に戻せる環境で行います。ソースコード、依存関係ロックファイル、ビルドコマンドを変えずに、Flutterのパッチ版だけを比較してください。先に全キャッシュを削除したり、打ち合わせなしに本番の打包機を作り直したりする必要はありません。

SwiftPM統合の再確認

パッチ更新後も失敗する場合は、プロジェクトにSwift Package Managerの接続が完全に残っているか確認します。Flutterの公式資料では、Flutterアプリ向けのSwiftPM統合方法と、生成されるパッケージの扱いが説明されています。FlutterのSwiftPM統合ガイドを基準にしてください。

見る場所は次のとおりです。

FlutterGeneratedPluginSwiftPackage が生成・参照されているか
ビルド前スクリプトが対象の構成で実行されているか
iOSアプリのTargetが必要な依存関係を参照しているか
Xcodeプロジェクトに重複したPackage参照や不完全な参照がないか
Debugだけでなく、ReleaseとArchiveでも同じ統合状態か

普通のFlutterアプリ、iOS Add-to-App、独自Targetを追加したプロジェクトでは、確認する証拠が異なります。Add-to-Appの場合は、Flutter公式のAdd-to-App資料に沿って、ホスト側のXcode設定とFlutter側の生成物を分けて確認します。

プロジェクト形態	重点確認箇所	早急に避ける操作
通常のFlutterアプリ	生成パッケージ、Target、プラグイン登録	依存関係を一括削除する
iOS Add-to-App	ホストアプリとFlutterモジュールの接続	ホスト側の設定を新規作成で上書きする
独自Targetあり	TargetごとのスクリプトとPackage参照	主Targetだけ直して完了と判断する

Xcode 27でFlutter Swift Packageのビルドが失敗した場合、どこから直しますか。

最初に、Flutterのパッチ版が修正済み範囲に入っているか確認します。次に、XcodeのPackage参照、生成パッケージ、Target依存、ビルド前スクリプトを同じコミットで比較します。SwiftPMそのものを壊れた仕組みと判断して、いきなりCocoaPodsへ全面移行するのは避けてください。

Swift Package Managerの仕組み自体を確認したい場合は、Swift Package Managerの公式リポジトリも参照できます。ただし、ここで確認できる一般的な仕様と、Flutterプロジェクト固有の統合失敗は別問題です。

プラグインと依存経路

SwiftPMの修正後も失敗するなら、プラグインがSwiftPMに対応しているかを一つずつ確認します。Flutter側が対応していないプラグインのためにCocoaPodsへ戻る場合があるため、Podfileや既存のネイティブ依存を削除してはいけません。

確認項目は以下です。

失敗したプラグインがSwiftPM対応を明示しているか
Flutterが実際にSwiftPMを使ったのか、CocoaPodsへ戻ったのか
手動編集したPodfileに独自設定が残っているか
プライベートなiOS依存パッケージへ接続できるか
最低OSバージョンの条件がXcode 27と一致しているか
同じプラグインがSwiftPMとPodの両方から二重に読み込まれていないか

FlutterのSwiftPMビルドが失敗したら、CocoaPodsへ戻すべきですか。

プラグインがSwiftPMに未対応で、実際にその依存関係が失敗原因だと確認できた場合だけ、一時的な回帰を検討します。回帰前に、対象プラグイン、変更するPodfile、影響するTarget、戻す条件を記録します。

CocoaPodsへ戻す場合も、依存関係ロックを保ち、変更範囲を最小化します。修正後にSwiftPMとCocoaPodsの両方を残すのではなく、どちらが各プラグインを提供しているかを記録してください。

注意：Package Cache、Pods、Derived Dataを削除すると、原因の証拠と再現条件を失うことがあります。削除する前にログを保存し、同じコマンドで再生成できることと、失敗時に元へ戻せることを確認してください。

Archiveと実行環境の分離

通常のDebug Buildが成功しても、公開用のArchiveが復旧したとは限りません。Release構成、Archive、書き出し、必要な署名処理、App Store Connectへのアップロード準備まで別々に確認します。

次の順序で進めます。

[ ] 同じコミットで依存関係の解決結果を保存する
[ ] DebugではなくReleaseのiOS Buildを実行する
[ ] Xcode 27でArchiveを作成する
[ ] Archiveの書き出しと成果物の存在を確認する
[ ] 必要な署名情報とKeychainの読み込み結果を確認する
[ ] 公開用のアップロード手前まで同じ環境で実行する
[ ] GUI、SSH、CIでDeveloper DirectoryとFlutterのパスを比較する
[ ] 断線後の再接続とMac再起動後に同じ手順を再実行する

ローカルではパッケージできるのに、リモートMacでは失敗する場合はどう切り分けますか。

同じソースコードでも、SSHやCIではGUIセッションと環境が異なります。まずFlutter、Xcode、Ruby、CocoaPods、Package Cacheの参照先を記録し、次に実行ユーザーのホームディレクトリ、Keychainのロック状態、作業ディレクトリの権限を比較します。

依存関係の解決だけが失敗するなら、Git接続、認証、キャッシュ所有者を確認します。Buildは成功してArchiveだけ失敗するなら、署名、書き出し設定、実行セッションを確認します。GUIで成功したからといって、無人実行も成功するとは限りません。

MACCOMEの日本語向けMac環境案内のようなリモートMac環境を使う場合も、単に接続できるかではなく、同じFlutterプロジェクトで依存解決、Build、Archive、再接続を確認してください。Mac miniの構成を比較する場合は、Mac miniの注文案内も選択肢の整理に役立ちます。

一週間の固定化

一度成功しただけでは、Flutter 3.47 iOS ビルド失敗が再発しないとは言えません。修正後は、Flutterの版、Xcodeの版、依存関係ロック、ビルド入口を固定し、最小プロジェクトと実際のプラグインを含む脱敏プロジェクトで継続確認します。

特に残すべきものは、成功したコマンド、環境変数、PackageとPodの採用経路、Archiveの保存場所、署名前後のログです。後続パッチやXcodeの更新を導入するときは、いきなり本番機を置き換えず、旧環境を戻せる状態で比較します。

長期間維持する場合は、旧版と新版の二重環境を残すか、修正済みの環境へ切り替えるかを決めます。判断基準は「新しい版で一度成功したか」ではなく、断線、再接続、Mac再起動、Release Archive、実際の公開作業まで再現できるかです。

遠隔環境を選ぶ条件

WindowsやLinuxの開発機だけでは、Xcode 27のArchive、Apple向け署名、App Store Connectへの公開確認を完結できません。自前のMacを長期間使う方法は、環境を自由に固定できる一方、購入費用、保守、常時稼働、故障時の交換を自分で負担します。

一方、リモートMacは、旧版と新版のFlutter・Xcodeを分けて試したいときや、公開時だけmacOSの実行環境が必要なときに向いています。ただし、物理的なUSB機器が必要な開発、長期にわたる高負荷処理、社内規定で機材を専有する必要がある場合は、自前のMacのほうが適しています。

現在の環境で「ローカルでは成功するが、常時稼働するArchive環境がない」「WindowsやLinuxから公開作業だけ実行したい」「更新前のツールチェーンを残したい」という条件が重なるなら、修復後の同一コミットをMACCOMEの環境で検証する価値があります。先にプロジェクト側の原因を切り分け、実際のArchiveと再接続を確認してから、継続利用するか判断するのが安全です。