對於 Flutter、RN、Weex、小程式這些跨平臺解決方案的稽核風險，曾與相關團隊專門溝通過這塊。

RN、Weex、小程式：

1. 首先 RN 和 Weex 本身是類似的解決方案，都是期望團隊開發業務的同學可以開發一套程式碼供多端使用，更多追求的是跨平臺能力，在做這個方案的同時正好也具備了動態化能力，關於動態性方面本身具有一定的稽核風險，這裡明確表示是不合規的，參考稽核規則 2.5.2 蘋果動態性稽核條款，只不過 RN 和 Weex 的風險不如當年的 JSPatch 那麼大；
2. JSPatch 等熱修復解決方案通過底層操作使得開發者可以用 js 等語言呼叫任意原生程式碼，這直接導致了使用者 App 在蘋果稽核之後，依然可能做大範圍的改動，這會使得蘋果的稽核機制形同虛設，想象下你一個明面上說是新聞類的 App，稽核通過後搖身一變變成了博彩 App，你說合不合規，既影響 App Store 整體的體驗，更會給蘋果帶來系統性的合規問題，這是一大封殺 JSPatch 的原因，至於官方說的安全性問題，確實可能存在下發指令碼被黑客控制導致 App 出現重大安全隱患，但是都這麼多年了，為什麼蘋果自己沒有提供這樣一個安全通道呢，答案顯而易見稽核才是其命脈和維護 App Store 生態的根本；
3. RN、Weex 蘋果的建議是不提倡、不承諾不封殺，從我的理解是蘋果對於這類相對低風險的方案，秉持的態度是觀望，比如某天發現影響了他們的稽核，就會毫不猶豫的封殺；
4. 如果在稽核期間，通過這類技術動態改變頁面，很有可能會被直接拒審。

至於小程式，其實本身是當年 H5 離線包的一個開發語法標準化的衍伸，本身確實也具備了跨平臺和動態化能力，從蘋果目前的態度來看，只要不做的特別過分，目前是可以的，尤其是目前各大平臺都出了自己的小程式解決方案與開放平臺的情況下，總不能把這些 App 都幹了。

Flutter：

1. Flutter 與前面說的 RN、Weex、小程式最大的不同就是 Flutter 是一個跨平臺解決方案，而非一個動態化解決方案，Google 的野心很大，想把 Flutter 打造成為新一代的移動端開發標準，在做任何事情時都會考慮合規問題，所以才會在考慮了 iOS 上動態化能力時，依然不考慮支援這個特性，因為一旦 Flutter 在 iOS 上具備了這個能力，也就存在了稽核風險，這個稽核風險是系統性的；
2. 這點要說到國內外開發模式的不同，國外主張加強 CodeReview，國內主張小步快跑，快速迭代，有問題動態更新和熱修復頂上，而蘋果的稽核速度即便一再加快，也難滿足國內各大 App 的快速發版需求，正因為如此一再試探蘋果的稽核邊界，最終在稽核方面造成的問題和風險會逐步抵消掉動態更新和熱修復帶來的好處，當然不同 App 有不同的大環境，未來 App 也一定是朝著更合規的方向去發展；
3. Flutter 目前沒有合規上的風險，因為本身就不是一個動態化解決方案，但一樣秉持不提倡、不承諾不封殺，因為 Flutter 的崛起會吃掉蘋果 App 原生開發人員的份額，蘋果不建議使用官方以外提供的 Native 開發方案，蘋果是絕不能容忍開發人員的大面積消失，一旦這種情況發生，蘋果的生態就會遭人掣肘，這是蘋果爸爸就會出來保護蘋果 App 原生開發人員，這個時候也就是 Flutter 份額降低影響力降低的時刻，蘋果也在不斷推行 Swift 和 SwiftUI 等對原生開發人員更友好的解決方案，力圖抵擋住各跨平臺解決方案對蘋果 App 原生開發人員的蠶食。

轉載請標明作者與正確出處~