macOS: What's the correct place to install a dylib on a user's system?

Question

I've developing a software package that needs to install a dylib somewhere globally accessible by all user accounts. I'm not actually sure where the best place to put it is.

Ordinarily I would think /usr/local/lib is correct, but occasionally we encounter users who do strange things with that folder, including changing its permissions so that only one user can access the files in it, thus breaking my software for other user accounts on that system. Technically this sort of thing isn't disallowed on macOS -- /usr/local is intended to be a place that the user can utilize however they like.

An alternative solution could be in either /Library/Frameworks or /Library/Application Support/<my app name>. Those folders would certainly be safer as users are not supposed to use them however they want, nor modify their permissions. However neither place strikes me as correct for a dynamic library. /Library/Frameworks comes the closest and I think I've encountered other apps that put dylibs in there, but it's obviously intended for frameworks.

So where's the correct place to put it?

Answer 1

The Mac is a bit of a strange beast when it comes to file system locations, and it's going to get more difficult after macOS 10.15 (Catalina) ships, due to the primary boot file system being read-only.

Depending on the purpose of accessing the library, there are some appropriate places to put it.

In your Application bundle

If you have an Application that is being installed globally in the /Applications folder (most Applications are on the Mac, but sometimes users put them in strange places), then you could use the Application's own folder for storage of the library and it would be available to any code that can read in that folder. There are a number of problems with this, though: the user can move the Application, permissions may be wrong, and you have to be careful in any code that uses the Apple Hardened Runtime because it requires special flags to load code signed by anyone other than the signatory on the Application loading the library. The advantage is that deleting the Application also deletes your library, so you don't need to write an uninstaller. This technique is used by software like VMWare Fusion (if you need to run command-line code or similar) and

/Library/Application Support or /Library/Frameworks

If you need the library to be persistent and guaranteed to be in one clearly-defined location, then having the User approve your installation into /Library/Application Support/<your application> or into /Library/Frameworks is likely your best bet.

/usr/local/lib

As you've already noticed, /usr/local/lib can be problematic, especially since the popular Homebrew package manager generally sets the /usr/local/lib to be owned by the user installing files with brew so that it can be modified without needing to sudo.

With that said, though, you can install in /usr/local/lib, with the proviso that you may need to escalate privileges in order to perform the installation. Once the installation is done, the directory is usually set to be readable by any other user on the system.

Recommendation

As a long-time Mac user, I prefer when Applications keep themselves contained (codewise) to their Application bundle, and thus would encourage using that mechanism. The downside of the user not installing in /Applications can be mitigated by having the Application itself check when it runs to make sure that it's in the right place, and if not, prompt the user to move it (or do the moving after asking for a privilege elevation). This also removes the need for an installer/uninstaller program.

If that's not acceptable for some reason, then the /Library/Frameworks or /Library/Application Support/<your application> would be your next best bet. They're much less likely to create a problem than /usr/local/lib.