概述
Flutter是什麼？Flutter是Google推出的一套開源跨平臺UI框架，可以快速地在Android、iOS和Web平臺上構建高質量的原生使用者介面。在過去的兩年時間裡，Flutter的更新頻率是相當的快，也有很多的公司開始使用它來進行跨平臺應用開發，可以說，將Flutter稱為2019年最流行的跨平臺技術也不為過。
作為一個移動網際網路的老兵，我先後研究過Hybrid APP、React Native和Weex等跨平臺技術，並且有幸出版過相關的書籍。對於Flutter，給我的感覺是，不管是從社群和社群的活躍來看，還是從技術的水準上來看，Flutter無疑都是目前最優秀的跨平臺開發方案。
在國內，除了阿里、騰訊、美團等大廠外，國內很多的中小團隊也開始使用Flutter來作為移動應用開發的首選，並且很多公司在移動招聘方面也要求具有Flutter開發的背景。那麼對於Flutter這個新生事物，Apple的態度是怎樣的呢？以後會不會封殺呢，就像之前的JSPatch等。
RN、Weex、小程式
首先，讓我們先來認識下RN和Weex。RN 和 Weex 其實使用的是類似的技術方案，即它們都使用JavaScript作為程式語言，然後通過中間層轉換為原生平臺的元件後再使用原生平臺的渲染引擎執行渲染操作。並且它們都是期望團隊開發業務的同學可以開發一套程式碼供多端使用，更多追求的是跨平臺能力，在做這個方案的同時正好也具備了動態化能力。
關於動態性方面本身具有一定的稽核風險，這裡明確表示是不合規的，參考稽核規則 2.5.2 蘋果動態性稽核條款，只不過 RN 和 Weex 的風險不如當年的 JSPatch 那麼大，所以Apple方面也是睜一隻眼閉一隻眼。
而當年的JSPatch 等熱修復解決方案則是通過底層操作使得開發者可以用 JS 語言呼叫任意原生程式碼，這直接導致了使用者 App 在蘋果稽核之後，依然可能做大範圍的改動，這會使得蘋果的稽核機制形同虛設。想象一下，你一個明面上說是新聞類的App，稽核通過後搖身一變變成了其他型別的App，你說合不合規，既影響 App Store 整體的體驗，更會給蘋果帶來系統性的合規問題，這是一大封殺 JSPatch 的原因。
RN和Weex 蘋果的建議是不提倡、不承諾不封殺，從我的理解是蘋果對於這類相對低風險的方案，秉持的態度是觀望，比如某天發現影響了他們的稽核，就會毫不猶豫的封殺；如果在稽核期間，通過這類技術動態改變頁面，很有可能會被直接拒審。
至於小程式，其實本身是當年 H5 離線包的一個開發語法標準化的衍伸，本身確實也具備了跨平臺和動態化能力，從蘋果目前的態度來看，只要不做的特別過分，目前是可以的，尤其是目前各大平臺都出了自己的小程式解決方案與開放平臺的情況下，總不能把這些 App 都幹掉吧。
Flutter
Flutter 與 RN、Weex、小程式最大的不同就是，Flutter是一個跨平臺解決方案，而非一個動態化解決方案。如果你閱讀Flutter相關的介紹，會發現Flutter直接使用skia引擎來渲染檢視，並且Flutter的Widget使用現代響應式框架進行構建，和平臺沒有直接的關係。
而從技術實現上來說，Flutter直接通過NDK編譯成本地庫的(libflutter.so)，也就是說，Flutter執行是AOT（靜態編譯）執行，而不是JIT（即時編譯），效能上完全沒問題。而在實際表現中，也優於Android原生下JIT狀態時的效率，本地庫的特性也導致Flutter自身不具備熱更新能力。而JSPatch這類東西，就和Android原生的熱修復框架Tinker之類的類似，是影響編譯效率的，尤其對啟動速度影響比較大。出於使用者體驗方面的考慮，肯定是會被封殺的，這方面Google Play也是一樣做法。
目前，從Flutter的發展趨勢來說，Google 是想把 Flutter 打造成為新一代的移動端開發標準，在做任何事情時都會考慮合規問題，所以才會在考慮了 iOS 上動態化能力時，依然不考慮支援這個特性，因為一旦 Flutter 在 iOS 上具備了這個能力，也就存在了稽核風險，這個稽核風險是系統性的。
蘋果已經明確表示 Flutter 目前沒有合規上的風險，因為它本身就不是一個動態化解決方案，但一樣秉持不提倡、不承諾不封殺，因為 Flutter 的崛起會吃掉蘋果 App 原生開發人員的份額，蘋果不建議使用官方以外提供的 Native 開發方案，蘋果是絕不能容忍開發人員的大面積消失。一旦這種情況發生，蘋果的生態就會遭人掣肘，這是蘋果爸爸就會出來保護蘋果 App 原生開發人員，這個時候也就是 Flutter 份額降低影響力降低的時刻，蘋果也在不斷推行 Swift 和 SwiftUI 等對原生開發人員更友好的解決方案，力圖抵擋住各跨平臺解決方案對蘋果 App 原生開發人員的蠶食。