为什么当我单击 .app 时，Mac OS 有时会启动错误的二进制文件
我创建了这个包含多个二进制文件（假设 X、Y 和 Z）的应用程序。我有一个 .plist 文件，指定应用程序在打开时应启动 X。 99.9% 的情况下一切正常，但有时，它会启动另一个二进制文件（Y 或 Z）。
这通常发生在我的应用程序崩溃之后，所以我猜测这是一种 Mac OS 机制，它检测到二进制文件出现问题并尝试不同的二进制文件。
这对我来说非常糟糕，因为我的应用程序变得无法使用，直到我卸载并重新安装它。
I created this application that contains several binary files (let's say X, Y and Z). I have a .plist file that specifies that the application should launch X when opened. Everything works fine 99.9% of the time but sometimes, it launches another binary (Y or Z).
This usually happens after something crashed in my application so I am guessing that this is a Mac OS mechanism that detects that something went wrong with a binary and try a different one.
This is very bad for me as my application becomes unusable until I uninstall and re-install it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果这些附加二进制文件只是为了在应用程序中执行某些任务而启动，则没有理由需要将它们存储在与应用程序包的主二进制文件相同的文件夹中。如果您尚未将它们存储在应用程序包内的 Resources 文件夹中，那么您可以尝试将它们放置在那里，而不是放置在主二进制文件所在的 MacOS 文件夹中。我认为这足以将它们隐藏起来，使其免受启动不同二进制文件而不是主要二进制文件的任何机制的影响。
If these additional binaries are just launched for performing certain tasks within your application, there's no reason they need to be stored in the same folder as the main binary for your app bundle. If you're not already storing them in the Resources folder inside the app bundle, then you might try putting them there instead of in the MacOS folder where the main binary is. I would think that would sufficiently hide them from whatever mechanism is launching a different binary instead of the main one.
我在 Cocoa 方面只做了一点点工作，所以请原谅我缺乏知识，但这是我的 2 美分：
你有一个有趣的问题。显然，您有多种架构或需要同一应用程序的多个版本的东西在这里工作。这是自找麻烦。如果处理器架构是主要考虑因素，则只需使用通用二进制文件。如果您关心的问题与应用程序条件问题更相关，为什么不在单个二进制文件中执行此类逻辑呢？如果该技术被证明不可靠，那就不要使用它。您的客户会感谢您。 PS：Mac OS X 确实有一些自动执行的奇怪的故障排除功能，尤其是属性列表。避免让操作系统为您重新启动应用程序，然后看看这是否有效。总是有最后一个选项：右键（ctl）单击应用程序并说“显示包内容”。然后双击右侧的二进制文件。这样就没有犯错的余地。
祝你好运。
I have done only a little in Cocoa, so pardon my lack of knowledge, but here's my 2 cents:
You have an interesting problem. Clearly, you have multiple architectures or something at work here that requires multiple versions of the same Application. This is asking for trouble. If processor architecture is the primary concern, just use a universal binary. If your concern is more related to problems of Application condition, why not perform such logic inside a single binary? If the technology proves unreliable, just don't use it. Your customers will thank you. PS: Mac OS X does have some weird troubleshooting stuff it automatically does, especially with Property lists. Avoid letting the OS relaunch the App for you, then see if that works. There's always one last option: right(ctl) click on the App and say "Show package contents". Then double click on the right binary. There's no room for error that way.
Good Luck.