我正在考虑放弃 32 位支持，转而支持自动引用计数（仅支持 64 位二进制文件）。
我想在 Mac App Store 中避免出现这两种情况：
For a 旧 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 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/ http://www.linethirteen.com/blog/2011/01/mac-app-store-32-bit-vs-64-bit/
我还发现 ARC 需要 64 位处理器。然而，我设法构建了一个胖二进制文件，其中 64 位版本使用 ARC，32 位版本使用垃圾收集器。为此，我必须执行以下操作：
- 设置使用 GC 的仅 32 位目标
- 设置使用 ARC 的仅 64 位目标
- 将 32 位目标添加为 64 位目标的依赖项
- 使用 shell 脚本添加自定义构建阶段，该阶段使用
lipo从两个目标中的二进制文件组装一个胖二进制文件
两个目标使用相同的源，但有一些#ifdef __OBJC_GC__声明是必要的。为了向后兼容，我确实不得不放弃合成的 ivars :(
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
