作者：约翰·格鲁伯；原文链接；译者：Willow
约翰·纳克 (John Nack) 发布了一篇在 iTunes 走向 64 位这一问题上唱反调的文章。纳克问：
我和其他所有人一样，从来没有说要完成 Carbon 到 Cocoa 的重写仅仅是因为它是 Cocoa，所以它更好。64 位问题也是如此。真正重要的是功能和用户体验，而不是实现他们所用的开发技术。·你的 iTunes 真的有性能方面的问题吗？我从来没有过。它筛选我有 3000 个项目的曲库的速度跟我打字一样快，也可以很好地处理高清视频，还可以在 Cover Flow 的封面间飞来飞去。我记不得有听其他人抱怨过。·难道他们想让 iTunes 使用超过 4GB 的内存？我认为我们可以有把握地说“不”·他们抱怨过用户界面（如非标准滚动条），并认为 Cocoa 将会使 iTunes 看起来更像 Mac 程序吗？同样，我没有听到过这种抱怨（或更确切地说，只有荒谬的那种）。即使如此，那又怎样？让我换一种说法：如果你在领导 iTunes 开发团队，作为一个消费者，你何以让他们把本该花在完成其他用户需求的时间花在 Cocoa 或者 64 位上？
当我说苹果似乎无可避免地最终会要带着 iTunes 走向 Cocoa 和 64 位，那不是因为这两种技术将显著地提升其功能和用户体验。我说这似乎是无可避免的，是因为苹果已经将他们大部分的「系统软件」转移到了 64 位。注意苹果的 Snow Leopard 技术特性页面里第一个脚注：
应用程序除了 DVD 播放器、Front Row、Grapher、iTunes 和 X11 之外，都已经重新编译为 64 位版本。几乎一切与 Mac OS X 一起发布的东西都已经是 64 位的了。用户需要一个 64 位的 Dock 吗？有没有人的生活因为 64 位的词典软件而改变？当然不会。对于某些软件，64 位改写真的可以提升其性能，但苹果把它大部分软件都进行改写仅仅是因为现在他们认为这是编译 Mac 软件最好的方法。他们以身作则，为将来做准备。
跟 iTunes 对比，Finder 是一个很好的例子。Snow Leopard 中的 Finder 不仅仅是从 32 位转移到了 64 位，还从 Carbon 转移到 Cocoa。在 Mac OS X 的早年间，Finder 在 WWDC 上被当作 Carbon 的宠儿。它曾是 Carbon 的典范。
不管 Finder 在 Carbon 应用程序界曾是如何先进（它是为 Carbon API 全新编写的，而不是将老的 Classic Mac OS 中的代码进行移植），将它移植到 Cocoa 上一定需要很多工作——而其结果是大多数用户不会觉得它与 10.5 时代的 Carbon Finder 有任何区别。约翰·锡拉库撒 (John Siracusa) 如此介绍了 Snow Leopard 里的 Finder：
向 Cocoa 的转移遵循了 Snow Leopard 的风格：没有新特性……或许有那么一两个。因此，“新” Cocoa Finder 看起来几乎跟老的 Carbon Finder 完全一样。其最具 Cocoa 特征的表现是广泛使用了基于 Core Animation 的过渡。Sven-S.Porst 则有点严厉：
总之，人们可能投入很大精力来创造了一个跟老版本一样难用的 Finder ，仅仅是可以为了标榜 "64 位" 和 "Cocoa" 而已。Cocoa 不是让 Finder 从本质上变得更好的魔法。那苹果为什么做这样的事情？因为 Cocoa 和 64 位，是 Mac OS X 的未来。对许多新的 API 来说，则已经是现在。正如锡拉库撒在他 Snow Leopard 评论的 64 位部分所指出的：
第二个关键点是新 API 和技术持续缺乏对 32 位的支持。这一趋势从 Leopard 开始，淘汰过时的 API 而仅仅移植新的到 64 位。在 Leopard 中引入的改进版 Objective-C 的 2.0 运行时也只支持 64 位。总之，Mac OS X 的部分新 API 和特性仅仅对 64 位程序提供支持，而 Carbon 没有 64 位 API，64 位应用程序就意味着是 Cocoa 程序。
Snow Leopard 沿袭了类似的路线。Objective-C 2.1 运行时的一些新特性也仍然只适用于 64 位应用程序。而最重要的新仅支持 64 位的 API 是 QuickTime X。
Carbon 还没有死掉。还没有针对现有 Carbon API 将在未来 Mac OS X 中不复存在的警告。一些最大型的热门第三方软件，如微软的 Office 和 Adobe 的 CS 套件，是用 Carbon 编写。即使这些应用程序的下一个主要版本都移植到了 Cocoa，还有很大一部分 Mac 用户希望继续使用他们付了钱的老版本。而且，即使你不相信苹果有支持第三方 Carbon 开发者的动机，请注意苹果自己的“专业软件”，比如 Final Cut Studio 所包含的，仍是 Carbon 应用程序。
也许 Carbon API 将永远消失，但我不会押注于此。他们当然不会很快消失，但“永不消失”是一个更长的时间。何况，苹果的所有新东西都是 64 位。
自从 64 位 Carbon 计划在 WWDC 2007 被披露之后，关于此的写作就没停过。Classic Mac OS 环境在此之后短短几年就被放弃了。Rosetta（PowerPC 的模拟器）不再与 Snow Leopard 默认安装，我猜测它也不会在 10.7 中出现。苹果电脑公司不只是添加东西到 Mac OS X 中——他们删除旧的东西。Carbon 还没有被移除，但显然苹果把它当作遗留技术，而苹果已经对任何遗留的东西表现出反感。
Snow Leopard 最值得一提的是它比前一代系统占有更小的硬盘空间。这个操作系统——还可以追溯到它在 NeXT 的根源，一直是在——进化，而不仅仅是增长。苹果公司不只是添加新东西进来。他们进行修剪。他们放弃旧东西。而以往的记录显示，当谈到把老技术踢到门外去，苹果宁愿选择“看起来太早放弃”而不是“让他们留到太晚“。苹果对于事情应该是怎么样的关心远远超过它对事情过去是怎么样的关心。
对于用户而言 Cocoa 有什么优势
64 位的 iTunes 并不会仅仅因为 64 位 Cocoa 的魔法就可以更快地完成 iPod 同步。但是，Snow Leopard 的新 Finder 的确展现了 Cocoa 重写给用户带来种种细微的好处。系统服务在 Carbon 和 Cocoa 程序中都可以通过服务菜单调用，但只有 Cocoa 程序支持最新的内容相关服务菜单。这是苹果给 Cocoa 添加的功能，所以所有 Cocoa 程序都可以“免费”得到它，包括新的 Finder。iTunes 9 则因为它是 Carbon 的，得不到。
另一个例子。本站（编者注：指格鲁伯本人的博客）的长期读者可能还记得“高可选择性”，在三年前我写的文章中比较过用键盘实现列表项目多选的两种模式：锚定式和非锚定式。我论证更欣赏锚定模式，并对 Cocoa，也就是大部分 Mac 程序采用的是非锚定模式感到遗憾。这在 Leopard 中变了，苹果改进了 Cocoa 的标准列表控件 (NSTableView) 以支持锚定模式。突然间，所有的 Cocoa 程序都从较差的模式切换到了较好的模式。但是像 iTunes 和 Finder 这样的 Carbon 程序还是没有改进。
Snow Leopard Finder 作为一个 Cocoa 程序，也有了锚定式选择。iTunes 9，还是 Carbon，就没有。这些小的功能细节和系统级 别的一致性构成了 Cocoa 的优点。
iTunes 和 Finder 之间一个大区别是 iTunes 是跨平台的。Finder 没有 Windows 版本。（即使是在 Mac 世界，iTunes 9 仍然可以运行在 10.4 和 10.5 上，而 10.6 Finder 只能运行在 10.6 上。）正如大多数 Mac/Windows 的跨平台应用程序一样，Mac 版本的基于 Carbon，而不是 Cocoa。这一问题的许多，如果不是大多数，原因是历史——大多数的大型跨平台的程序可以追溯到10年前，当时的 Mac 版不能写成 Cocoa 程序，因为 Mac OS X 还没出现。这对于微软的 Office，Adobe 的 CS 套件还有 Firefox 来说都属实，甚至 iTunes 也如此。
一个伟大的反例其实来自于 Adobe。Lightroom 是一个跨平台的应用程序，而其 Mac 版本不仅是 Cocoa，而且是主流软件中第一款我认识到是采用 64 位模式的（甚至比苹果本身还早）。如果 iTunes 不用 64 位 Cocoa 写，那我希望它参考 Lightroom 的架构：相对较小的 UI 层用原生 Mac 和 Windows API 书写，而其它大部分放在跨平台编译的库和脚本运行时中。但是，尽管 Lightroom 采用 Lua 作为跨平台的脚本运行时，我打赌苹果会把 WebKit 用在 iTunes上。
iTunes 中越来越多的 WebKit 应用可以看做是往这个方向踏出的一步。苹果不需要给 Mac 和 Windows 分别写新的 iTunes LP 或者新的 iTunes Store 的代码——他们用 WebKit，他已经可以在两个系统上都顺利地工作。
当然，苹果本身还有一个大的跨平台的应用程序，并且是 Snow Leopard 上的 64 位 Cocoa 程序。它叫 Safari。