I have an application composed of a GUI and 3 launchd daemon launched command-line executables.
I’m planning to put the executables for the launchd daemons inside the .app bundle for the GUI.
These apps utilize 2 (both fairly small) frameworks which I have created.
Is it a better idea to put these frameworks in /Library/Frameworks (and thus save multiple applications loading the same code) or to keep them in the application bundle (thus making the application self-contained except for the launchd plists)?
Bottom line: I’d opt for self-contained unless/until you have convincing proof that putting the frameworks in
/Library/Frameworks/will offer a noticeable improvement for your particular scenario. Check the impact of doing it both ways, but I prefer to group the frameworks with the app to begin with.The dynamic linker (
dyld) is pretty smart about loading frameworks and reusing what has already been loaded in most cases. If there are several apps in disparate locations using a framework, it is definitely preferred to install it to/Library/Frameworks/. However, since it seems that all the “apps” you’re referring to are within your .app bundle, it wouldn’t seem there’s much benefit to this approach, since they’ll all be linked to the same path, whichdyldshould pick up on. (Not only is a user required to have admin permissions to modify/Library, but the install process instantly becomes more complex.) See the last part of my answer to a related SO question for ideas about analyzing launch performance of executables, including examiningdyldactivity.Another consideration is the degree of control you have over framework versioning when they are stored within your app bundle. If you purposefully “publish” a framework by putting it in a canonical public location, you must be prepared to accept the consequences of others possibly choosing to link against it. However, if a framework is only distributed inside your app bundle, any developer who chooses to link against it anyway has nobody to blame but themselves. 🙂