Native all the way, until you need text
446 points
• 1 day ago
• Article
Link
作者是位拥有近二十年 macOS 和 iOS 开发经验的资深工程师，坦率地分享了在用苹果原生框架构建富文本界面时遇到的局限。他尝试用纯 Swift 和 SwiftUI 实现一个支持 Markdown 的简单聊天功能，却屡屡受阻：SwiftUI 对基础界面足够，但在复杂文本处理上力不从心，像是无法从其原语上直接选中整个由 Markdown 组成的文档，这类限制是其设计所致。
为此他尝试了其他原生方案，先从 NSTextView 和 TextKit 2 入手，但要把它们和现有的 SwiftUI 代码整合非常困难，而且流式文本（现代聊天的常见需求）会引起明显的 CPU 峰值。接着他试了成熟且性能优良的 NSCollectionView，却发现单元格会不可预测地闪烁，仍然是设计层面的问题。即便用纯 TextKit 2 做底层原型，性能能接受，但在文本流式传输和与现代开发实践的兼容性方面仍然捉襟见肘。
令他最沮丧的是，要把 macOS 上那些被期望的文本行为做齐做全，需要投入巨大的工程量：上下文菜单、词典查询、平滑的选区、无障碍支持和直观的文本交互等，可能要耗费数月时间。于是他试用了 WebKit 来渲染 Markdown，发现排版和可控性都很好。但最出乎意料的是最后一次实验：他生成了一个简单的 Electron 项目，本以为会有妥协，结果却发现文本操作、 Markdown 渲染和排版开箱即用且表现出色，性能甚至超过了他最好的原生实现。
基于这一系列经验，他不得不做出一个艰难的结论：即便在 SwiftUI 、 AppKit 、 TextKit 和 WebKit 都很精通的情况下，他也无法仅用苹果的原生工具构建一个功能齐全、面向长篇富文本且排版灵活的聊天界面。对于以长篇富文本和灵活排版为核心的应用——这是当下主流的界面模式——苹果原生 SDK 很可能不再是优势而成了限制。他同时承认 Swift 在性能关键场景下依然出色，但像 Electron 或 React Native 这样的框架通过原生互操作性能提供相当的性能，同时在文本处理和渲染模型上更胜一筹。最终，他的体会是：针对这个特定且关键的使用场景，基于 Web 的技术目前没有可行的原生替代方案。
The author, a veteran macOS and iOS developer with nearly two decades of experience, shares a candid reflection on the limitations of native Apple frameworks when building rich text interfaces. He recounts his attempt to implement a simple Markdown-supported chat feature using pure Swift and SwiftUI, only to encounter persistent roadblocks. While SwiftUI performs adequately for basic screens, it falls short for complex text handling, such as selecting an entire Markdown document built from its primitives, a limitation inherent to its design.
Faced with these constraints, the author explores alternative native solutions, starting with `NSTextView` and TextKit 2. However, integrating these with existing SwiftUI code proves difficult, and streaming text, a standard feature in modern chat applications, causes significant CPU spikes. He then turns to `NSCollectionView`, a mature and performant AppKit component, but discovers that cells blink unpredictably, another design-level issue. Even a lower-level prototype using pure TextKit 2 yields acceptable performance but still struggles with text streaming and compatibility with modern development practices.
The core of the author's frustration lies in the immense effort required to achieve basic macOS text behaviors. Replicating expected functionalities like context menus, dictionary lookups, smooth selection, accessibility, and intuitive text interactions would take months of work. This stark reality leads him to experiment with WebKit for Markdown rendering, which performs well with good typography and control, but it is his final experiment that proves most revealing. In a moment of desperation, he generates a simple Electron project, expecting compromise, but instead finds that text operations, Markdown rendering, and typography work flawlessly out of the box, with performance surpassing his best native implementations.
This experience forces a difficult conclusion. Despite his deep expertise in SwiftUI, AppKit, TextKit, and WebKit, he cannot build a functional, feature-rich chat interface using Apple's native tools. The author argues that for applications centered on long-form rich text and flexible typography, the dominant interface pattern of the current era, native Apple SDKs are no longer an advantage but a constraint. He acknowledges that Swift remains excellent for performance-critical tasks, but contends that frameworks like Electron or React Native offer comparable performance through native interoperability while providing a far superior text and rendering model. The post ends with a sobering realization that for this specific, crucial use case, there is no viable native alternative to web-based technologies.
301 comments • Comments Link
- 在经历了十多年针对 GPU 加速和复杂 Web 应用的实践与压力测试后，浏览器渲染引擎已经显著成熟，因此单纯以性能为由支持原生 API 的论点不再像过去那样有说服力。
- SwiftUI 受到性能方面的批评：有人指出，苹果自家的 System Preferences 在切换分区时会卡顿，尽管争论焦点在于这是 SwiftUI 的问题还是更广泛的原生开发问题。
- SwiftUI 与原生开发之间的差异很重要：正确设计的 Qt C++/QML 应用相比类似的 Web 应用，通常在性能和内存使用上有明显优势。
- 报道称，SwiftUI 在 xOS 26 中性能有所改善，而且大多数非平凡的 SwiftUI 应用都会结合使用 UIKit/AppKit 来补充 SwiftUI 尚不完善的功能。
- 跨平台的本地 UI 开发仍然充满挑战；对于希望其应用能在未来数十年内无需重写而保持原生体验的开发者，wxWidgets 被建议为更稳健的长期选择。
- 尽管浏览器引擎已成熟，原生应用与基于浏览器的应用在性能上仍存在显著差异，尤其是在旧款 Chromebook 等低功耗设备上，浏览器运行表现较差。
- SwiftUI 在对大型数据集的增量更新方面存在困难，这也是苹果历史上缺乏可用 SwiftUI 文本视图组件的原因之一，虽然后来在 2025 年随着增强型 TextEditor 的推出有所改善。
- 内存使用已成为优先选择原生 API 而非 Web 视图的主要原因之一：即便原始性能差距缩小，内存效率仍是显著的分水岭。
- 像 VS Code 这样的复杂应用在性能上仍低于原生应用的上限，说明简单的 Web 应用或许能匹配原生性能，但高要求的应用仍然受益于原生开发。
- V8 通过把 JavaScript 做到极快而非在浏览器中运行原生代码的路径取得成功；在渲染方面的类似进展也使得 Web 技术对大多数 GUI 需求（除去专门的硬件密集型应用）成为可行选择。
- 在性能和资源消耗方面，AppKit 仍优于 SwiftUI 和 Web 渲染，这表明老旧的苹果框架对高要求应用仍更为适合。
- 富文本渲染（包括恰当的双向文本支持、字形塑造、混合内容和自然选择）仍是软件中最难的问题之一，浏览器引擎是唯一能正确处理所有复杂性的实现。
- 在 macOS 上用 WebKit 渲染 Markdown 从技术上是合适的：Markdown 本质上会被转成 HTML，而 WebKit 是原生的 HTML 渲染器，但每个 WKWebView 实例都带来显著的内存和性能开销。
- Web 和原生 UI 工具包之间的成熟度差距源自投资模式：大量开发工作流向 Web 技术，因为它们"能直接工作"，形成了正反馈循环，导致原生框架受关注较少，难以完善。
- iOS 开发的历史背景很重要：即便在 Objective-C/UIKit 时代，实现段落中可点击链接这类基本任务也非常困难，开发者因此期待 SwiftUI 在文本处理方面能达到与 Web 相当的能力。
- HTML/CSS 依然是生产力和性能最强的 GUI 系统：Web 作为文档呈现机制的本质使其在文本密集型应用中具有天然优势。
- 对于需要流式传输 Markdown 并支持文本选择的 AI 聊天应用，原生方案仍存在问题：多个文本编辑组件在渲染时会出现卡顿和 UI 锁定，因而尽管有内存和性能代价，Web 视图成为更务实的选择。
- macOS 上的 TextKit 2 公共 API 存在重大问题，开发者不得不为一些本不应出现的问题做变通，部分人甚至在探索完全绕开 TextKit 的方案。
- 现代苹果开发栈在为聊天型 UI 设计架构时显得尴尬：NSTextView 不能自然地与 SwiftUI 整合，迫使开发者要么深度依赖 AppKit，要么与 SwiftUI 的数据模型抗争。
- 跨平台原生 GUI 开发相比 Web 开发仍属于利基市场；Chrome 代表了全球资金最充足的软件项目，这解释了为什么 Web 技术"能直接工作"，而原生框架在一致性和完善度上难以匹敌。
- Electron 在老旧硬件上表现欠佳；虽然原生 UI 框架自身也有问题，但追求高性能文本渲染的开发者可能需要降低对字体复杂性的要求，并避免带有 JavaScript 生态包袱的基于 JSON 的配置。
- 性能的定义因用例而异：一些开发者更看重流式传输时的稳定 FPS 和平滑滚动，而不是极致的内存效率，认为为节省数百兆甚至数 GB 内存而牺牲用户体验对日常使用数小时的应用并不划算。
- 原生移动开发的开发者体验仍然较差：像创建平滑滚动元素这样的简单任务可能需要数小时的变通和大量 Stack Overflow 研究，这也推动开发者转向虽有开销但更高效的 Web 技术。
讨论表明，原生技术与 Web 技术之间的性能差距在许多场景已明显缩小，但关键差异依然存在。浏览器渲染引擎已能处理许多原生框架仍在挣扎的复杂文本渲染与布局任务，尤其是富文本、 Markdown 和流式内容；但这并不意味着原生开发会过时，因为在低功耗设备上的内存效率和需要深度平台集成的专业应用仍倾向于原生做法。核心矛盾在于：Web 技术在文本处理能力和生态成熟度上占优，而原生开发在资源效率和平台集成上有优势。 SwiftUI 因性能问题和 API 不完整受到批评，但对一些场景来说它仍是方便的选择，并可在需要时由 AppKit/UIKit 补充。对于像 AI 聊天界面这样的文本密集型应用，Web 视图已成为务实之选，尽管在资源受限或需深度平台集成的环境中，原生开发仍然是首选。 • Browser rendering engines have matured significantly with GPU acceleration and over a decade of stress-testing by complex web apps, making the traditional performance argument for native APIs less compelling than it once was.
• SwiftUI specifically faces criticism for poor performance, with Apple's own System Preferences app showing lag when switching sections, though some argue this is a SwiftUI issue rather than a native development problem overall.
• The distinction between SwiftUI and native development matters, as Qt C++/QML applications demonstrate significantly better performance and lower RAM usage compared to similar web apps when properly engineered.
• SwiftUI's performance profile has reportedly improved with xOS 26, and most non-trivial SwiftUI apps also incorporate UIKit/AppKit for capabilities not yet available in SwiftUI.
• Native UI development remains challenging across platforms, with wxWidgets suggested as a more stable long-term choice for developers committed to native development who want their apps to run for decades without complete rewrites.
• Despite browser engine maturity, there remains a stark performance difference between native apps and browser-based applications, particularly on low-powered devices like older Chromebooks where browsers run poorly.
• SwiftUI struggles specifically with incremental changes to large data sets, which is why Apple has historically lacked a usable SwiftUI text view component, though improvements arrived in 2025 with the enhanced TextEditor.
• RAM usage has become the primary reason to prefer native APIs over web views, as memory efficiency remains a significant differentiator even when raw performance gaps have narrowed.
• Complex applications like VS Code still hit performance ceilings lower than native apps, suggesting that while simple web apps may match native performance, demanding applications still benefit from native development.
• The V8 JavaScript engine's approach of making JavaScript extremely fast rather than finding ways to run native code in browsers proved successful, and similar progress has occurred on the rendering side, making web technologies viable for most GUI needs except specialized hardware-intensive applications.
• AppKit still outperforms both SwiftUI and web rendering in terms of performance and resource consumption, suggesting that Apple's older frameworks remain superior for demanding applications.
• Rich text rendering with proper bidirectional text support, glyph shaping, mixed content, and natural selection remains one of software's hardest problems, with browser engines being the only implementations that come close to handling all complexities correctly.
• Using WebKit to render Markdown on macOS is technically appropriate since Markdown transpiles to HTML and WebKit is the native HTML renderer, though each WKWebView instance carries significant memory and performance overhead.
• The maturity gap between web and native UI toolkits stems from investment patterns, with most development effort flowing to web technologies because they "just work," creating a cycle where native frameworks receive less attention and remain less polished.
• Historical context matters for iOS development, as even basic tasks like rendering clickable links within paragraphs were extremely difficult in Objective-C/UIKit, and developers expected SwiftUI to provide better text handling parity with web capabilities.
• HTML/CSS remains the most powerful GUI system for productivity and performance, with the web's fundamental nature as a document presentation mechanism giving it inherent advantages for text-rich applications.
• For AI chat applications requiring streaming Markdown with text selection, native solutions remain problematic, with developers reporting slow, laggy rendering and UI lockups across multiple text editor components, making web views the pragmatic choice despite their overhead.
• TextKit 2 on macOS has significant issues with its public API, requiring developers to implement workarounds for problems that shouldn't exist, though some developers are researching solutions that bypass TextKit entirely.
• The modern Apple development stack creates awkward architectural choices for chat-style UIs, as NSTextView doesn't integrate naturally with SwiftUI, forcing developers to choose between deep AppKit integration or fighting SwiftUI's model.
• Cross-platform native GUI development remains niche compared to web development, with Chrome representing the best-funded software effort globally, explaining why web technologies "just work" while native frameworks struggle with consistency.
• Electron performs poorly on older hardware, and while native UI frameworks have their own issues, developers seeking performant text rendering may need to reduce expectations regarding font complexity and avoid JSON-based configuration that carries JavaScript ecosystem baggage.
• Performance definitions vary by use case, with some developers prioritizing stable FPS and smooth scrolling during streaming over raw memory efficiency, arguing that sacrificing UX to save hundreds of megabytes or even gigabytes of RAM isn't worthwhile for apps used hours daily.
• The developer experience for native mobile development remains poor, with simple tasks like creating smooth scrollable elements requiring hours of workarounds and Stack Overflow research, driving developers toward web technologies despite their overhead.
The discussion reveals a nuanced landscape where the performance gap between native and web technologies has narrowed significantly for many use cases, yet important distinctions remain. Browser rendering engines have indeed matured to handle complex text rendering and layout tasks that native frameworks still struggle with, particularly for rich text, Markdown, and streaming content. However, this doesn't render native development obsolete, as performance on lower-powered devices, memory efficiency, and specialized applications still favor native approaches. The core tension appears to be between web technologies' superior text handling capabilities and mature ecosystem versus native development's resource efficiency and platform integration. SwiftUI specifically draws criticism for performance issues and incomplete APIs, though some defend it as a convenient option that can be supplemented with AppKit/UIKit when needed. The conversation suggests that for text-heavy applications like AI chat interfaces, web views have become the pragmatic solution despite their overhead, while native development remains preferable for resource-constrained environments and applications requiring deep platform integration.