undefined | Better HN

0 pointszxspectrum19824y ago0 comments

Have you ever developed a cross-platform application for desktop or embedded? It's quite a challenge, especially if there's GUI involved. Qt makes that a breeze.

As for mobile: if you can afford to develop completely independent apps for mobile, then do it. Many organizations cannot, and saying "we'll do the backend in C or C++, then call that code from a Java/.NET/Swift/HTML5 UI" looks fine on paper but then reality hits. Is the deliverable big? Yes it is, especially if you don't compile statically. But there's no good and cheap solution (and yes, Qt is cheap for the kind of savings it provides).

0 comments

5 comments · 2 top-level

joezydeco4y ago· 2 in thread

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)

michaelsbradley4y ago

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).

joezydeco4y ago

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.

secretsatan4y ago· 1 in thread

I don't think 'QT makes that a breeze' is true for anything but the most simple of UIs on mobile. It seems to work better for desktops I'll admit, but just seems grossly underprepared for anything smaller than a desktop screen that isn't embedded. (Although I personally really dislike QT interfaces on a mac)

Literally any other cross platform mobile solution is better, possibly the fact that QT tries to stretch itself across mobile and desktop is why it is so frustrating to work with on mobile. The apps tend to come out like desktop apps someone did their very best to shrink down

secretsatan4y ago

And while i think about it, the more it annoys me.

I think the only way we can get away with using it is because noone has any choice, if anyone launched an app using native in our field, any qt app is at an instant disadvantage. The qt team worries that an new ios release happened while i’m looking at the release notes and docs looking for things to use to our advantage

j / k navigate · click thread line to collapse