原生 Mac 應用開發困境：SwiftUI 的局限與性能追求

原生 Mac 應用開發困境：SwiftUI 的局限與性能追求

長期從事原生 macOS 和 iOS 開發的開發者們可能會對那些選擇使用 Node.js 或 Electron 等技術來搭建應用程序的人投以不屑的眼神，認為這些做法是「返璞歸真」或「倒退」。然而，這種態度可能需要重新評估。

最近，我嘗試用純 Swift 和 SwiftUI 實現一個簡單的聊天功能，支援 Markdown 格式。事實上，在跨出簡單界面範疇之後，會發現即便是這些被稱為「原生」的技術也仍存在許多不成熟之處。例如，SwiftUI 確實可以實現良好的性能表現，甚至能讓人接受一些略顯卡頓的操作。但當你需要從 SwiftUI 的基本元素構建一個完整的 Markdown 文本並選取它時，就會發現這根本是不可能完成的任務——這是設計上的限制。

面對這種情況，我們會開始尋找其他解決方案。NSTextView 便是一個選擇，它可以支持 TextKit 2，這似乎是一個完美的答案。然而，在轉向 NSTextView 後，你會發現它與原有的 SwiftUI 測試和性能工作並不兼容，這意味著你需要重新建立測試環境。

接下來的挑戰是實現文本流式傳入，因為在當今這個每個人都在從模型獲取響應的世界裡，這是一個基本需求。然而，這種操作可能會讓 CPU 發生突增。此時，AppKit 的 NSCollectionView 似乎又是一個解決方案——它成熟的性能和穩定性給人信心。但是，在實際使用中你會發現，它的單元格會在任何情況下都會閃爍——這是設計上的缺陷。

更進一步地，我們甚至考慮直接使用純 TextKit 2 實現文本操作。雖然這種方式的性能還可以接受，但文本流式傳入仍然存在問題，並且它與現代技術兼容性差。當你決定完全放棄 SwiftUI、只依靠 AppKit 時，會發現自己需要手動處理擴展的文本塊——此時幾乎所有功能都變得不穩定。

更糟糕的是，要實現基本的原生 macOS 行為，如上下文菜單、字典查閱、選擇性文字操作及可訪問性等，可能需要數月的時間來完成。這些都是用戶在使用應用程序時期望得到的功能，但卻往往被忽視。

面對這種情況，我們可能會轉向 WebKit 渲染 Markdown 文本，因為它能很好地工作並提供良好的性能表現和完美的排版效果。然而，在這最黑暗的一刻，你可能會想：好吧，讓我們生成一個簡單的 Electron 項目吧。

令人驚訝的是，從 Electron 中獲得的功能遠超預期——文本操作、Markdown 渲染等都運行順暢且性能良好。此外，與 macOS 的集成也非常到位，甚至可以用少量代碼渲染複雜的 Git 差異報告。

這時，我們不得不問自己：到底發生了什麼？

我做了所有專家建議的「正確」事——選擇原生技術路徑、熟悉平台和框架（SwiftUI、AppKit、TextKit 和 WebKit）。但即便如此，在實現一個簡單功能如 Markdown 聊天並選取整個消息時，仍然會遇到無法逾越的障礙。

這一切讓我們開始重新思考：為什麼越來越多的新聊天應用程序選擇使用 Electron 或其他非原生技術？在這個時代，聊天、長文本和靈活的排版是最重要的界面模式之一。或許，這些新興技術能夠更好地解決當前框架中存在的問題，提供更加簡潔且高效的開發體驗。

未來展望

面對這種挑戰，開發者們需要重新評估自己的選擇，考慮非原生技術在某些情況下的優勢。隨著時間的推移，SwiftUI 和其他原生框架可能會迎頭趕上並解決這些問題，但當前來說，開放心態地接受新的技術路徑可能是更佳的策略。

對於開發者而言，這意味著需要更加靈活地考慮不同的工具和平台，以實現最佳的應用程序性能和用戶體驗。