Deploying an OSX application

Well, here is another first: For all of my commercial career, I have worked on Microsoft Windows only applications. All my side projects over the years where either never intended for deploying them to someone else or they were iOS code where deployment is really easy. But getting my 3D modeler code to be deployable proofed to be quite an adventure.

So in principle, an OSX app is a folder containing various files called an app bundle. Since the modeler code uses various 3rd party libraries and is split into multiple components, all of those have to be put into the app bundle. But for some strange reason it’s awfully complicate:

1. At first I tried to link against static libraries instead of dylibs to prevent problems where the app cannot find one of its components. But for some reason, if you add a static library as a dependency in XCode and the dylib is lying right next to it, the OSX linker will use the dylib instead! The only way to prevent this is to manually link to the static library with full absolute path in the linker’s other flags.
2. If you have dylibs that need to be bundled with your app, you have to add a build step that copies them to the product. But that’s not enough! If you use the otool application to analyze your binary, it will show you where the app looks for its dependencies. In my case, it looked for the devil image library in its installation path which is /usr/local/lib, which of course is not available on a non-developer machine. You can change the search path by using the install_name_tool but after a few futile tries, I gave up and linked against freeimage instead.
3. In a similar vain, if you have a target in your XCode project that create a library, you have to set its Installation Director build setting (in my case to @loader_path/../Frameworks). Apparently each binary encodes at which exact path it is looking for its dependencies instead of looking in the application folder like Windows systems.
4. After solving all dependencies on my app, it still wouldn’t work. The reason is that otool only shows the direct dependencies. If any of your linked dependencies uses other libraries, you have to change the paths in that binary as well. So in my case, I had to do the same otool/install_name_tool process on my sub-projects as well!

Well, that’s the short version of it. All in all, it took my 3 evenings of spare time to get everything running! While this is far from being a complete explanation of the process, I hope it might help to provide others with the relevant “google terms” to get their project up and running as well…