Thank you for adding this. I got the following issue however: PATH was not correctly set when starting the application from the OS X search (top right corner of screen). The result was that binaries from /usr/local/bin was not accessible. Although this works if one runs the following in a terminal: open -a juCi++.

One additional issue is that one cannot run juci from terminal anymore, one would have to run open -a juCi++ instead.

OK, I don't have a solution for the PATH environment variable not including "/usr/local/bin". But I think that this stuff should be solved in the app itself. (You can already set the preference value 'cmake_command' to /usr/local/bin/cmake).

And to run it from terminal, you have to use juCi++.app/Contents/MacOS/juCi++ as launch path.

I guess we could add /usr/local/bin to PATH when starting juci on OS X.

Maybe add a symbolic link, when doing make install, from /usr/local/bin/juci to /usr/local/bin/juCi++.app/Contents/MacOS/juCi++ so it's similar to other platforms as well?

I didn't thought about installation yet. To install an application package to /usr/local/bin is not OSX like.
It depends on how this app should be distributed to end users.

At least to me, and many developers on OS X, homebrew is essential. I'm thinking that juCi++ could be installable with brew install jucipp someday. However, your changes makes juCi++ runnable through OS X non-terminal functions, which is nice.

Instead of creating download-and-click installables to every platform, we are hoping that package maintainers will continue to create juCi++ packages for the various platforms (through their package systems), like what is done for arch and msys2 through git-packages (and hopefully soon release packages). Until then, I guess manual git/build/make/install is fine.

OK, then for now to add a symlink as you suggested would be a first start then. I will try to add this to the cmake file and update this pull request then.

Sorry for being late on this. Still considering what to do here. An OS X package is nice, but it brings extra complexity which may lead to issues in the future. And then there is the PATH problem when starting juci outside of a terminal. We have to keep things simple in order to support so many platforms (12 platforms last time I checked!).

It's up to you. If you think that the maintainability cost are too high, then close this pull request.
For me the PATH problem is no real issue as I think a good c++ IDE should make it easy to set custom paths for its tools.

I think CPACK is the way to go on OS X as well: https://cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29.

Then the need of the symbolic link goes away, since a normal make install will work as it does now. But if you do make package an OS X bundle will be created.

See https://cmake.org/Wiki/CMake/CPackExample for an simple example (although DEB).

I've added CPack now, and once I figure out how to setup the OS X bundle using CPack I'll merge this most likely (the Info.plist is still needed if I'm not mistaken).

edit: We also have to fix the PATH issue.

OK, sorry I have no time to help here.