tags:

views:

98

answers:

2

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.

A: 

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.

Nathan Lawrence
Thanks for your input. I have multiple binaries because I have a lot of code and different modules specialized in doing different tasks. I have one binary (that I call the launcher) that is in charge of starting all the useful binaries.I know I should change the architecture to have only one binary and libraries but at this point, this is too much work.After a crash, double clicking on the .app will always starts the wrong binary (even if the value of the .plist is still correct). If I use "Show package contents", it works but this is not an acceptable solution for my customers.
Boris
+2  A: 

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.

Brian Webster
Thanks Brian, I will try that. If anybody has more information about what's happening, feel free to reply.
Boris