一名长期从事 macOS 和 iOS 原生开发的工程师 Artem Loenko 近日写文称，他在用 Swift、SwiftUI、AppKit、TextKit 和 WebKit 实现一个带 Markdown 的聊天界面后，开始重新看待“全原生才是正道”这条行业习惯。
这不是外行对苹果开发工具的情绪化抱怨。Loenko 有近二十年原生开发经验，问题也不是普通表单、设置页或列表页，而是一个今天很多 AI 应用都绕不开的场景：聊天消息支持 Markdown、整段选择，并能随模型输出持续流式更新。他的判断很直接：在长文本、富文本、聊天式界面里，苹果原生文本栈未必仍是默认更优解。
一个简单聊天需求，拆开后并不简单
Loenko 最初尝试用纯 SwiftUI 搭建聊天界面。SwiftUI 可以做出还不错的普通界面，也能覆盖不少滚动列表需求，但当消息由 Markdown 结构组成，用户还要像网页上一样选择整段内容时，限制很快出现：由 SwiftUI 组件拼出的“文档”并不能自然获得完整文本选择能力。
他转向 NSTextView 和 TextKit 2，希望回到苹果传统文本系统。问题变成另一组：与 SwiftUI 集成不顺，已有测试和性能工作难以复用；当文本像大模型回复那样不断追加时，又出现性能波动。继续下探到 NSCollectionView、纯 AppKit 或更底层 TextKit 2，分别遇到单元格闪烁、流式更新困难、现代框架集成差等问题。
| 方案 | 主要优势 | 关键卡点 | 工程判断 |
|---|---|---|---|
| SwiftUI | 写界面快，适合常规页面 | Markdown 文档级选择受限 | 不适合复杂长文本聊天 |
| NSTextView / TextKit 2 | 原生文本能力完整 | 流式更新与 SwiftUI 集成成本高 | 能做，但代价上升 |
| NSCollectionView / AppKit | 成熟、性能基础好 | 单元格刷新、闪烁和状态管理麻烦 | 需要大量手工补洞 |
| WebKit / Electron | Markdown、排版、选择接近开箱可用 | 仍有包体、资源、平台集成成本 | 在富文本聊天里更现实 |
这张表背后的重点是，失败点不是“画不出 UI”，而是那些用户默认认为应该存在的小能力：选择、右键菜单、词典查询、辅助功能、文本交互、排版稳定性。它们单独看都不大，组合起来就是产品体验。
AI 聊天把文本系统推到了前台
过去很多移动和桌面应用的核心界面是按钮、表单、卡片和短列表。SwiftUI 在这类场景里有明确价值，Swift 也仍适合性能敏感模块。变化出现在 2022 年 ChatGPT 发布之后：聊天、长回答、代码块、表格、引用、diff、数学公式和 Markdown 混排，开始成为生产力软件的主界面。
这解释了为什么不少新一代 AI 客户端、知识库和开发者工具会选择 Web 技术。Electron 常被批评占内存、包体大、启动慢，Slack、VS Code、Discord 都长期处在这种争议里。但在文本渲染这件事上，浏览器栈有现实优势：HTML、CSS、Selection API、成熟 Markdown 渲染器和大量前端组件，刚好覆盖了聊天产品最难补齐的一层。
这里不能把 Loenko 的经历上升为苹果官方承认的系统缺陷，也不能推出“SwiftUI 不值得用”的结论。更准确的说法是：当产品核心不是原生控件，而是可选择、可复制、可持续更新的富文本流，原生框架的优势会被重新计价。
受影响的是技术选型，不是信仰输赢
最该读这篇文章的不是普通用户，而是正在做 AI 聊天、Markdown 编辑器、代码审阅、知识库和富文本阅读器的团队负责人。选 SwiftUI 还是 Electron，不再只是“高级”或“偷懒”的审美题，而是会影响排期、测试范围和后续维护的人力预算。
如果团队已经有成熟前端能力，且产品主体是富文本聊天，先用 WebKit 或 Electron 验证体验，可能比全原生重造一套文本行为更稳。若产品依赖系统级性能、低功耗、原生传感器或深度平台能力，Swift 和 AppKit 仍有位置。真正要盯的变量，是苹果后续会不会让 SwiftUI 的文本选择、AttributedString、TextKit 2 和流式渲染更好地打通。现在看，这个缺口已经从边缘体验变成 AI 应用的主路径成本。