全程原生，直到你需要文本

# 一路原生，直到你需要文本 | Artem Loenko 来源：https://justsitandgrin.im/posts/native-all-the-way-until-you-need-text/ 我做了近二十年的原生 macOS / iOS 开发者，想聊聊那种常见的"哦，又是 Node / Electron……真丢人……"的反应。 最近，我尝试在一个纯 Swift / SwiftUI 应用中实现一个支持 Markdown 的简单聊天功能。说实话，当你走出简单的界面时，所有这些"原生"的东西有多么不成熟，简直有点可笑。没错，你可以在 SwiftUI 中获得合理的性能。你甚至可以说服自己，跳跃滚动没问题，偶尔的卡顿也可以接受。但接着你想选中一个用 SwiftUI 原语构建的完整 Markdown 文档，却做不到。设计上就不行。 于是，聪明又经验丰富的你转向了 `NSTextView`。它现在甚至支持 TextKit 2 了。很好。只是现在你失去了在 SwiftUI 周围做的测试和性能优化成果，因为它与 SwiftUI 配合不好。然后你尝试往里面流式传输文本——因为现在是 2026 年，大家都在流式传输模型的响应——然后你开始看到 CPU 峰值。没关系。我们还有 AppKit。我们还有 `NSCollectionView`。成熟、高性能、久经考验。于是你又换了一次，把整个东西实现了，结果第二天你发现无论如何单元格都会闪烁。设计上就如此。 然后你甚至考虑用纯 TextKit 2 走更底层。你做了个原型。性能还行。流式传输仍然很糟糕。它和任何现代的东西都不好配合。你完全移除了 SwiftUI，坚持用 AppKit，然后开始手动处理不断扩展的文本块。到这时候几乎什么都坏了，但嘿，你能选中文本了！ 接着你意识到，要花好几个月才能达到基本原生 macOS 行为的功能对等：上下文菜单、词典查询、选中、无障碍、文本交互，所有用户不需要思考就期待的细小功能。 所以你尝试用 WebKit 渲染 Markdown。然后它就能用了。当然有陷阱，但基本上就是能用。性能不错。排版几乎完美。你有适当的控制权。 然后在最黑暗的时刻，你想：好吧，咱们生成一个简单的 Electron 项目。你投奔了黑暗面。 然后你惊了。 文本操作、Markdown 渲染、好的排版——所有这些开箱即用，性能甚至是你纯 TextKit 2 实现都达不到的。macOS 集成也有。你甚至可以几行代码渲染漂亮的 Git diff。我都不用提像 diffs.com (https://diffs.com/) 这样的东西。 然后你问自己：到底哪里出了问题？ 我做了一堆人们说你应该做的事。一路原生。我熟悉这个平台。我熟悉各种选项。我熟悉 SwiftUI、AppKit、TextKit、WebKit。 但我还是没法让一个简单的东西正常工作：一个带 Markdown 且能选中整条消息的聊天。 然后突然就清楚多了，为什么大多数依赖这个时代最重要的界面模式之一——聊天、长文富文本、灵活的排版——的新聊天类应用，都这样或那样地基于 Web。 没有真正的替代方案。 SwiftUI 对简单界面还行，最好没有太多滚动。Swift 在性能关键部分仍然很棒。但你几乎可以通过原生互操作性免费从 Electron 或 React Native 获得大部分性能，同时保持更好的文本和渲染模型。 所以这甚至不再是"快速方案 vs 正确方案"的争论了。如果你想为长文聊天构建富文本渲染，SwiftUI 和 Apple 的原生 SDK 帮不了你。它们不再是优势，反而成了限制。