一直都是原生的，直到您需要文本为止

我作为 macOS / iOS 原生开发人员已经有近二十年了，对于通常的“哦，又是 Node / Electron 了……真可惜……”的反应，我想说点什么。 Recently, I tried to implement a simple chat with Markdown support in a pure Swift / SwiftUI app.老实说，当你走出简单的屏幕时，所有这些“原生”的东西仍然是多么不成熟，这几乎是有趣的。是的，您可以在 SwiftUI 中实现合理的性能。您甚至可以说服自己，跳跃式滚动没有问题，并且这里和那里的一些滞后是可以接受的。但是，您想要选择从 SwiftUI 原语构建的整个 Markdown 文档，但您却做不到。通过设计。因此，聪明且经验丰富，您可以转向 NSTextView 。现在它甚至支持 TextKit 2。伟大的。但现在你失去了围绕 SwiftUI 所做的大部分测试和性能工作，因为它不能很好地配合它。然后你尝试将文本流式传输到其中，因为现在是 2026 年，现在每个人都从模型中流式传输响应，你开始看到 CPU 峰值。美好的。我们还有 AppKit。我们仍然有 NSCollectionView 。成熟、高效、久经考验。所以你再次切换，实施整个事情，第二天你意识到细胞无论如何都会闪烁。通过设计。然后你甚至考虑使用纯 TextKit 2 进行较低级别的设计。你制作了一个原型。性能还可以。流媒体仍然很糟糕。它与任何现代事物都不能很好地配合。您完全删除 SwiftUI，坚持使用 AppKit，并开始手动扩展文本块。此时几乎所有内容都已损坏，但是嘿，您可以选择文本！然后你意识到需要几个月的时间才能达到与基本原生 macOS 行为相同的功能：上下文菜单、字典查找、选择、可访问性、文本交互，以及用户不假思索地期望的所有小事情。所以你尝试用WebKit来渲染Markdown。它有效。当然，也有一些警告，但大多数情况下它都是有效的。性能良好。排版几乎是完美的。你有适当的控制水平。然后，在最黑暗的时刻，你想：好吧，让我们生成一个简单的 Electron 项目。你走向黑暗面。你很惊讶。文本操作、Markdown 渲染、良好的排版——所有这些都是开箱即用的，其性能甚至无法从纯 TextKit 2 实现中获得。 macOS 集成也在那里。您甚至可以用几行代码呈现精美的 Git 差异。我什至没有谈论像 diffs.com 这样的事情。然后你问自己：出了什么问题？我做了人们说你应该做的一切。一路原生。我知道这个平台。我知道选项。我知道 SwiftUI、AppKit、TextKit、WebKit。但我仍然无法让一个简单的事情正常工作：使用 Markdown 聊天以及选择整条消息的能力。突然之间，为什么大多数依赖于这个时代最重要的界面模式之一（聊天、长格式富文本、灵活排版）的新聊天应用程序都以某种方式基于网络，这一点变得更加清晰。没有真正的替代方案。 SwiftUI 适合简单的屏幕，最好不要太多滚动。 Swift 仍然非常适合性能关键的部分。但是，您可以通过本机互操作性几乎免费地从 Electron 或 React Native 获得大部分性能，同时保持更好的文本和渲染模型。因此，这甚至不再是“快速解决方案与正确解决方案”的争论。如果您想为长格式聊天构建富文本渲染，SwiftUI 和 Apple 的本机 SDK 无法帮助您。它们不再是优势，而是开始成为限制。