Sharing frameworks between multiple macOS applications

Question

Created Jan ’21

Replies 3

Boosts 0

Views 2.6k

Participants 2

We have multiple macOS applications (non sandboxed) that share a lot of core frameworks. So if the user installs two of our apps, there are essentially duplicate copies of the same frameworks inside the app bundles. This duplication can cost the user around 450 MB.

Is there an apple recommended way to avoid duplication in such scenarios?

One approach would be to install the common frameworks in a location like /Library/Application Support/MyCompany/Shared Frameworks/ and then add this to the rpath of all the applications, but I am not sure if this will work after signing and notarization.

Note - These apps are not distributed through the app store and are not sandboxed.

Boost

Answer 1

Etresoft OP

Jan ’21

Accepted Answer

It would be better to install them into /Library/Frameworks. That is a standard location and you wouldn't have to do anything to any rpaths. You can still sign and notarize. You would just have to sign the individual frameworks and the apps. Then notarize the installer pkg that installs them all.

It would be nice if you included an uninstaller too.

1

Answer 2

nangalvivek OP

Jan ’21

Can you share some documentation regarding this path? One concern with this approach is that other installers can overwrite some common library (eg libcurl.dylib, assuming we can also place dylibs here).

And we do include an uninstaller.

0

Answer 3

Etresoft OP

Jan ’21

Can you share some documentation regarding this path?

Here is Apple documentation.

One concern with this approach is that other installers can overwrite some common library

I suppose that is possible, but highly unlikely. There are really no such things as "common" frameworks.

(eg libcurl.dylib, assuming we can also place dylibs here).

That path is only for frameworks. If you have stand-alone dylibs, a more appropriate place would be /usr/local/lib. However, in /usr/local, you stand an excellent chance of some other installer overwriting a common library, or of the user deleting it.

libcurl, however, is part of the operating system. You don't need to install that. If you did want to install your own build of libcurl (which wouldn't necessarily be a bad idea), the best approach would be to create your own framework and statically link that to your custom build of libcurl.

0