作為一名長期從事 iOS 開發的程式設計師，最讓我感到鬱悶的莫過於是看著業界發展日新月異，而我們卻彷彿是在原地踏步。我試過用 lovable.dev、bolt.new，和 a0.dev 這些平臺構建網站和應用，使用體驗甚是神奇。反觀蘋果生態，我們連 Xcode 裡能正常執行的 GitHub Copilot 都少有，我認識的所有開發者都把蘋果的“智慧功能”關閉了。

據 Expo 專案的核心開發者之一 Evan Bacon 透露的資料，目前 App Store 購物類別中排名前百的應用中，有 40 個都是採用非原生開發的。隨著 AI 應用構建工具的爆發式增長，未來非原生應用的比例只會持續攀升。

iOS 開發者的“Cursor”級體驗究竟在哪？

在我看來，這一切都要追溯到蘋果根深蒂固的閉源傳統；是一個關於企業的長期決策是如何積重難返的警示案例。那讓我們深入討論，要想在 iOS 生態中打造類似 a0.dev 的開發體驗，究竟需要突破哪些技術壁壘？

在使用者提出修改需求時，要能對程式碼進行更新並驗證其可編譯性。聽起來不難，對嗎？

首先你得有一臺 Mac 裝置。但即便滿足了這個前提條件，iOS 程式碼編譯的複雜度依舊是臭名昭著；蘋果官方從未支援過 Xcode 之外的編譯環境。雖然也有xcodebuild這類的命令列工具，但其對增量編譯等基礎功能的支援堪稱災難。開發者還會遭遇無數瑣碎且耗時的障礙：系統會反覆向蘋果伺服器傳送驗證請求、檢查配置檔案更新狀態、確認應用是否具備正確授權（使用作業系統功能的許可權），以及強行增加但沒人樂意用的應用鎖定功能。

在我的一個本地的測試專案中，雖然我能讓這條命令執行，但還是會顯示下面這些編譯錯誤：

這種方案能行得通，大語言模型應該也能透過解析編譯錯誤來自動修復問題，總算是有所突破了！

不過要是 AI 的解決方案需要建立新檔案，這點應該難不倒 AI 吧？

現實很骨感。由於 Xcode 特有的 .xcodeproj 檔案格式需要開發者手動維護檔案引用關係，我們得想辦法在編輯檔案的同時，祈禱檔案的引用不會出錯。雖然開發者社群普遍使用 Ruby 工具庫 xcodeproj 來操作專案檔案，但蘋果從未提供過官方支援工具。

到 2025 年，業內普遍推薦將程式碼模組化至 Swift Packages，這種方式確實有效，但每個 Package 仍需手動整合到主專案檔案中。我們正處在一個尷尬的過渡期：既不能完全擺脫傳統專案檔案的束縛，又未能實現真正意義上的全 Swift Packages 應用構建。

幸好我們還不算徹底悲劇，目前有些值得關注的開發專案正在推進：

然而這些補救措施終究還是在亡羊補牢。iOS 開發生態的整體閉源屬性依然根深蒂固，短期內難以被撼動。

假設我們已經透過 AI 搞定了程式碼修改並且能透過編譯，現在就該即時預覽修改的效果了。以 Lovable.dev 等平臺為例，它們的實現方式是在虛擬機器執行本地開發伺服器，使用者只需在瀏覽器訪問特定頁面即可。對於採用 React Native 的 a0.dev 來說，原理同樣簡單：瀏覽器中呈現的不過是react-native-web的執行例項，比如這樣：

透過瀏覽器開發者工具可以看到，這個 <iframe> 載入的正是 react-native-web 生成的 HTML 頁面。由於 React Native 本質上是 React 框架的延伸，開發者只需切換底層平臺目標，就能在瀏覽器中獲得近乎完美的預覽效果。

但 iOS 開發完全是另一套遊戲規則：你必須要讓應用執行在 iOS 執行時環境中。這意味著開發者需要管理模擬器啟動（記憶體佔用極高）、處理裝置更新和模擬器執行時版本相容問題、想辦法透過影片流傳輸機制將模擬器畫面投射到瀏覽器的同時，建立雙向互動通道同步使用者輸入事件。一點都不簡單。

看起來 iOS 執行時才是技術瓶頸。難道不能透過 WASM 等技術讓 SwiftUI 支援網頁目標嗎？很遺憾，SwiftUI 是閉源的！我們完全受制於蘋果的技術路線圖。雖然開源社群有 OpenSwiftUI 這樣的優秀專案，但其實現原理卻是透過對框架逆向工程。為什麼蘋果會想把 SwiftUI 做成閉源產品超出了我的理解能力。對比之下，安卓的 Jetpack Compose 不僅完全開源，更是透過 Compose Multiplatform 實現了跨平臺開發。即便是 Skip 這類的創新專案，目前也僅支援安卓而非網頁平臺。

假設我們也已經攻克了模擬器的難題，現在要將解決方案擴充套件到供數千開發者使用。伺服器虛擬化本來就是成熟技術，不是嗎？

但在 iOS 生態中這仍是天方夜譚。要執行模擬器，我們就得有 macOS 裝置，但這也是要命的地方：規模化部署 macOS 伺服器非常困難。

首先，macOS 虛擬機器按規定只能在正版 Apple 硬體上執行。其次，根據蘋果的授權條款，物理 Mac 例項最低的租用週期長達 24 小時（參見 AWS 物理 Mac 例項的複雜配置流程）。

其次，即便成功啟動 Mac 例項，蘋果的虛擬化框架也會將併發虛擬機器的數量嚴格限制在兩臺以內。選擇在虛擬機器執行構建服務本是出於安全考量，由於 iOS 模擬器可直接訪問宿主檔案系統，惡意應用可能竊取宿主系統或其他使用者的資料。這種安全與效率的悖論，直接導致規模化部署需要堆砌數以千計的物理 Mac 裝置。

最後，macOS 本質上就不是為無伺服器環境設計的作業系統。Linux 系統上那些"開箱即用"的伺服器體驗，macOS 會給你帶來各種意想不到的"特色功能"。

鑑於谷歌的安卓生態是開源的，那它是否就比蘋果生態更具優勢呢？

理論上確實如此，多數專案透過簡單的 ./gradlew assembleDebug 命令就能成功編譯，雖然編譯時間往往過長而難以形成高效的工作流。模擬器問題與 iOS 要面對的基本相似，雖然安卓模擬器的規模化執行可行，但同樣存在其特有的技術難題。

要想實現真正實用的方案，安卓應用可能需要透過 Compose Multiplatform 轉向網頁平臺。目前已有專案實現在瀏覽器渲染 Compose 檢視，技術可行性已經得到了驗證，關鍵在於要如何將開發體驗至 Expo 的水準。

感謝你讀到這裡，那我們從中能學到什麼呢？在我看來，蘋果對軟體生態的封閉策略終於開始反噬自身，使其在 AI 競賽中漸顯頹勢。當下蓬勃發展的 UI 框架無不建立在開源技術之上，越來越多的開發團隊選擇了 React Native 而非 Swift 尤其是在 AI 服務讓應用搭建速度發生質變的今天。我期待能出現構建真正原生 iOS 應用的 Lovable 或 A0 級別工具，但蘋果生態的特殊性讓這種願景難以實現。

多年來開發者持續詬病蘋果平臺的開發體驗，但根源性問題始終未獲解決，如今這個技術深坑已越發地難以填平。