Mac App Store：放弃 32 位支持转而支持 ARC，32 位版本的现有用户会看到更新消息吗？答案

【问题标题】：Mac App Store: Giving up 32 bit support in favor for ARC, will existing users of 32 bit version see an update message?Mac App Store：放弃 32 位支持转而支持 ARC，32 位版本的现有用户会看到更新消息吗？
【发布时间】：2011-10-23 09:49:53
【问题描述】：

我正在考虑放弃对自动引用计数的 32 位支持（仅支持 64 位二进制文件）。

我想在 Mac App Store 中避免这两种情况：

对于旧 32 位 Mac 用户：

谁购买了支持 32 位的先前版本：他们会在 Mac App Store 中看到该应用程序的更新消息吗？如果是这样，（现在仅限 64 位）更新将不适用于他/她。
之前没有购买过该应用程序的人：他们是否能够购买该应用程序，尽管它不会在他们的系统上运行？

仅限 ARC 64 位： http://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/_index.html#//apple_ref/doc/uid/TP40011226

编辑：我曾发现有人能够将仅 64 位应用程序下载到 32 位 MacBook 并显示错误消息 “您的购买无法完成”。在这种情况下，它是一个免费的应用程序。我想知道何时会为付费应用弹出此消息（在付款之前或之后）。

http://www.linethirteen.com/blog/2011/01/mac-app-store-32-bit-vs-64-bit/

【问题讨论】：

标签： cocoa automatic-ref-counting mac-app-store

【解决方案1】：

我还发现 ARC 需要 64 位处理器。但是，我设法构建了一个胖二进制文件，其中 64 位版本使用 ARC，32 位版本使用垃圾收集器。为此，我必须执行以下操作：

设置使用 GC 的仅 32 位目标
设置仅使用 ARC 的 64 位目标
将 32 位目标作为依赖项添加到 64 位目标
添加一个带有 shell 脚本的自定义构建阶段，该脚本使用 lipo 从两个目标中的二进制文件组装一个胖二进制文件

两个目标使用相同的源，但需要一些#ifdef __OBJC_GC__ 语句。为了向后兼容，我不得不放弃合成的 ivars :(

【讨论】：

【解决方案2】：

我不知道 App Store 会做什么（无论如何它可能会发生变化），但如果应用确实交付给 32 位客户，您可以通过以下方式解决该问题：

让您的应用仅支持 64 位。
制作第二个仅 32 位的应用程序，除了显示警报消息外什么都不做。
将第二个应用程序中的所有资源构建到第一个应用程序中（即将它们添加到两个目标）。
使第二个目标成为第一个目标的依赖项，并在第一个目标的 shell 脚本阶段使用 lipo 将 32 位二进制文件同化为 64 位二进制文件。

然后，您将拥有一个通用二进制文件（或“胖二进制文件”），它是您在 64 位机器上的真正应用程序，以及在 32 位机器上的“请升级您的 Mac”应用程序。

【讨论】：

这不是一个好主意。 App Store 将指示您的应用支持 32 位，因为它在通用二进制文件中确实包含 32 位图像。这样你肯定会迷惑用户。
@gcbrueckmann：这让我们回到 Mark 最初的问题：“使用 32 位硬件的人是否能够购买64 bit only 应用程序？”如果是这样，最好告诉他们为什么他们不能使用它，如果他必须自己这样做（并且不会因此而被拒绝），那么他应该这样做。如果 32 位用户一开始就无法购买，那么是的，只使用 64 位。
缺少仅 32 位的 Mac 我无法验证这一点，但我猜即使购买它是可能的，尝试在 32- 上启动仅 64 位的应用程序仅限位的 Mac 应该提示 Launch Services 显示一个警报，就像您尝试在 Snow Leopard 上启动一个仅限 Lion 的应用程序时显示的一样。
@gcbrueckmann 这就是问题的一部分：假设有人会看到他们已经购买了该应用程序的错误消息。我无法想象 App Store 不会处理这个问题，但很高兴知道这一点。
那我们就同意了。我只是在暗示，除了 App Store 和 OS X 已经为您做的事情之外，您无能为力（并且添加虚假的 32 位支持只会使事情变得不必要地复杂化）。