原生Mac UI的总结
摘要
作者讨论了原生Mac用户界面对于用户熟悉度和开发者努力的重要性正在减弱,以Things和NetNewsWire等应用为例,并反思了macOS开发中的趋势变化。
<p><a href="https://lobste.rs/s/vvg9ue/about_wraps_it_up_for_stock_mac_ui">评论</a></p>
查看缓存全文
缓存时间: 2026/09/22 20:40
# 原生Mac用户界面的故事到这里也该告一段落了
来源:https://inessential.com/2026/09/22/that-about-wraps-it-up-for.html
最新版macOS朝着打造美观的Mac用户界面迈出了不错的一步,但我真心希望它能更进一步。
我尤其不喜欢Mac工具栏的呈现方式。不喜欢全高侧边栏,更不喜欢那个"液态玻璃"按钮。
我查看了其他Mac应用的做法。我在个人微博(https://micro.inessential.com/2026/09/21/now-that-were-a-year.html)上提问(该微博会同步至Mastodon:https://indieweb.social/@brentsimmons/117310475883194321),也参考了几天前Isaiah类似提问(https://mastodon.social/@isaiah/117299199842156790)下的回复。
结果毫不意外:许多公认设计精良的应用都没有采用原生界面。
你早就知道这点。我认为无需证明。但可以拿Things(https://culturedcode.com/things/)作为典型案例:
Things因其设计和"Mac风范"而屡获赞誉。但它实际上根本不是原生Mac应用。工具栏不在窗口顶部(不是NSToolbar),也不支持自定义。主界面没有任何液态玻璃风格的透明效果——比如内容不会从侧边栏下方滑过。(我唯一发现明显采用液态玻璃设计的地方,是设置窗口的工具栏按钮。)
我长期以来一直坚定主张使用原生Mac界面,总以为理由充分:用户早已熟悉这种界面,而且每年创建和更新所需的工作量更少。
### 剧情转折
我认为这些理由(用户熟悉度和开发工作量)可能不再完全成立。至少在当下如此。
用户已经表明——再次强调,无需证明——他们并不在意原生Mac应用与自定义应用的区别。他们会因为Things没有提供可自定义的顶部工具栏而反感吗?不会。(只有像我这样的资深Mac开发者才会这么想。)
用户能否轻松理解那些热门Mac应用的界面——无论是Things、Slack、Craft、OmniFocus、NotePlan、Bear、Reeder、Telegram、Acorn、Tapestry、Obsidian、Audio Hijack还是其他应用——无论它们采用原生设计与否?完全可以。
他们能看出某个应用是Electron应用吗?根本不能:他们既没有Electron的概念,就算你解释了也不在乎。(何必在乎呢?)
用户或许已经熟悉原生Mac界面(也可能并不熟悉,取决于他们使用的应用),但我认为这已不再重要。
### 那么开发工作量呢
原本的设想是:使用原生Mac界面能让开发者坐享其成——主要通过每年免费或只需极少工作量就能获得macOS的大部分更新,因为你每年都跟进了适配。
但我的应用NetNewsWire采用非常标准的原生Mac界面,去年适配液态玻璃却耗费了大量工作。使用原生界面并没有帮我们省事——事实上,与采用更多自定义界面的应用相比,我们的工作量反而更大。
回到Things的例子。需要说明的是,我并非针对他们。恰恰相反!我非常尊重他们的工作,尽管我曾希望它能更"Mac风格"(再次强调,只有资深Mac开发者才会这么想)。
这是他们一年前发布的关于适配液态玻璃的博文(https://culturedcode.com/things/blog/2025/09/things-for-os-26/)。他们确实做了些工作,而且保持着一贯的高品质。我并非贬低这些工作。但看起来他们的工作量比我们在NetNewsWire上的要少得多。
这就是我的观点:对于原生Mac应用,开发者的工作量反而**更高**。
### 使用原生Mac界面的第三个隐秘理由
总结一下:使用原生Mac界面的理由是——1)用户熟悉度,我们早已知道这根本不成立;2)期望减少开发工作量,但事实可能适得其反。
但还有第三个理由:原生Mac界面由苹果设计——世界上最好的设计师——你真的认为自己能做得更好吗?真的吗?
应用世界里充满了自认为比苹果设计更好的人,但实际上他们远远做不到。
嗯,我仍然认为苹果拥有世界上最优秀的UI设计师团队,但不知何故,上层关于Mac界面设计的指导未能切中要害。我并非批评执行工作的员工——他们在既定方向上做得非常出色。
所以——糟糕的方向指引——这就是第三个隐秘理由失效的原因。如今我们找不到真正值得坚守原生Mac界面的理由了(除了想获得像我这样的资深Mac人士认可,而你完全不该在意这点)。
### 昨晚的实验
带着这些思考,我尝试在NetNewsWire中尽可能移除我不喜欢的液态玻璃元素。结果发现进展相当不错,尽管代价是放弃了NSToolbar(正如预料)。
注意:这些改动只存在于某个分支上。仅是夜间实验,并非正式设计或深思熟虑的成果。(但这是实际代码,不是概念图。)它不会以这种形态发布。但我仍然要分享,因为它确实暗示了NetNewsWire未来的某些可能方向。
点击查看完整大图。
[](https://ranchero.com/images/netnewswire-minus-glass.png)
[](https://ranchero.com/images/netnewswire-minus-glass-columns.png)
(注意第二张截图中的列视图将在7.2版本发布。该功能已开发完成,与是否采用液态玻璃无关。另外注意:当前使用的文章主题是NetNewsWire标准应用的一部分,并非新功能。)
显然,我首先能做的改进是为工具栏图标添加颜色并调整布局。或许还能增加一些自定义功能,即使它不是标准的Mac工具栏。
当然,你看到这个设计可能会觉得"呃!太老土了!别让我看!"完全合理!
但它确实挺可爱的。也许以后会删掉。
相似文章
在 2026 年使用 SwiftUI 构建纯正的 Mac 应用
这篇文章讲述了作者完全使用 SwiftUI 构建 macOS 应用的经验,讨论了在实现原生 Mac 体验时遇到的挑战和限制,例如选中状态和非活动窗口的行为,并得出结论:SwiftUI 在 Mac 上尚不足以构建‘纯正 Mac’应用。
引用约翰·格鲁伯
约翰·格鲁伯讨论了苹果的竞争优势正在减弱,因为越来越少的开发者有动力为苹果平台打造独家的高质量原生应用,导致第三方软件质量向行业平均水平回归。
别再做终端界面了
作者主张用原生用户界面替代终端界面,并展示了几个借助AI以极少量代码创建的应用程序。
关于使用 SwiftUI 构建 macOS 应用的 WWDC 27 更新
本文介绍了 WWDC 27 中 SwiftUI 的改进,用于构建 macOS 应用,涵盖选中状态、拖放和键盘快捷键的新 API。
Tolaria、Rust,以及关于 Mac 应用“手感”的思考
作者评测了 Tolaria,这是一款使用 Rust 和 React(通过 Tauri 框架)构建的快速轻量级 macOS 知识库应用,称赞其类原生体验以及与 Electron 替代品相比的开发速度。