一位拥有近二十年原生 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