一直坚持原生，直到你需要处理文本：原生 UI 的隐藏成本

在近二十年的时间里，Apple 生态系统中的主流观点一直是“一直坚持原生”。这个承诺很简单：通过使用 SwiftUI、AppKit 和 TextKit，你可以获得无与伦比的性能、深度的 OS 集成以及精致的用户体验。但对于许多开发者来说，一旦他们尝试构建一个现代化的、以文本为核心的界面——特别是支持 Markdown 的聊天应用时，这个承诺就碰壁了。

在最近一篇具有启发性的文章中，资深 macOS/iOS 开发者 Artem Loenko 描述了他在尝试实现一个简单的聊天界面时陷入“开发地狱”的过程。他的经历凸显了现代软件工程中日益增长的紧张关系：原生框架的感知效率与实现复杂文本渲染的实际生产力成本之间的差距。

原生之痛：从 SwiftUI 到 TextKit

Loenko 的旅程始于 SwiftUI，这个现代的声明式框架。虽然它能够处理简单的屏幕，但他发现它在处理富文本交互方面根本无法胜任。主要的崩溃点在于一个基本的用户预期：能够选择由 SwiftUI 原语构建的整个 Markdown 文档。从设计上讲，这几乎是不可能的。

为了寻求更强大的解决方案，他在 Apple SDK 层级中不断尝试，每一步都感觉像是生产力的倒退：

• NSTextView & TextKit 2: 虽然提供了更好的文本控制，但它使项目脱离了在 SwiftUI 中已经完成的性能和测试工作。
• AppKit & NSCollectionView: 一种经过实战检验的方法，但深受“单元格闪烁”问题的困扰，而这似乎是设计使然。
• Pure TextKit 2: 一个低层级的原型，提供了可以接受的性能，但在流式文本处理方面表现糟糕——这对于现代 AI 驱动的聊天应用来说是不可或缺的要求。

Loenko 得出结论，要达到与基础 macOS 行为一致的功能水平——如上下文菜单、词典查询和辅助功能——需要数月的体力劳动。这正是“黑暗面”变得具有吸引力的地方：Electron。

“Electron 悖论”

当 Loenko 最终转向 Electron 时，他发现文本操作、Markdown 渲染和排版功能开箱即用，其性能甚至可以媲美或超过他纯 TextKit 2 的实现。

这创造了一个悖论。开发者经常嘲笑 Electron “臃肿”或“慢”，但对于富文本而言，浏览器引擎（Blink/WebKit）往往是机器上优化程度最高的软件部分。

正如一位评论者 @pornel 所指出的：

"浏览器渲染引擎在目前阶段已经非常成熟，拥有显著的 GPU 加速，并且经过了十多年臃肿的 Web 应用的压力测试。与此同时，SwiftUI 并不觉得特别快。"

社区辩论：是技能问题还是系统性失败？

围绕这一经历的讨论呈现出明显的两极分化。一些开发者认为这是“技能问题”，并指向现有的原生库或他们在 TextKit 上的成功经验。

• 拥护原生派： 一些用户，如 @lenkite 和 @msephton，认为 SwiftUI 中已经存在成熟的 Markdown 渲染器，或者认为如果实现正确，TextKit 2 可以具有极高的性能。@msephton 引用了他们构建的一个文本编辑器，该编辑器可以在 150ms 内处理 20 次快速按键并进行完整的重新样式化。
• 系统性失败派： 其他人则同意 Loenko 的观点，认为让原生文本“正常工作”所需的巨大努力是令人望而却步的。@splittydev 呼应了这一点，表示在尝试了五个流行的 GitHub 组件（针对 UIKit/SwiftUI）后，所有组件都“以某种方式损坏、有 Bug 且运行缓慢”。

中间道路：混合渲染

在讨论中反复出现的一个建议是混合方法：使用原生框架构建应用外壳（菜单、工具栏、导航），并专门为富文本内容使用 WKWebView。

这种方法承认了 HTML/CSS 是 GUI 文本渲染中最强大的系统。正如 @iamcalledrob 所指出的，这并不是一个新发现；macOS 的早期版本和最初的 iPhone 的 UITextField 实际上都是由 WebKit 支持的，因为“文本处理很困难”。

结论：选择正确的工具

这场辩论的核心并不在于原生框架是否可以做到，但在于它是否应该作为文本密集型应用的默认选择。对于高性能、专业化的工具——如数字音频工作站 (DAWs) 或 3D 建模软件——原生是不可或缺的。但对于现代“聊天密集型”的软件时代，与原生框架抗争的成本可能超过了其带来的收益。

正如社区共识所暗示的，浏览器引擎不仅仅是一种构建网站的方式；它是目前世界上资金投入最重、优化程度最高的文本渲染引擎。当目标是灵活的排版和无缝的 Markdown 流式传输时，有时最具有“原生”感的体验，反而是构建在 Web 技术栈之上的。