让我先说明一下，性能这个问题很复杂，而且不幸的是，比你想象的要更加……宗教化。一个很好的例子就是Objective-C社区过去坚持认为良好的性能与垃圾回收不兼容，尽管几十年来已经证明并非如此。这篇关于Swift被node.js打得措手不及的文章[1]很有趣，可以看到一个社区如何用结果来挑战他们的预期（“你指望什么，JS的BigInt是经过优化的，而我们的不是”，“它更慢，但使用的RAM更少！”等等）。事实上，像GC与引用计数这样的问题，往往比单纯哪个更快要更加复杂（也更令人不满意）。你最终会得到很多不令人满意的结论，比如一个更确定性但通常更慢（而且事实上大多数UIKit应用都不是实时系统）。所有这些想说明的是，很难在一条评论中回答这个问题，但为了总结我的观点，我认为Swift的性能优势过去和现在都被夸大了。…

精彩的文章。Objective-C仍然是我首选的编程语言。 > 现在，我确信有人会争辩说，整个技术栈最终都会用Swift，那时这个问题就不存在了，但我们现在谈论的是一个20年的计划，看起来把我的计算器应用的代码作为关键的第一步似乎很奇怪。 看来至少有一些苹果的人是这么想的。但很多Swift框架都依赖于Objective-C框架（SwiftUI包装了很多UIKit。SwiftData是建立在CoreData之上的，等等）。 二十年后，Swift的年龄将大致等于Swift出现时Objective-C的年龄（可能有几年的差异）。到那时，Swift的使用者将变得年迈和灰白。我认为合理地赌注是，届时一些年轻人将推动一种新的编程语言/UI框架。我不确定苹果即使想替换整个Objective-C栈也能够做到…

关于垃圾回收的讨论，很多没有经历过Objective-C垃圾回收项目失败的人可能不知道，ARC是从一个失败的项目中转变而来的，但苹果以他们一贯的方式推销了这段历史。 Objective-C的垃圾回收失败了，因为底层的C语义，它永远不会比典型的保守式垃圾回收更好，并且在混合使用GC和非GC编译的代码时，经常出现应用程序崩溃。 因此，他们选择了下一个最佳策略，即自动化Cocoa的retain/release消息对，并将其宣传为比GC更好，因为性能等原因，而不是因为垃圾回收方法失败了。 自然地，正如.NET与COM的复杂互操作层所证明的那样，考虑到Objective-C的发展，Swift采用相同的方法会更好，而不是创建类似CCW/RCW的复杂层。 现在越来越…

作为一名对苹果应用开发感兴趣的人，你会推荐仍然从ObjC开始吗？我注意到Swiftcord应用（用Swift开发的开源Discord客户端）的开发者已经详细指出，你仍然需要调用UIKit来完成很多事情，因为SwiftUI有很多死胡同。