我用一個跨平臺 Web 應用替換了原生 iOS 應用，竟沒人發現

不知為何，我的跨平臺 Web 應用實際上更穩定。我想，我浪費了大量時間開發原生 iOS 應用。

這一切要從我想做一款可以幫助父母們安排孩子上學的 App 開始。

我是一個有 3 個孩子的父親。在工作中，有很多功能強大的工具可以幫我組織和管理團隊，但在家裡卻沒有任何工具可以幫我安排孩子們去上學，每次都搞得一團糟，為此我感到很惱火。於是我想，為什麼不給孩子們列一個待辦事項清單呢？我可以讓它的使用體驗看起來像遊戲一樣，甚至嵌入遊戲化的設計元素，幫助孩子們保持專注和參與度。

所以我開發了“ School Morning Routine ”，效果非常棒。現在，孩子們準備上學的時間縮短為原來的 30%，我們嘮叨的時間也減少了 95%（是的，我算過了）。

但在開發過程中，我犯了一個大錯誤。**我浪費了大量時間開發原生 iOS 應用。**

為什麼最開始我選擇了原生開發

在 2022 年，要開始一個移動 App 專案，最大的問題在於有很多完全不同的技術方向可供你選擇：原生應用、跨平臺 Web 應用、React Native、Flutter、漸進式 Web 應用、Xamarin 等等。

預設的方案是寫 3 次程式碼，一次針對 iOS，一次針對 Android，一次針對 Web。

但是，對我們軟體開發人員來說，多次編寫相同的程式碼是非常令人不安和不自然的。因此，這麼多年來，我們已經嘗試了幾十種方法，試圖實現“一次編寫，到處執行”，但它們都涉及令人討厭的權衡。

如果選擇了跨平臺 Web 應用，你只需要使用通用的 Web 技術編寫程式碼，然後將其部署到多個平臺上，只是有少量涉及 iOS 和 Android 功能的原生程式碼無法在瀏覽器中執行。

但你需要在效能方面做出權衡。

2014 年，我嘗試用 Ionic Framework 開發一款不同的應用，然後我和大多數人都發現了統一的問題：Android 和 iOS 執行 Web 應用的表現很糟糕。

它們響應慢、行為不可預測、斷斷續續、忽隱忽現，觸屏互動體驗也很古怪。

所以，我很早就確定 School Morning Routine 不應該是一款跨平臺 Web 應用。這款應用將大量使用遊戲風格的動畫，因為它是面向兒童的，所以它需要出色的觸屏互動體驗。

不知為何，我的跨平臺 Web 應用實際上更穩定

所以，我決定開發一款原生應用。原生應用通常風險最小、質量最高。當然，同樣的應用做了兩次，這不是什麼好事，但它畢竟是一款小應用，我相信努力比魔法更重要。

首先，我做了一款漂亮的 iOS 應用，並與測試使用者進行了多次迭代。然後我將其釋出到 App Store 上，並獲得了一些使用者反饋。除了收到五星好評，還有來自使用者的電子郵件。使用者在郵件裡說這款應用是如何改變了他們的生活和工作。

我很高興自己取得了一些成績，並決定接下來要開發 Web 應用。我使用了 React，再加上 CSS 動畫、Framer 和一些 Lottie 動畫。在開發完成後，我花了一下午仔細調優效能，只是想確保沒有做不必要的渲染。

那時，我的孩子們已經使用 iOS 原生版 School Morning Routine 好幾周了。為了測試這個新的跨平臺 Web 版本，我把它裝到孩子的 iPad 上。他們可以用它來測試，為上學做準備。

有趣的是， 我忘記告訴他們那個 App 已經從原生改為 Web 版了，但第二天早上他們卻沒有注意到。

他們沒有注意到。

他們甚至都沒有注意到。

如果你沒有孩子，可能就不會意識到這個。要知道，孩子總是抱怨所有的東西。真的，所有的東西。但是，當第二天我問他們是否注意到有什麼不同時，他們不僅沒有抱怨那款 Web 版 App ，還感謝我，因為我在 Web 版中使用了不同的動畫，他們當中有兩個更喜歡它。

他們是對的，新版的動畫流暢如黃油，觸屏互動體驗更加精準。

我感到很震驚。也許只是因為 iPad 的效能好？於是，我出去買了一臺低端的 Android 平板電腦。我選擇了一款功能配置差的，即使是開啟設定螢幕都很不流暢。但這也是一項重要的測試，因為對許多人來說，這是他們唯一能使用的裝置。

我載入了 School Morning Routine，你猜怎麼著，它執行得很好。雖然不算很出色，但這只是一款低端的 Android 平板電腦，你還能期待什麼？

於是，我走到辦公桌前，刪除了我的原生 iOS 應用，決定使用 Ionic Capacitor。

現在，我要開發一款可以在三個平臺上執行的 App。我的構建指令碼中有 3 個命令，分別用於部署到 iOS 平臺、Android 平臺或 AWS 的網站上。

這太酷了！

從那時起，我便在 Android、iOS 和 Web 上釋出 School Morning Routine。不僅我的 iOS 使用者沒有注意到，漏洞的數量也減少了。有一個麻煩的 Bug 與渲染表格檢視有關，這個問題只發生在 iOS 14 上，它打印出來的堆疊跟蹤資訊沒有用……但在我的跨平臺 Web 應用中，就不存在這個問題。

直線出現在跨平臺 Web 應用釋出之後

不知為何，我的跨平臺 Web 應用實際上更穩定！

這是怎麼回事？

為兒童開發的一款到處都是動畫的 App 居然是一款 Web 應用，這怎麼可能？

事實證明，在 2022 年，對於許多應用程式來說，編寫一次就可以在任何地方執行的夢想終於實現了。

對於跨平臺 Web 應用來說，成本和收益之間的權衡總是以較差的效能換取較短的開發時間。對於 2014 年的大多數應用來說，這是一個糟糕的權衡。但在過去的 8 年裡，很多事情都發生了變化。瀏覽器效能在穩步提升：

圖片來源： http://v8.dev/blog/10-years

Web 應用開發工具的種類和成熟度也在增加。現在，我們有了 React 和 TypeScript。IDE 和 Chrome 偵錯程式比原生應用開發工具要領先好幾光年。有很多創新的設計模式和開源庫可用於實現你能想到的目標。JavaScript 的世界比 Swift 或 Kotlin 的世界更加有活力和豐富多彩。

2022 年，成本和收益之間的權衡發生了變化。

跨平臺 Web 應用的時代正在到來

我一直是 Ionic 的鐵粉。他們在幾年前創辦了一家公司，是跨平臺 Web 應用的早期倡導者。我喜歡他們所做的工作，但我一直為他們感到難過。他們似乎押錯馬了，支撐跨平臺 Web 應用的技術無法支撐他們的夢想。

但到了今天，我認為技術的發展終於與 Ionic 的願景合拍了。

可能你在幾年前就瘋狂地想要開發一款像 School Morning Routine 這樣的跨平臺 Web 應用。這確實沒毛病！它很漂亮，真的！我已經在谷歌 Play Store 和蘋果 App Store 上釋出了這款應用，你甚至可以線上使用它。

不只是我，Josh Wardle 在去年末開發了 Wordle，這款手機遊戲現在正風靡全球。正如我在另一篇文章（ http://uxdesign.cc/wordle-is-a-masterclass-in-product-design-simplicity-52de1ba06d85 ）中所寫的，它甚至都沒有原生版本，只是一個使用 Web 元件開發的漸進式 Web 應用。

結論

我多麼希望在我開始開發 School Morning Routine 時能夠讀到這樣的文章。過去，我忽視了跨平臺 Web 應用，只因為我覺得它們太慢了，但沒想到它們卻完美匹配我的應用。

瀏覽器和 Web 技術每年都在變得越來越強大，每年都有更多型別的應用可以跨平臺開發。

所以，在開始下一個專案之前，為什麼不考慮一下跨平臺 Web 應用呢？或許它們真的不適你的專案，但或許，就像我一樣，你會發現它們可以“編寫一次，到處執行”。我覺得這非常出人意料。

如果你想了解跨平臺技術在國內的最新實踐，點選 GMTC全球大前端技術大會（北京站） 發現Weex 2.0、 Waft（基於 WebAssembly 和 Skia 的 IoT 應用開發框架） ，還將看到KMM、DSL 的優秀表現。

原文連結（本文對文章結構有小小的改動）： http://javascript.plainenglish.io/i-replaced-my-native-ios-app-with-a-cross-platform-web-app-and-no-one-noticed-1653901ce244