一位拥有近二十年原生 macOS 和 iOS 开发经验的开发者近日分享了他的最新感悟,揭示了一个看似违背直觉的事实:在复杂文本处理场景下,Electron 等 Web 技术反而比 Apple 原生框架更加可靠。

Artem Loenko 在其博客中记录了这段颇为曲折的技术探索之旅。他原本打算在一个纯 Swift / SwiftUI 应用中实现一个支持 Markdown 的简单聊天功能,然而很快发现,当脱离简单界面范畴后,所有这些"原生"技术都显得极其不成熟。
问题接踵而至。首先,他想选择一个由 SwiftUI 原生构建的整个 Markdown 文档,这从根本上就无法实现。转而使用 NSTextView 后,虽然获得了 TextKit 2 支持,但大部分围绕 SwiftUI 构建的测试和性能优化工作都打了水漂,因为 NSTextView 与 SwiftUI 配合并不理想。当他尝试向 NSTextView 流式输入文本时,CPU 占用率开始飙升。他转向 NSCollectionView,这个看似成熟、高性能、经过实战检验的方案,结果第二天就发现单元格会不受控制地闪烁——这同样是设计层面的限制。
即便他考虑降级到纯 TextKit 2,虽然性能尚可,但流式文本处理依然糟糕,与现代框架的配合一团糟。他彻底放弃了 SwiftUI,完全转向 AppKit,开始手动处理文本扩展块,此时几乎所有功能都出现了问题,但至少——终于可以选中文字了。
这套方案距离达到基本原生 macOS 行为的功能对等还需要数月之久:上下文菜单、词典查询、文本选择、无障碍访问、各种用户理所当然期待的小功能。
最终,他尝试使用 WebKit 来渲染 Markdown。结果立竿见影——除了一些注意事项外,基本上完美运行。性能出色,版式几乎无可挑剔,他获得了恰到好处的控制权。在最困难的时刻,他甚至想到了生成一个简单的 Electron 项目。他去了"黑暗面",然后惊讶地发现:文本操作、Markdown 渲染、精美的排版——所有这些都开箱即用,性能甚至超过了他之前那套纯 TextKit 2 实现。macOS 集成同样完备,甚至可以用几行代码渲染精美的 Git diff 对比。
这一经历让他豁然开朗:为什么大多数依赖聊天、长篇富文本、灵活排版等这个时代最重要的界面模式之一的新款聊天应用,在某种程度上都是基于 Web 的。这没有真正的替代方案。
Loenko 总结道,SwiftUI 适合简单屏幕,尤其是那些不需要太多滚动的场景;Swift 在性能关键部分仍然出色。但如果你想构建富文本渲染、长篇聊天或灵活排版,SwiftUI 和 Apple 的原生 SDK 并不能提供帮助,反而开始成为限制。这甚至不再是"快速解决方案与正确解决方案"的争论——如果你想构建富文本渲染,Apple 的原生工具已经不再是优势,而是约束。
参考来源:
- 原文链接:https://justsitandgrin.im/posts/native-all-the-way-until-you-need-text/
- Hacker News 讨论:https://news.ycombinator.com/item?id=48168058