[Interest] Is Qt Library for OS X frameworks only?

[Till Oliver Knoll]

2012/10/18 Michael Jackson <imikejackson at gmail.com>:
> ... This is all done with symlinks and does work very well. If someone wants to point me to the specific Apple document that says NOT to do this I will happily change my code otherwise I'll keep going this route.

Most probably this:
https://developer.apple.com/appstore/guidelines.html - Mac App Store
rules, notably the way an application is supposed to be bundled and
self-contained etc...

Of course if you never plan to deploy there, that's no issue then ;)


However there is a valid use case for dynamic linking (I'll leave the
discussion "framework vs dynamic library" to away for sake of
simplicity, I really want to focus on "static vs dynamic linking"):
Sandboxing and Privilege Separation.

Assume you want to implement an "application which also accesses the
network": according to Apple it is good practise you split the
networking part from the rest of the application (which can access the
file system, for instance).

You do this by implementing (at least) two binaries inside the same
Bundle, with different Entitlements (the "networking binary" cannot
access the filesystem, the main binary cannot access the network
etc.). So you can at least share QtCore, and if the networking binary
should also render some GUI elements on its own (I'd consider this bad
practise, but for the sake of argument...) you could even share QtGui
- instead of linking both libraries statically into both binaries :)

Now when linking statically and after removing "dead" code in both
binaries, in theory you could /still/ end up with less code than in
the dynamic case - to be honest I don't know. But as soon as you start
to use a "reasonable amount" of the Qt API in both binaries, I dare to
say your application bundle becomes smaller in the dynamic linking
case :)

Cheers, Oliver