Discussion:
QtQuick for mobile - any experience to share?
(too old to reply)
Sylvain Pointeau
2018-05-25 13:12:18 UTC
Permalink
Dear all,

Do you have any experience that you can share on your mobile development
using QtQuick?

compared to native? compared to react-native? others?

How did you manage the different device sizes? and phone size / tablet
size? mobile + desktop?

I am really puzzled about which technology to choose.

Many thanks in advance for sharing.

Best regards,
Sylvain
ekke
2018-05-25 13:48:54 UTC
Permalink
Sylvain,
please take a look at my blog series
https://appbus.wordpress.com/category/qt-for-mobile/overview/
there are also some example apps at github

also some tips HowTo develop performant mobile apps with Qt:
https://blog.qt.io/blog/2016/09/22/qt-conference-apps-out-of-the-developer-trenches-part-1/


I have developed many mobile business apps running on Android and iOS
using QtQuickControls2
From customer feedback Apps feel like native apps

QQC2 support different densities
https://doc.qt.io/archives/qt-5.10/qtquickcontrols2-highdpi.html

take a look at QQC2 controls using Gallery App:
https://doc.qt.io/archives/qt-5.10/qtquickcontrols2-gallery-example.html

I'm really happy with QQC2 - it's really fast and easy to customize
all business logik and networking I'm doing w C++

ekke
Post by Sylvain Pointeau
Dear all,
Do you have any experience that you can share on your mobile
development using QtQuick?
compared to native? compared to react-native? others?
How did you manage the different device sizes? and phone size / tablet
size? mobile + desktop?
I am really puzzled about which technology to choose.
Many thanks in advance for sharing.
Best regards,
Sylvain
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
BlackBerry 10 | Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*Qt Champion
BlackBerry Elite Developer
*
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:***@ekkes-corner.org
my blog: http://ekkes-corner.org
app development blog: http://appbus.org

twitter: @ekkescorner
LinkedIn: http://linkedin.com/in/ekkehard/
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
Jérôme Godbout
2018-05-25 13:59:17 UTC
Permalink
I would not go HTML based application, they scale badly. personal, I would said you have either Qt (C++) and Xamarin (C#) as options. I haven't dig too much into Xamarin so far, look nice. Either way you still have to write some native part (BLE, background processing, kick start application etc).


As far as Qml goes, I have done both mobile and Desktop application (currently available iOS app and Android app for BLE mesh configuration, and Desktop Medical CAD application) with it and if you design well, you can totally reused the view and component for both. I love Qml so far, the only trap to avoid is to start doing everything into Qml, keep you model into C++ and manage them into C++, keep Qml for controller/view at most.


I would said, it depends on the lib you need to do, the more deeper and core to the system, I would said Qt could be more useful. Xamarin probably can shine to reduce code quantity with C# over C++.

A few area that are painful when it come to multiple embedded devices into Qt so far (I don't known if they are better into Xamarin at all by the way) is Bluetooth Low Energy and beacon, background processing, QtCreator is no VS (config cached pain, debugger is basic, may need to restart often when config changes a lots, just yesterday, I removed an Android-Build-Tools release candidate for testing into Android-Studio and I had to manually edit my gradle of my project, it doesn't stop seeing the uninstalled version, no matter what, so I forced it). But when it's setup and working properly it goes smoothly).

Hope this help.

________________________________
From: Interest <interest-bounces+godboutj=***@qt-project.org> on behalf of Sylvain Pointeau <***@gmail.com>
Sent: May 25, 2018 9:12 AM
To: Qt Project
Subject: [Interest] QtQuick for mobile - any experience to share?

Dear all,

Do you have any experience that you can share on your mobile development using QtQuick?

compared to native? compared to react-native? others?

How did you manage the different device sizes? and phone size / tablet size? mobile + desktop?

I am really puzzled about which technology to choose.

Many thanks in advance for sharing.

Best regards,
Sylvain
Jason H
2018-05-25 18:39:42 UTC
Permalink
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Sylvain Pointeau
2018-05-27 08:13:58 UTC
Permalink
Hello Ekke, Jason, JérÎme, and all

Thank you so much for sharing your experience and tips.

Did you use the v-play components? how did you succeed to match the native
look and feel?

My choice is between Qt and React Native.

I would have gone with Qt but the price is the real barrier for me. As I
don't know the success of the app, it is hard to start (and convince my
partners) knowing the price to pay per year.

Ekke you mention in your blog about the startup plan but as far as I know,
this is discontinued, the startup plan now let you use the "trial" version
until you go to the store.

React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML).

The benefit of RN is IMO to do json natively, but the negative aspect is
that it is not as cross plateform as Qt, so the desktop version is likely
to be (much) more challenging.

I am really puzzled, I think that Qt is better than RN, but the price ...

Am I missing something? is there someone else in the same situation?

ps: I continue to investigate (and to read the blog of Ekke), my choice is
not done yet.

Best regards,
Sylvain
ekke
2018-05-27 11:26:07 UTC
Permalink
Post by Sylvain Pointeau
Hello Ekke, Jason, JérÎme, and all
Thank you so much for sharing your experience and tips.
Did you use the v-play components?
v-play components are really great, but I'm not using them because
a) they are not open source - one of my reasons to use Qt is Open Source
b) each v-play release is bound to a specificx Qt version - so could be
problematic if you want to apply a patch
c) v-play license costs exta (Indie license for > 50k and < 100k annual
turnover)
Post by Sylvain Pointeau
how did you succeed to match the native look and feel?
QtQuickControls 2 with Material Style give you native look-n-feel on Android
you can customize UI Controls so they fit better iOS, but I'm using
Material Style together with BottomBar Navigation and for my customers
this is ok. Navigation of app is like iOS app. not 100%, but really fast.
Post by Sylvain Pointeau
My choice is between Qt and React Native.
This was also my question: should I use React Native or Qt ?
As I started, QtQuickControls2 just came out and from my POV Qt mobile
apps are easier to develop as RN.
Now there's also Flutter.io with Dart, but again: Qt Apps are easier
done x-platform.
yes - sometimes I miss a feature and some native code is needed for iOS
or Android. I never did native Android or iOS apps, but (with the help
of other Qt devs) managed to implement things like share-to and
share-from other apps. solutions are always published open source to
help other devs.
BTW: my next example app will be QML Camera Example for Android/iOS with
some real-life complex use-cases
Post by Sylvain Pointeau
I would have gone with Qt but the price is the real barrier for me. As
I don't know the success of the app, it is hard to start (and convince
my partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I
know, this is discontinued, the startup plan now let you use the
"trial" version until you go to the store.
take a look here
https://www1.qt.io/start-up-plan/
and apply, fill out the fomular and wait for feedback
if you match the requirements (less then 100.000 $ revenue p.a.) I'm
sure you'll get your startup license
Post by Sylvain Pointeau
React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML). 
The benefit of RN is IMO to do json natively, but the negative aspect
is that it is not as cross plateform as Qt, so the desktop version is
likely to be (much) more challenging.
yep - Qt is so powerfull x-platform. per ex. I'm debeloping for Android
and iOS but testing on macOS
Post by Sylvain Pointeau
I am really puzzled, I think that Qt is better than RN, but the price ...
Am I missing something? is there someone else in the same situation?
ps: I continue to investigate (and to read the blog of Ekke), my
choice is not done yet.
I really recommend to try out Qt with QtQuickControls2

ekke
Post by Sylvain Pointeau
 
Best regards,
Sylvain
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Sylvain Pointeau
2018-05-27 17:40:32 UTC
Permalink
Post by Sylvain Pointeau
My choice is between Qt and React Native.
This was also my question: should I use React Native or Qt ?
As I started, QtQuickControls2 just came out and from my POV Qt mobile
apps are easier to develop as RN.
Now there's also Flutter.io with Dart, but again: Qt Apps are easier done
x-platform.
yes - sometimes I miss a feature and some native code is needed for iOS or
Android. I never did native Android or iOS apps, but (with the help of
other Qt devs) managed to implement things like share-to and share-from
other apps. solutions are always published open source to help other devs.
BTW: my next example app will be QML Camera Example for Android/iOS with
some real-life complex use-cases
flutter seems promising, but their community is still (very) small whereas
RN is having a big community.
Main advantage of Flutter is that their compile natively. I wish QML was
designed to be compiled down to native.
Post by Sylvain Pointeau
I would have gone with Qt but the price is the real barrier for me. As I
don't know the success of the app, it is hard to start (and convince my
partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I know,
this is discontinued, the startup plan now let you use the "trial" version
until you go to the store.
take a look here
https://www1.qt.io/start-up-plan/
and apply, fill out the fomular and wait for feedback
if you match the requirements (less then 100.000 $ revenue p.a.) I'm sure
you'll get your startup license
The startup plan only offers to use the trial version for longer time, then
the price of 459$ applies. (or when you want to deploy on the store)
This price is correct for a company, but individuals, startups or very
small companies, this price is simply too much. I cannot spend this price
for sure.
Post by Sylvain Pointeau
ps: I continue to investigate (and to read the blog of Ekke), my choice is
not done yet.
I really recommend to try out Qt with QtQuickControls2
I believe that Qt is better, I have almost no doubt, but in my case, I
doubt I can choose it due to the price.
I am looking more and more in React Native, it seems manageable. It uses an
js engine (like Qt) and integrates native code quite easily (like Qt).
Sylvain Pointeau
2018-05-27 19:33:50 UTC
Permalink
Post by Sylvain Pointeau
I am looking more and more in React Native, it seems manageable. It uses
an js engine (like Qt) and integrates native code quite easily (like Qt).

actually this is not that straightforward in RN, and this is different on
Android (java) and iOS (Objective C). It is much easier with Qt. I continue
to be puzzled.
Marek.Floriańczyk
2018-05-27 11:55:10 UTC
Permalink
Hello Ekke, Jason, Jérôme, and all
Hi all

If I can add my two words.
I'm using Qt since 2012, V-Play about a year now.

From my point of view biggest advantage is that Qt runs on about everything. Most of my
projects include desktop, mobile, and server applications, where server runs on x86
processors as well as on ARM and it runs well, one of my project is CuteComfort all written in
Qt (mobile app for Android, iOS, both tablet and phone), desktop app for Windows,Mac and
Linux, server app running on Cubieboard microcomputer with ARM processor and the
system is managing 4 story hotel (heating, lightning, sensors) about 5 years now.

This advantage means that I just copy part of my code from server, to mobile (not graphics
of course), to desktop - all the same code.

V-Play is really nice, about a year ago I started to use it, so now I'm writing desktop and
mobile app with V-Play. Many useful features like plugins (PushNotification, Facebook, etc.) -
and again common code.

So lets say you need to create system that require server,desktop and mobile apps, if you go
native, this will require 4 different programming languages - 4 times the costs. If you go with
some JS framework, you wont be able to make server and desktop app, whereas with Qt ... ;)

About the costs, I'm not sure how it works now, I purchased license a few years ago and it
costs me about 99 USD per month (I'm micro-entity) for Qt and I have yearly subscription for
V-Play.
I don't want to brag, but some of my projects are described here
http://fmcode.pl/portfolio
although only in Polish language, maybe google will translate, anyway pictures included.

Best,
Marek
Thank you so much for sharing your experience and tips.
Did you use the v-play components? how did you succeed to match the native
look and feel?
My choice is between Qt and React Native.
I would have gone with Qt but the price is the real barrier for me. As I
don't know the success of the app, it is hard to start (and convince my
partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I know,
this is discontinued, the startup plan now let you use the "trial" version
until you go to the store.
React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML).
The benefit of RN is IMO to do json natively, but the negative aspect is
that it is not as cross plateform as Qt, so the desktop version is likely
to be (much) more challenging.
I am really puzzled, I think that Qt is better than RN, but the price ...
Am I missing something? is there someone else in the same situation?
ps: I continue to investigate (and to read the blog of Ekke), my choice is
not done yet.
Best regards,
Sylvain
Christoph Keller
2018-05-28 09:25:16 UTC
Permalink
You are correct, in my opinion the price for Qt is way too high if you
only need the mobile platforms. That's the reason we're thinking about
phasing out Qt in the next project. You'll likely reach the $100k
revenue with a 2-man project soon.

Don't forget there's also Google's Flutter in the game which is written
in dart and renders all by itself like Qt does.

React Native will give you all the joy of dependency management
(cocoapods, gradle) and 3rdparty libraries available for mobile which
will be hell to integrate with Qt (think of lottie animations and google
maps for example). Also they support the nice "hot reload" (flutter also
has this feature).

Regards,
Christoph
Post by Sylvain Pointeau
Hello Ekke, Jason, JérÎme, and all
Thank you so much for sharing your experience and tips.
Did you use the v-play components? how did you succeed to match the
native look and feel?
My choice is between Qt and React Native.
I would have gone with Qt but the price is the real barrier for me. As
I don't know the success of the app, it is hard to start (and convince
my partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I
know, this is discontinued, the startup plan now let you use the
"trial" version until you go to the store.
React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML).
The benefit of RN is IMO to do json natively, but the negative aspect
is that it is not as cross plateform as Qt, so the desktop version is
likely to be (much) more challenging.
I am really puzzled, I think that Qt is better than RN, but the price ...
Am I missing something? is there someone else in the same situation?
ps: I continue to investigate (and to read the blog of Ekke), my
choice is not done yet.
Best regards,
Sylvain
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
ekke
2018-05-28 13:57:25 UTC
Permalink
Post by Christoph Keller
You are correct, in my opinion the price for Qt is way too high if you
only need the mobile platforms.
that's right
there should be a 30$ or so per Dev per month license for mobile platforms
really don't understand why Qt isn't pushing mobile Apps with a cheap
Indie Developer License
Post by Christoph Keller
That's the reason we're thinking about phasing out Qt in the next project.
sorry to hear
Qt is so GREAT on mobile platforms w QQC2
Post by Christoph Keller
You'll likely reach the $100k revenue with a 2-man project soon.
yep - with 2 or more devs you'll reach the limits soon

I'm a single developer working from my home office and it works for me
with StartUp License
@Sylvain: if you fit into the 100.000$ maximum I recommend to fill out
the formular and wait for answer from sales. I'm pretty sure you'll get
the license. I'm using this license with 99 $ / month and know that
there are some otherd evs out there using this license
Post by Christoph Keller
Don't forget there's also Google's Flutter in the game which is
written in dart and renders all by itself like Qt does.
Flutter does a great work and is pushed by Google.
but: try to develop a x-platform project with Camera, BluetoothLE, ...
and compare with Qt ;-)
Post by Christoph Keller
React Native will give you all the joy of dependency management
(cocoapods, gradle) and 3rdparty libraries available for mobile which
will be hell to integrate with Qt (think of lottie animations and
google maps for example). Also they support the nice "hot reload"
(flutter also has this feature).
Regards,
Christoph
Post by Sylvain Pointeau
Hello Ekke, Jason, JérÎme, and all
Thank you so much for sharing your experience and tips.
Did you use the v-play components? how did you succeed to match the
native look and feel?
My choice is between Qt and React Native.
I would have gone with Qt but the price is the real barrier for me.
As I don't know the success of the app, it is hard to start (and
convince my partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I
know, this is discontinued, the startup plan now let you use the
"trial" version until you go to the store. 
React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML). 
The benefit of RN is IMO to do json natively, but the negative aspect
is that it is not as cross plateform as Qt, so the desktop version is
likely to be (much) more challenging.
I am really puzzled, I think that Qt is better than RN, but the price ...
Am I missing something? is there someone else in the same situation?
ps: I continue to investigate (and to read the blog of Ekke), my
choice is not done yet.
 
Best regards,
Sylvain
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
René Hansen
2018-05-28 14:19:31 UTC
Permalink
Or...

Just make your app LGPL compliant and use Qt anyway.


/René
Post by Christoph Keller
You are correct, in my opinion the price for Qt is way too high if you
only need the mobile platforms.
that's right
there should be a 30$ or so per Dev per month license for mobile platforms
really don't understand why Qt isn't pushing mobile Apps with a cheap
Indie Developer License
That's the reason we're thinking about phasing out Qt in the next project.
sorry to hear
Qt is so GREAT on mobile platforms w QQC2
You'll likely reach the $100k revenue with a 2-man project soon.
yep - with 2 or more devs you'll reach the limits soon
I'm a single developer working from my home office and it works for me
with StartUp License
@Sylvain: if you fit into the 100.000$ maximum I recommend to fill out the
formular and wait for answer from sales. I'm pretty sure you'll get the
license. I'm using this license with 99 $ / month and know that there are
some otherd evs out there using this license
Don't forget there's also Google's Flutter in the game which is written in
dart and renders all by itself like Qt does.
Flutter does a great work and is pushed by Google.
but: try to develop a x-platform project with Camera, BluetoothLE, ... and
compare with Qt ;-)
React Native will give you all the joy of dependency management
(cocoapods, gradle) and 3rdparty libraries available for mobile which will
be hell to integrate with Qt (think of lottie animations and google maps
for example). Also they support the nice "hot reload" (flutter also has
this feature).
Regards,
Christoph
Hello Ekke, Jason, JérÎme, and all
Thank you so much for sharing your experience and tips.
Did you use the v-play components? how did you succeed to match the native
look and feel?
My choice is between Qt and React Native.
I would have gone with Qt but the price is the real barrier for me. As I
don't know the success of the app, it is hard to start (and convince my
partners) knowing the price to pay per year.
Ekke you mention in your blog about the startup plan but as far as I know,
this is discontinued, the startup plan now let you use the "trial" version
until you go to the store.
React Native is fully in javascript, but seems typescript can be used
(which is much better) (BTW would be great to use typescript in QML).
The benefit of RN is IMO to do json natively, but the negative aspect is
that it is not as cross plateform as Qt, so the desktop version is likely
to be (much) more challenging.
I am really puzzled, I think that Qt is better than RN, but the price ...
Am I missing something? is there someone else in the same situation?
ps: I continue to investigate (and to read the blog of Ekke), my choice is
not done yet.
Best regards,
Sylvain
_______________________________________________
_______________________________________________
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Sylvain Pointeau
2018-05-28 14:32:13 UTC
Permalink
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t see
the business model in that case for my app.
Jean-Michaël Celerier
2018-05-28 17:37:18 UTC
Permalink
Post by Sylvain Pointeau
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.

in which case would using Qt under the LGPL affect your business model ?
You don't have to publish your sources, only under the GPL.




-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau <
Post by Sylvain Pointeau
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Sylvain Pointeau
2018-05-28 18:08:16 UTC
Permalink
My mistake, I understood the question was about to make my app GPL
compliant.
I would agree with you for the desktop version but I don't think that it is
feasible for a mobile app (is it not statically linked BTW?)
and I also understood the app store was not GPL friendly, but maybe my
knowledge is outdated.

Best regards,
Sylvain

Le lun. 28 mai 2018 à 19:37, Jean-Michaël Celerier <
Post by Jean-Michaël Celerier
Post by Sylvain Pointeau
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
in which case would using Qt under the LGPL affect your business model ?
You don't have to publish your sources, only under the GPL.
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau <
Post by Sylvain Pointeau
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
René Hansen
2018-05-28 22:39:16 UTC
Permalink
I can't speak for IOS, but at least on Android, all Qt libraries are packed
inside the application apk as .so files, so no static linking there.

It seems the "go-to" reply on the list and from Qt in general is, "just buy
the license". Somewhat shortsighted, but understandable as it is, Qt is a
business, out to make a profit. However, and as I'm surely not alone in
thinking, I really don't get this approach towards small-timers. The
license cost just isn't feasible for a lone couch coder with a pet project,
who just want to put a $1 proprietary app on the store. Most those kinds of
apps never make much sales anyway and Qt is quickly excluded from the list
of candidate frameworks, due to this perceived upfront cost.

The side effect of supporting indie devs and tinkerers are a lot more
profound though. That is where the ecosystem grows. Bigger ecosystem = more
growth opportunity for the "business" down the line.

It's a shame that many devs are left with the same impression as yourself,
and easily jump ship to React Native or similar. Qt could easily be the
defacto standard for mobile app development. It's just not the narrative
being supported by the Qt corp. Hence, you won't find any official guide or
writeup on how to publish a closed source LGPL paid app on the app store.

As far as I can tell though, there's really no reason why you can't publish
a paid app, which is still compliant.

You need to let people relink against other versions of Qt, but that simply
entails making object files available on request. If ever one is made...


/René
Post by Sylvain Pointeau
My mistake, I understood the question was about to make my app GPL
compliant.
I would agree with you for the desktop version but I don't think that it
is feasible for a mobile app (is it not statically linked BTW?)
and I also understood the app store was not GPL friendly, but maybe my
knowledge is outdated.
Best regards,
Sylvain
Le lun. 28 mai 2018 à 19:37, Jean-Michaël Celerier <
Post by Jean-Michaël Celerier
Post by Sylvain Pointeau
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
in which case would using Qt under the LGPL affect your business model ?
You don't have to publish your sources, only under the GPL.
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau <
Post by Sylvain Pointeau
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Sze Howe Koh
2018-05-29 00:54:50 UTC
Permalink
I can't speak for IOS, but at least on Android, all Qt libraries are packed inside the application apk as .so files, so no static linking there.
It seems the "go-to" reply on the list and from Qt in general is, "just buy the license". Somewhat shortsighted, but understandable as it is, Qt is a business, out to make a profit. However, and as I'm surely not alone in thinking, I really don't get this approach towards small-timers. The license cost just isn't feasible for a lone couch coder with a pet project, who just want to put a $1 proprietary app on the store. Most those kinds of apps never make much sales anyway and Qt is quickly excluded from the list of candidate frameworks, due to this perceived upfront cost.
The side effect of supporting indie devs and tinkerers are a lot more profound though. That is where the ecosystem grows. Bigger ecosystem = more growth opportunity for the "business" down the line.
It's a shame that many devs are left with the same impression as yourself, and easily jump ship to React Native or similar. Qt could easily be the defacto standard for mobile app development. It's just not the narrative being supported by the Qt corp. Hence, you won't find any official guide or writeup on how to publish a closed source LGPL paid app on the app store.
As far as I can tell though, there's really no reason why you can't publish a paid app, which is still compliant.
You need to let people relink against other versions of Qt, but that simply entails making object files available on request. If ever one is made...
/René
Dynamic libraries are allowed from iOS 8 onwards:
https://stackoverflow.com/questions/4733847/can-you-build-dynamic-libraries-for-ios-and-load-them-at-runtime


Regards,
Sze-Howe
My mistake, I understood the question was about to make my app GPL compliant.
I would agree with you for the desktop version but I don't think that it is feasible for a mobile app (is it not statically linked BTW?)
and I also understood the app store was not GPL friendly, but maybe my knowledge is outdated.
Best regards,
Sylvain
I thought about it but that does not work for all projects, and I don’t see the business model in that case for my app.
in which case would using Qt under the LGPL affect your business model ? You don't have to publish your sources, only under the GPL.
-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t see the business model in that case for my app.
ekke
2018-05-29 04:42:02 UTC
Permalink
for iOS I found this:
https://opensource.stackexchange.com/questions/6463/in-2018-if-i-use-c-qt-5-10-0-to-build-a-closed-source-application-requires-ope/6495#6495

but sounds complicated for me as a mobile business app developer

really sorry that there is no Indie mobile dev license from Qt

I asked and got answer that they have tried this some years ago with no
success
Some years ago I moved from BlackBerryOS7 (JavaME) to BlackBerry10
(Cascades/Qt 4.8)
This was first time I had to develop in C++ / Qt. BB10 Cascades was
great UX and performance.
So I also tried Qt itself, but performance of QQC1 was poor and I stopped.
Later BB10 died and I tried again to develop mobile apps with Qt. At
that time just first preview of QQC2 came out and I was impressed by UX
and performance.
So I started  to develop mobille Apps using QQC2 and in the meantime my
apps have native speed.

Also had some sessions at dev conferences where I talked about Qt for
Mobile.
Always same feedback from devs: looks great, but the costs ...

so now with QQC2 Qt is a great solution for mobile, but many devs cannot
use it because of license - very sorry about that

I'm using the startup license - but even the startup license info is
hidden at Qt's web sites. If you don't know about and search explicitely
for 'Qt start-up' you won't found https://www1.qt.io/start-up-plan/

Qt really has the potential to become a great player for mobile apps if
license model would be changed.


ekke
Post by René Hansen
I can't speak for IOS, but at least on Android, all Qt libraries are
packed inside the application apk as .so files, so no static linking
there.
It seems the "go-to" reply on the list and from Qt in general is,
"just buy the license". Somewhat shortsighted, but understandable as
it is, Qt is a business, out to make a profit. However, and as I'm
surely not alone in thinking, I really don't get this approach towards
small-timers. The license cost just isn't feasible for a lone couch
coder with a pet project, who just want to put a $1 proprietary app on
the store. Most those kinds of apps never make much sales anyway and
Qt is quickly excluded from the list of candidate frameworks, due to
this perceived upfront cost.
The side effect of supporting indie devs and tinkerers are a lot more
profound though. That is where the ecosystem grows. Bigger ecosystem =
more growth opportunity for the "business" down the line.
It's a shame that many devs are left with the same impression as
yourself, and easily jump ship to React Native or similar. Qt could
easily be the defacto standard for mobile app development. It's just
not the narrative being supported by the Qt corp. Hence, you won't
find any official guide or writeup on how to publish a closed source
LGPL paid app on the app store.
As far as I can tell though, there's really no reason why you can't
publish a paid app, which is still compliant.
You need to let people relink against other versions of Qt, but that
simply entails making object files available on request. If ever one
is made...
/René
On Mon, 28 May 2018 at 20:08 Sylvain Pointeau
My mistake, I understood the question was about to make my app GPL
compliant.
I would agree with you for the desktop version but I don't think
that it is feasible for a mobile app (is it not statically linked
BTW?)
and I also understood the app store was not GPL friendly, but
maybe my knowledge is outdated.
Best regards,
Sylvain
Le lun. 28 mai 2018 à 19:37, Jean-Michaël Celerier
Post by Sylvain Pointeau
I thought about it but that does not work for all projects,
and I don’t see the business model in that case for my app.
in which case would using Qt under the LGPL affect your
business model ? You don't have to publish your sources, only
under the GPL.
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau
On Mon, 28 May 2018 at 16:21, René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all
projects, and I don’t see the business model in that case
for my app.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Vlad Stelmahovsky
2018-05-29 05:22:09 UTC
Permalink
@ekke thanks for sharing! still not clear what
*With this in mind, we have leveled out the playing field for small teams
and growing businesses by providing an extended evaluation period of Qt for
up to 3 named developers.*
really means?
https://opensource.stackexchange.com/questions/
6463/in-2018-if-i-use-c-qt-5-10-0-to-build-a-closed-source-
application-requires-ope/6495#6495
but sounds complicated for me as a mobile business app developer
really sorry that there is no Indie mobile dev license from Qt
I asked and got answer that they have tried this some years ago with no
success
Some years ago I moved from BlackBerryOS7 (JavaME) to BlackBerry10
(Cascades/Qt 4.8)
This was first time I had to develop in C++ / Qt. BB10 Cascades was great
UX and performance.
So I also tried Qt itself, but performance of QQC1 was poor and I stopped.
Later BB10 died and I tried again to develop mobile apps with Qt. At that
time just first preview of QQC2 came out and I was impressed by UX and
performance.
So I started to develop mobille Apps using QQC2 and in the meantime my
apps have native speed.
Also had some sessions at dev conferences where I talked about Qt for
Mobile.
Always same feedback from devs: looks great, but the costs ...
so now with QQC2 Qt is a great solution for mobile, but many devs cannot
use it because of license - very sorry about that
I'm using the startup license - but even the startup license info is
hidden at Qt's web sites. If you don't know about and search explicitely
for 'Qt start-up' you won't found https://www1.qt.io/start-up-plan/
Qt really has the potential to become a great player for mobile apps if
license model would be changed.
ekke
I can't speak for IOS, but at least on Android, all Qt libraries are
packed inside the application apk as .so files, so no static linking there.
It seems the "go-to" reply on the list and from Qt in general is, "just
buy the license". Somewhat shortsighted, but understandable as it is, Qt is
a business, out to make a profit. However, and as I'm surely not alone in
thinking, I really don't get this approach towards small-timers. The
license cost just isn't feasible for a lone couch coder with a pet project,
who just want to put a $1 proprietary app on the store. Most those kinds of
apps never make much sales anyway and Qt is quickly excluded from the list
of candidate frameworks, due to this perceived upfront cost.
The side effect of supporting indie devs and tinkerers are a lot more
profound though. That is where the ecosystem grows. Bigger ecosystem = more
growth opportunity for the "business" down the line.
It's a shame that many devs are left with the same impression as yourself,
and easily jump ship to React Native or similar. Qt could easily be the
defacto standard for mobile app development. It's just not the narrative
being supported by the Qt corp. Hence, you won't find any official guide or
writeup on how to publish a closed source LGPL paid app on the app store.
As far as I can tell though, there's really no reason why you can't
publish a paid app, which is still compliant.
You need to let people relink against other versions of Qt, but that
simply entails making object files available on request. If ever one is
made...
/René
Post by Sylvain Pointeau
My mistake, I understood the question was about to make my app GPL
compliant.
I would agree with you for the desktop version but I don't think that it
is feasible for a mobile app (is it not statically linked BTW?)
and I also understood the app store was not GPL friendly, but maybe my
knowledge is outdated.
Best regards,
Sylvain
Le lun. 28 mai 2018 à 19:37, Jean-Michaël Celerier <
Post by René Hansen
Post by Sylvain Pointeau
I thought about it but that does not work for all projects, and I
don’t see the business model in that case for my app.
in which case would using Qt under the LGPL affect your business model ?
You don't have to publish your sources, only under the GPL.
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau <
Post by Sylvain Pointeau
Post by René Hansen
Or...
Just make your app LGPL compliant and use Qt anyway.
I thought about it but that does not work for all projects, and I don’t
see the business model in that case for my app.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
Jason H
2018-05-29 15:00:50 UTC
Permalink
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Sylvain Pointeau
2018-05-29 15:24:44 UTC
Permalink
A few things not mentioned, (or scanning to catch up on the thread, I did
not see)
1. RN will expose native libraries. This is terrible for a X-platform
developer as if you use Multimedia, have to know each multipedia API
expertly. The best thing is to use Qt and have it abstract the native
libraries. I once attempted to write the code to use different recording
qualities in iOS and got close, but the Trolls had it done right in a week.
Now repeat this for Android (luckily, this was already supported on
android). So whule RN is "cross platform" as soon as you do anything fancy,
you're into native API land. Qt does not have this problem.
I fully agree, however the react native community is really large, maybe
someone did it, maybe (often?) not perfect but better than nothing
2. The license is really worth it. I'd love to say that Qt is perfect. It
is not. Having your issues fixed in the next maintence release is a good
thing. But, not all your issues will land. I have paid for Qt support, and
I think I got comparable value out of it. Sometimes more, sometimes less.
But I do recommend it. One downside is that for Agile teams that release
often (weekly/bi-weekly), it takes longer to get an issue resolved than a
sprint. Some of this is just due to communication time (48 hour turn
around, 3 messages, has you in the next sprint.) But such is life.
Yes it is surely worth it, if you are sure about the revenue, in my case I
am quite reluctant to spend 459$/Month without knowing if I will get return
on investment, I will not hesitate if a client wants to pay to have a
certain app and I know that the Qt license can be paid with this client.
Sylvain Pointeau
2018-05-30 18:38:02 UTC
Permalink
I have still not made any decision yet, I am doing some testing to get a
better idea. Thanks a lot so far to all for your feedback.
Sylvain Pointeau
2018-06-02 08:37:53 UTC
Permalink
Post by Sylvain Pointeau
I have still not made any decision yet, I am doing some testing to get a
better idea. Thanks a lot so far to all for your feedback.
I investigated into React Native, as I know Qt quick by reading a lot about
it and trying time to time through the years.

RN has 3 parts: the js, the native and the bridge.

the native is specific for a plateform, objective c for ios and java for
android
the js is with javascriptcore but without the jit on ios
the bridge is basically a serialisation, I read that this is the most
costly.

the js and the native are asynchrone so every call between them must be
returned by a callback or with a future

so if I need something in my app that requires something special, long
calculation, threads, queued database writes, it will probably require the
native and I will have to write it for each platform.

I have some pain to see how fast is the js, I also heard that Android is
much slower than ios. Did you observe that with Qt?

In Qt, do you know how costly is the bridge? how fast is V4 vs
javascriptcore? I understood that the native objects are only communicating
with the js via the signal/slot right. How would you compare it with RN?
Jason H
2018-06-02 16:46:01 UTC
Permalink
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
ekke
2018-06-02 17:14:21 UTC
Permalink
I never noticed the differnce On AES encryption, the iOS devices were
faster, but in terms of Qt, I did not observe anything notable.
 
Post by Sylvain Pointeau
In Qt, do you know how costly is the bridge?
It's usually C++/ObjC or C++/JNI, so it's fast.
 
Post by Sylvain Pointeau
how fast is V4 vs javascriptcore?
It's not terrible. And it's getting better all the time. Note that the
"proper way" is to do it all in C++ and only use QML for glue code,
not to write a lot of app logic in it. (I don't think anyone follows
that though)
I'm always trying ;-)
while developing I'm doing many things in QML because it's easy done
but later the final code I always try to 'move' as much as possible from
QML to C++ to publish performant Apps
(this year I'm doing again the QtWorldSummit Conference App and will try
only to have some glue code in QML)
BTW: started Qt for mobile apps with BB10 Cascades and first I learned
from Cascades developers at BlackBerry to do as much as possible in C++
 
I understood that the native objects are only communicating with the
js via the signal/slot right. How would you compare it with RN? 
No, sometimes you do direct API. Like for wake locks, notifications,
etc. But 99% of the time, you just roll that into a C++ QObject and
expose that to QML, so it's highly re-usable and use signals and
slots. So it doesn't matter where you can use it, from QML or C++...
 
 
*Sent:* Saturday, June 02, 2018 at 4:37 AM
*Subject:* Re: [Interest] QtQuick for mobile - any experience to share?
On Wed, 30 May 2018 at 20:38, Sylvain Pointeau
I have still not made any decision yet, I am doing some testing to
get a better idea. Thanks a lot so far to all for your feedback.
 
I investigated into React Native, as I know Qt quick by reading a lot
about it and trying time to time through the years.
 
RN has 3 parts: the js, the native and the bridge. 
 
the native is specific for a plateform, objective c for ios and java
for android
the js is with javascriptcore but without the jit on ios
the bridge is basically a serialisation, I read that this is the most
costly.
 
the js and the native are asynchrone so every call between them must
be returned by a callback or with a future
 
so if I need something in my app that requires something special, long
calculation, threads, queued database writes, it will probably require
the native and I will have to write it for each platform.
 
I have some pain to see how fast is the js, I also heard that Android
is much slower than ios. Did you observe that with Qt?
 
In Qt, do you know how costly is the bridge? how fast is V4 vs
javascriptcore? I understood that the native objects are only
communicating with the js via the signal/slot right. How would you
compare it with RN? 
 
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Continue reading on narkive:
Loading...