【文章翻譯】How Flutter stays ahead of iOS releases
【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】
原文：https://flutter.dev/blog/how-flutter-stays-ahead-of-ios-releases
Flutter 如何領先 iOS 版本
了解 Flutter 團隊如何應對 WWDC、Beta 版發布和主動工程，以實現 iOS 的 Day 0 支援。
每個特定於平台的子團隊的工作流程都根據該平台的演變方式量身定制，就 Apple 而言，這往往圍繞著 6 月份的一周，屆時科技界的目光都轉向了加州庫比蒂諾。
蘋果的旗艦活動，WWDC
每年 6 月，Apple 都會舉辦一場名為 WWDC 的活動，預覽他們的軟體在未來一年中將如何演變。這通常與硬體發布分開，硬體發布會在一年中的其他時間陸續推出。在 WWDC 上，Apple 的許多作業系統（iOS、macOS、watchOS 等）是主角。
如果您曾經關注過 WWDC，那麼您就知道其後 COVID 時代的通用格式：首先是主題演講，然後是「平台現狀」，最後是大量專題影片發布。2026 年，WWDC 包含了超過 145 場技術會議，幫助 Apple 的開發者社群了解預期會有哪些變化——這無疑是一個令人難以置信的資源，但內容也太多了，無法手動篩選。
您已經知道接下來會發生什麼。我們甚至不必寫出以下這句話，您就知道這是真的，但我們還是會寫：
2026 年，Flutter 團隊開始使用 AI 對每個技術會議進行分類。
從今年開始，一小段 Dart 程式碼首先從每個影片中提取了文字記錄。然後，Gemini 根據以下標準對每個會議進行排名和分類：
- 對 Flutter 貢獻者（Google 內外）的重要性
- 影響範圍
- 建議採取的行動
影片發布當天日落時分，我們無需觀看 145 場（雖然質量非常高）技術會議，就得到了一份由 Gemini 生成的分類文件，其中包含每個會議的早期訊號。例如，我們的系統識別出我們可以大致忽略 SwiftData 會議，因為 Flutter 處理持久性的方式不同。另外，它將「現代化您的 UIKit 應用程式」演講標記為 Flutter 引擎團隊的關鍵 [1]，因為它描述了對 UIScene [2] 生命周期 API 的強制性更改。
[1] 為了查看對 Flutter 重要的所有內容，我們確實會親自爆一些爆米花並觀看 Gemini 以這種方式標記的每個會議。
[2] 稍後會詳細介紹UISceneAPI！
第二天早上日出時，Flutter 的 iOS 團隊正式進入了緊張時期。從 6 月的 WWDC 到 9 月的最終穩定版本發布之間隔了三個月，因此這是一場與時間賽跑的競賽，充滿了衝刺和錯誤修復，以確保及時合規。這項工作量很大，但 Flutter 團隊致力於始終為每個主要的 iOS 版本提供 Day 0 支援。要追蹤我們對 iOS 27 支援的進度，請 查看其在 GitHub 上的專案。
Dart 程式碼和 Gemini 工作流的系統處理了所有 WWDC 的內容，這佔了 Apple 絕大多數的變更。然而，「絕大多數」與「全部」是不同的；有時，一個關鍵的重大變更可能來自於像一個小修補程式發行說明一樣無害的東西。
Flutter 團隊聽聞的 Beta 版發布
2024 年，iOS 18.2 開發者測試版剛剛發布，帶來了一系列更新，其中包含了手勢和指標事件處理。幾天後，我們收到了一份令人擔憂的錯誤報告：點擊 webview 上方的 Widget 後，對底層 webview 的後續手勢或點擊都不會觸發 onClick 事件。
這不僅僅是糟糕。不，這是一場紅色警戒、五級火警——因為廣告依賴 webview，剝奪開發者哪怕一美元的收入絕對是不可接受的。
這個錯誤的根本原因最初不清楚，但按照科技偵錯的傳統，團隊成員想到了嘗試「關閉再打開」的說法。我們發現，在每次點擊時，替換 webview 堆疊中的一個手勢識別器可以解決問題。沒有人對這個解決方案特別滿意，但這是一個解決方案，而且對終端使用者來說是不可見的。
快進到 2025 年 8 月的 iOS 26 Beta 版，看似不相關的變更與我們的手勢識別器切換技巧發生衝突，導致更嚴重的 regression，其中 Flutter 的觸控和手勢阻擋系統完全失效。在沒有其他選擇的情況下，我們還原了先前的權宜之計……並立即重新遇到了無回應的 webview 錯誤。
從 Flutter 端對此異常的調查毫無結果，因此我們必須簡化問題。團隊用純 Swift 建立了一個測試專案。在沒有 Flutter、沒有 Dart 的情況下，只是一個標準的 UIKit 父視圖、一個原生手勢識別器和一個獨立的 webview，我們看到了相同的錯誤行為。
這是一個巨大的勝利！憑藉清晰的重現步驟，我們向 Apple 發送了錯誤報告和建議的修復方案，Apple 很快就識別並修復了該問題。到 iOS 26.4，webview 點擊行為恢復正常，無論專案是否使用 Flutter。
多方面修復
這個圓滿的結局還有一個補充事實：與此同時，Flutter 團隊正忙於 將所有 Dart 程式碼從一個單獨的「UI 執行緒」遷移回主「平台執行緒」（用 Flutter 的術語來說）。這意味著 Dart 程式碼可以與平台程式碼（如 iOS 的 Swift 和 Objective-C）同步通訊，這為其他現代化提供了可能性，例如引入一個同步的命中測試系統。這些重構透過移除微任務延遲和其他混亂來源，進一步改善了 iOS 上的手勢行為。
這些變更結合在一起，為在 iOS 上運行的 Flutter 應用程式和原生 iOS 應用程式帶來了主要的穩定性改進。
有時我們甚至也採取主動行動
WWDC 公告和錯誤報告本質上是反應性措施，但有時 Flutter 團隊實際上是領先一步。在 2025 年春季，Apple 發布了 iOS 18.4，這在 Flutter 應用程式中產生了以下警告：
CLIENT OF UIKIT REQUIRES UPDATE: 此過程未採用 UIScene 生命週期。這將在未來版本中成為斷言。
「未來版本」是模棱兩可的，但 Flutter 團隊不會對您的應用程式拖延，因此我們提前進行了深入研究。不幸的是，暗示的變更將會是一個重大變更。
要理解原因，必須考慮自 Flutter 於 2014 年誕生以來，行動裝置格局發生了多大的變化。曾幾何時，Flutter 只有 iOS 和 Android，完全佔據了這些螢幕，並享有穩定的視窗大小。現在，在 2026 年，Flutter 運行在其他平台上，可以有多個視窗，嵌入到非 Flutter 應用程式中，並且其幾何形狀可以隨時折疊一半。這些變化使曾經簡單的問題（例如「視窗有多大？」「應用程式是否在後台？」）變得複雜，也使 UIScene 的採用變得複雜！
然後，在 2025 年的 WWDC 中，一個獨立的技術會議包含了以下這句至關重要的句子：
在 iOS 26 之後的版本中，任何使用最新 SDK 建置的
UIKit應用程式都將被要求使用UIScene生命周期，否則將無法啟動。
感謝我們的輸入和我們（當時手動）的分類流程標記了該會議！
我們在 2025 年第三季度專注於設計和實施，並最終在第四季度開始測試我們的 UIScene 實施。一個實驗性標誌為喜歡冒險的 Flutter 開發人員解鎖了它，我們要非常感謝所有測試過的人，因為您們共同幫助我們找到了關鍵的邊緣情況、時間問題和其他怪癖。
到 2026 年 1 月，我們將重點轉移到幫助生態系統更新 iOS 外掛，因為它們的採用對於應用程式的健康也是必需的。在遷移了我們直接維護的每個外掛後，我們開始向社群外掛提交議題。值得慶幸的是，來自世界各地的外掛作者反應非常迅速，我們在更新所有內容方面得到了巨大的支持和團隊精神！
發佈此功能
Apple 的 UIScene API 的完整支援在 2026 年 2 月的 Flutter 3.41 穩定版本中推出。如果您從未聽過 UIScene，基本上不知道我們在說什麼——太好了！我們對成功的定義是，大多數 Flutter 開發人員將運行 flutter upgrade，繼續撰寫 Dart 程式碼，並且永遠不必考慮這個問題。（一些進階使用者，例如那些有「加入到應用程式」情境的人，確實有一個簡短但手動的遷移指南可以遵循。）
這項積極主動的工作帶來了巨大的回報，因為正如 Apple 所說，他們在 iOS 27 Beta 版中將該警告變成了斷言。但是，由於我們早期的努力，Flutter 在 iOS 27 甚至發布前幾個月就已準備就緒。
我們在沙漠中揮汗如雨；您享受甜蜜的甜點
Flutter 團隊的目標一如既往：找出應用程式開發中令人煩惱的部分，讓您可以專注於有趣的部分：建立功能、讓使用者滿意，以及發布出色的版本。無論是 iOS、Android，還是 Flutter 應用程式運行的許多其他平台，我們都希望您的建置目標仍然只是創造讓使用者愉悅的卓越體驗的另一個實作細節。
欲了解更多 Flutter 資訊，請觀看 本部落格文章的影片版本、我們的 文件、YouTube 頻道，或在社交媒體上找到我們。在此之前，我們迫不及待想看看您將建立什麼！
更多來自 Flutter
隆重推出 Flutter 桌面視窗化 API
了解新的桌面視窗化 API 背後的設計，並撰寫您的第一個多視窗 Flutter 應用程式。
架構師、測試人員和程式設計師：建構多代理開發團隊
在 Antigravity 中運行的多代理開發團隊如何使用測試驅動開發將 Python 函式庫移植到慣用的 Dart 套件。
