[joezydeco]

Qt on iOS is expensive. Apple requires a static build^, and Qt static build requires a commercial license.

Qt saw this paradox and declared that iOS builds don't count as "embedded" builds, so you can deploy with a desktop license and not pay the exorbitant per-device vig. But it's still non-zero.

^(yes, you can do it dynamically, but you can't use GPL because users can't replace the dynlibs. So you're static whether you like it or not)

[michaelsbradley]

Generally speaking, Qt static builds do not require a commercial license if all of the Qt libs you're using are LGPL:

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

   If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

Now, for mobile apps "providing your [proprietary] application in an object format... so that a user has the opportunity to modify [Qt] and relink" might be challenging/impossible, e.g. given the nature of the iOS platform.

However, what I've found is that many devs believe that Qt static builds (for proprietary apps) are not allowed in general by the LGPL, and that's simply not true per the FSF's own FAQ. Qt's docs/marketing don't help in this regard (in my experience).

[joezydeco]

The example I was talking about was specifically regarding a Qt app built for iOS. An end customer cannot modify and/or relink the Qt libraries inside because Apple doesn't allow it through the App Store signing mechanisms.

I agree, Qt docs/marketing regarding licensing are a complete shit-show, and a solid reason why I don't recommend them anymore when I show up in a new organization. And I've been a Qt developer since the version 2 days. It's just too hard to negotiate and explain to management anymore, and the new lean towards a subscription model makes it even worse.