React Native 雖然強調自己不是 “Write once, run anywhere” 的框架，但是它至少能像 Google 的 j2objc 那樣，在 Model 層實現復用。那些底層的、與界面無關的邏輯，相信 React Native 也可以實現復用。這樣，雖然 UI 層的工作還是需要做 iOS 和 Android 兩個平臺，但如果抽象得好，Logic 和 Model 層的復用不但可以讓代碼復用，更可能實現底層的邏輯的單元測試。這樣移動端的代碼質量將更加可靠。
其實 React Native 宣傳的 “Learning once, write anywhere” 本身也是一種復用的思想。大家厭煩了各種各樣的編程語言，如果有一種語言真的能夠統一移動開發領域，對于所有人都是好事。
UI 排版的問題
我自己一直不喜歡蘋果新推出的 AutoLayout 那套解決方案，其實 HTML 和 CSS 在界面布局和呈現上深耕多年，Android 也是借鑒的 HTML 的那套方案，蘋果完全可以也走這套方案的。但是蘋果選擇發明了一個 Constraint 的東西來實現排版。在企業的開發中，其實大家很少使用 Xib 的，而手寫 Constraint 其實是非常痛苦的。所以出現了 Masonry 一類的開源框架來解決這類同行的痛苦。
我一直在尋找使用類似 HTML + CSS 的排版，但是使用原生控件渲染的框架。其實之前 BeeFramework 就做了這方面的事情。所以我還專門代表 InfoQ 對他進行過采訪。BeeFramework 雖然開源多年，而且有 2000 多的 star 數，但是受限于它自身的影響力以及框架的復雜性，一直沒有很大的成功。至少我不知道有什么大的公司采用。
這次 Facebook 的 React Native 做的事情相比 BeeFramework 更加激進。它不但采用了類似 HTML + CSS 的排版，還把語言也換成了 JavaScript，這下子改變可以稱作巨大了。但是 Facebook 有它作為全球互聯網企業的光環，相信會有不少開發者跟進采用 React Native。
不過也說回來，Facebook 開源的也不一定都好，比如 three20 就被 Facebook 放棄了，但是不可否認 three20 作為一個框架，在那個時期的特定價值。所以 React Native 即使沒有成功，它也將人們關注的焦點放在了移動開發的效率上了。很可能會有越來越多相關的框架因此涌現出來。
MVVM
MVVM 在 Web 開發領域相當火熱，而 iOS 領域的 ReactiveCocoa 雖然很火，但是還是非常小眾。糾其原因，一方面是 ReactiveCocoa 帶來的編程習慣上的改變實在太大，ReactiveCocoa 和 MVVM 的學習成本還是很高。另一方面是 ReactiveCocoa 在代碼可讀性、可維護性和協作上不太友好。