01

Flutter 3.44 iOS 構建：2026 要遷移嗎？

Flutter 3.44.0 的發布說明已列出 Swift Package Manager 預設啟用；官方文件也說明，Flutter 3.44 起，iOS 與 macOS 原生依賴會優先使用 Swift Package Manager。Flutter 3.44.0 發布說明 因此，本週的建議不是「全部立刻刪掉 CocoaPods」，而是按專案類型行動：

  • 新建專案：直接採用 Swift Package Manager。
  • 一般存量專案：建立升級分支，通過乾淨環境與 Release Archive 驗證後遷移。
  • 插件密集、複雜 Target 或 Add-to-App：先保留 CocoaPods，採雙軌驗證。
  • 持續整合維護者：先複製現有工具鏈，再決定是否改動常駐構建環境。

誰該看這篇：準備把現有 iOS 專案升級到 Flutter 3.44、但不確定依賴是否兼容的獨立開發者。
如果你維護遠端 Mac、自動構建腳本、多套 Flavor、Flutter 插件或 Add-to-App 模組，以下判斷可以避免一次性切換造成簽名或上架中斷。

最後更新於 2026 年 8 月 14 日；版本與依賴策略核實自 Flutter 官方發布說明、Swift Package Manager 文件、Add-to-App 文件及 CocoaPods 官方公告。

02

先按專案角色決定遷移速度

Flutter 3.44 的變更不只是換一個指令。你實際上是在調整原生依賴解析、Xcode 專案整合、插件資源處理與 CI 快取的邊界。

新專案：預設方案通常就是較低風險方案

新建 Flutter 專案沒有歷史 Podfile、舊版 Ruby 環境、手工修改過的構建腳本，也沒有一堆遺留 Target。這類專案應先使用 Flutter 3.44 生成的 Swift Package Manager 整合，不要為了沿用舊教學而主動恢復 CocoaPods。

但你仍要檢查新增插件是否具備 Swift Package Manager 支援。Flutter 官方插件開發文件指出，插件可以透過 Package.swift 宣告 Darwin 原生依賴，同時保留 CocoaPods 作為向後兼容路徑。Flutter 插件原生依賴文件

對新專案而言，「沒有 Podfile」不是驗收標準。真正的標準是：

  • 依賴能在沒有本機快取的環境中重新解析。
  • Debug 與 Release 都能完成編譯。
  • 真機可啟動，且原生權限、推播與深層連結沒有異常。
  • Xcode Archive 能完成簽名和導出。

一般存量專案：先建立可回退的升級分支

如果你的 App 主要使用常見 Flutter 插件，沒有私有 Pod、擴充功能或大量 Objective-C 構建邏輯，可以把 Flutter 3.44 遷移列入 2026 年的正常維護工作。

不要直接在唯一的發布分支上執行升級。先複製分支，鎖定目前可發布版本，再記錄以下結果：

  • 遷移前的 flutter pub get、依賴解析結果與鎖定檔。
  • 遷移前後的 Debug、Profile、Release 構建。
  • 模擬器與至少一台實體裝置的啟動結果。
  • xcodebuild archive 的輸出、簽名身份與導出設定。
  • App Store Connect 上傳前的校驗結果。

模擬器能啟動，只能證明部分編譯路徑可用。它不能證明 Release Archive、代碼簽名或上傳流程沒有問題。你應把「依賴解析成功、應用程式編譯成功、Release Archive 成功、簽名發布成功」視為四個獨立關卡。

03

Flutter 3.44 升級後還需要 CocoaPods 嗎？

需要與否，取決於你的插件和原生整合狀態，而不是只看 Flutter 版本。Flutter 官方目前的說法是：3.44 起 Swift Package Manager 是預設方案，但對尚未兼容的插件仍會回退使用 CocoaPods。Swift Package Manager 遷移文件

截至 2026 年 8 月 14 日，CocoaPods 並不是已經停止構建。CocoaPods 官方公告計劃在 2026 年 12 月 2 日 將 Trunk 轉為只讀，並明確表示現有構建不會因此立即失效；日期仍可能調整。CocoaPods Trunk 只讀計劃

所以，你可以按以下方式處理：

  • 全新專案、插件均支援 SwiftPM：以 Swift Package Manager 為主，不必為了慣性保留完整 CocoaPods 流程。
  • 部分插件仍依賴 Podspec：保留 CocoaPods，接受混合依賴狀態。
  • 私有 Pod 或自行維護的原生 SDK：先確認來源、版本鎖定與 CI 能否離線恢復。
  • 即將上架的專案：不要在發布週刪除 Podfile。先讓新舊分支各自完成一次 Release Archive。

Flutter 插件不支援 Swift Package Manager 時的處理方式

先不要把問題簡化成「插件太舊，直接換掉」。你需要判斷它是否真的阻塞生產構建。

第一步，列出所有 iOS 插件，區分純 Dart 插件、包含原生 iOS 程式碼的插件，以及帶有原生資源或二進位 SDK 的插件。第二步，查看插件是否有 Package.swift、SwiftPM 說明或已知限制。第三步，確認它使用的最低平台版本、資源 Bundle 和建構 Target 是否能被你的主 App 找到。

如果插件尚未支援 Swift Package Manager，但 CocoaPods 路徑能穩定完成 Release Archive，最安全的短期方案是保留雙軌，而不是為了「看起來已完成遷移」強行刪除 Podfile。Flutter 官方也保留 CocoaPods 作為向後兼容方案。Flutter 插件開發指南

這類專案的優點與代價

採用 Swift Package Manager 的優點：

  • 原生依賴更貼近 Xcode 目前的套件管理流程。
  • 新專案少一層 Podfile 與 Ruby 環境維護。
  • 對插件作者而言，Package.swift 能把原生依賴描述集中管理。

短期代價：

  • 部分插件仍可能回退至 CocoaPods，專案會進入混合狀態。
  • 既有自訂腳本可能假設 Pods/ 目錄一定存在。
  • CI 快取鍵、清理腳本和 Xcode 工作區設定可能需要重寫。
  • 依賴解析成功，不代表原生資源、簽名和 Archive 全部成功。
04

插件密集、Flavor 與 Add-to-App 專案要採雙軌

插件密集專案的風險不是插件數量本身，而是每個插件可能帶來不同的原生整合方式。私有 Pod、自訂 Flavor、通知服務擴充功能、Widget Target、原生測試 Target，都可能讓自動遷移結果與新建專案不同。

複雜原生 Target 的檢查重點

你應逐個 Target 檢查：

  • Flutter 依賴是否加入正確的包或工作區。
  • 每個 Flavor 是否使用相同或明確指定的依賴解析結果。
  • .xcconfig、Build Phase 和自訂腳本是否仍引用 Pod 路徑。
  • 推播、Widget、Share Extension 等 Target 是否需要獨立的原生依賴。
  • Release Archive 是否仍能找到資源 Bundle、Framework 和符號檔。

不要把「CocoaPods 資料夾已刪除」當成遷移完成的唯一證據。對複雜專案，能否重現生產包才是結論。

Add-to-App 不應直接套用普通 Flutter App 經驗

Add-to-App 是把 Flutter 模組嵌入既有 iOS App。官方目前提供把 Flutter 模組建成 Swift Package、再由宿主 Xcode 專案整合的路徑。Flutter iOS Add-to-App 文件

如果你的模組過去使用 CocoaPods 或 embedded frameworks，官方要求先移除舊整合，再按照 Swift Package Manager 路徑重新接入。這意味著宿主專案的相對路徑、自訂 Build Configuration、FlutterEngine 初始化和原生測試 Target，都需要單獨驗證。

Add-to-App 的結論通常是「先雙軌，不要急著清理」。你應先在獨立分支確認：

  • 模組可被宿主 App 找到。
  • Debug 與 Release 使用相同的 Flutter 產物來源。
  • 宿主 App 的簽名設定沒有因整合方式改變而失效。
  • 多個構建配置都能找到正確的 Swift Package。
  • 舊整合仍可在回退分支上重新構建。
05

遠端 Mac 如何驗證 Flutter 3.44 iOS 構建

如果你本機沒有獨立的 macOS 測試環境，或現有 Mac 正在承擔生產打包工作，可以先使用遠端 Mac 做一次乾淨遷移驗證。重點不是遠端桌面本身，而是把本機快取、未提交設定和個人憑證影響降到最低。

VpsMesh 提供可透過 VNC、SSH 或網頁控制台連線的遠端 Mac。你可以先參考遠端 Mac 的方案與租用方式，再按以下流程建立一次性測試環境。

第一步：固定工具鏈與分支

記錄 Flutter channel、Flutter SDK 版本、Xcode 版本、Ruby 與 CocoaPods 狀態。將遷移內容放在獨立分支，不要直接覆蓋可發布分支。

第二步：清除快取後重新取得依賴

在全新工作目錄中取得原始碼。不要先複製本機的 DerivedData、Pods 快取或 Xcode 使用者資料。依序執行專案既有的依賴安裝與生成指令，並保留完整終端輸出。

第三步：確認依賴解析路徑

查看 Flutter 產生的 iOS 設定、Xcode Package Dependencies、Podfile 或插件生成結果。你要記錄每個插件最後走 Swift Package Manager、CocoaPods，還是因不兼容而回退。

第四步：分開執行 Debug 與 Release

先用模擬器確認基本啟動，再以實體裝置測試原生權限和插件功能。接著使用 Release 設定構建，不要用 Debug 成功替代 Release 結論。

第五步：執行 Archive 與簽名驗證

使用與正式環境一致的 Bundle ID、Export Options 和簽名策略。憑證、API Key 和私密資料不要寫入文章、腳本範例或版本庫。你要檢查的是 Archive 是否完成、簽名身份是否正確，以及導出包是否通過上傳前校驗。

第六步：測試回退與 CI

刪除新依賴快取後重新構建一次。再切回舊分支，確認原 CocoaPods 路徑仍能運作。若回退需要手動修改多個設定檔，代表遷移尚未具備足夠的操作安全性。

06

本週可直接執行的遷移清單

  • [ ] 記錄目前可發布分支、Flutter SDK、Xcode 與依賴管理狀態。
  • [ ] 列出所有包含原生 iOS 程式碼的 Flutter 插件。
  • [ ] 標記每個插件是否支援 Swift Package Manager。
  • [ ] 檢查是否存在私有 Pod、自訂 Target、Extension 或 Add-to-App。
  • [ ] 建立獨立遷移分支，保留原 Podfile、鎖定檔與 CI 設定。
  • [ ] 在乾淨 macOS 環境重新取得程式碼與依賴。
  • [ ] 分別驗證依賴解析、Debug、Release、真機與 Archive。
  • [ ] 檢查簽名結果、導出包和 App Store Connect 上傳前校驗。
  • [ ] 記錄失敗位於解析、編譯、簽名還是發布階段。
  • [ ] 在確認回退路徑可用前，不要刪除舊構建環境。

對需要長時間跑 CI 的團隊，遠端 Mac 的價值在於隔離測試，而不是替你跳過驗收。通過一次遷移測試後，你可以再評估是否需要常駐 Mac 構建環境，或只在版本升級、插件替換和上架前使用臨時環境。

07

最後的取捨：遷移成功不等於立刻重做整套 CI

Flutter 3.44 iOS 構建的合理路線，是讓新專案先走 Swift Package Manager，讓普通存量專案以分支驗證遷移，讓插件密集與 Add-to-App 專案保留雙軌。CocoaPods 在 2026 年 12 月 2 日前仍不是已停止服務；即使官方只讀計劃按期執行，也不代表現有 Pod 會在當天立即無法構建。CocoaPods 官方公告

如果你目前只有一台工作 Mac，直接在同一台機器上改依賴、改簽名、改 CI，缺點是容易被本機快取掩蓋問題，也缺少可回退的隔離環境，還可能中斷正在進行的發布流程。若現有電腦無法提供獨立的 macOS 測試環境，你可以先租用 VpsMesh 的遠端 Mac，複製目前工具鏈，完成 Flutter 3.44 遷移前後的對照構建；驗證通過後，再決定是否把常駐打包機正式切換過去。