IOS - which parts of Qt are supported on iOS devices (especially QWebView)?
-
I think you can find it on Labs blogpost about it
-
There is general work being done in Qt 4.8 to ensure that it is iOS-compatible when it is released. There are two plugins being developed for Qt on iOS, but only one of them is currently open source. The open source plugin (aka. proof-of-concept UIKit plugin) was developed at Nokia, is (currently) part of Qt 4.8 and was discussed in a QtLabs blog post (in February?). That plugin however is only able to run simple QML apps and does not support more advanced features like auto-rotation, multi-touch, OpenGL, retina displays & widgets.
The other plugin (aka. Qt iOS plugin) is currently closed source, supports full Qt GUI with widgets, multi-touch, multi-threaded OpenGL, shader effects, Qt3D, Qt Scenegraph & parts of Qt Mobility. This is the plugin that was used to make some YouTube demo videos (in Oct/Nov last year) & was shown on the iPad at QtCS.
The Qt iOS plugin is currently being used to produce a trial-run application for submission to the Apple App Store, and more information etc. about that plugin will be made available once it has passed the App Store trial-run and can be considered for commercial application development.
PS. The qt-iphone project is unrelated to these efforts and will most likely never be able to be used to run QML on iOS (if it is in fact still being developed). The purpose of that project is to be able to use Qt to write native UIKit applications. The purpose of Lighthouse (and the iOS plugins for it) is to be able to build and run standard Qt applications on iOS.
-
Unfortunately, this Apple App Store rule gets in the way of using QtWebKit on iOS:
"2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
Making a custom version of QtWebkit that uses Apple's underlying WebKit framework was considered, but according to QtWebKit developers, this is not going to be technically feasible.
At this point, it is looking like a custom QML item would need to be made that used iOS WebKit to render to a surface, which could then be used in QML...
-
@SumWon : Do you have any idee when you will able to have more information about your ios plugins : I suspect that a lot of people will be very interested : Do you plan to release a commercial version or an lgpl version ? will nokia allow to use the lgpl Qt licence to build Qt ios apps without buying a commercial version ?
I have a lot of interest in porting my apps to ios, and don't know if I only have to wait for Qt ios :), or forget this and start objective C :(I we have Qt for Meego, Android (Necessitas), and IOS, it can be a very good new start for Qt ... forgetting 11 februar
-
There is no official investment on iOS & Android porting.
-
@ qtnext: I'm currently working on an app to put through the App Store approval process (even though I'll have to yank it as soon as it gets approved due to Qt 4.8 still being under a Technology Preview license) - because really, the biggest and most important unknown with this project is whether it is possible to get App Store approval for a Qt/QML based app. The aim is to get all of this (and the work on the plugin - including Mobility) done by the time Qt 4.8 is officially released.
In terms of licensing, no decisions have been made as yet. I have significant development costs to recoup, and so will need to get some commercial licensees (or some other form of remuneration) before I would be prepared to make the work publicly available under an LGPL or similar license. I have been contributing iOS-specific changes to both Qt (4.8) and the UIKit (proof-of-concept) plugin, and that work is under the standard Qt license (and part of the current 4.8 master).
I have been developing the Qt iOS plugin with a commercial Qt license, and so obviously for myself and other Qt licensees there is no issue with the static linking of Qt. Whether or not it is possible to adhere to LGPL when using statically linked code is a legal grey area. Nokia has assured me that they would like Qt to be "Everywhere" and would not wish to test this aspect of LGPL in court - as long as the other terms of the license were adhered to and source code or linkable object code (for your application) was provided.
-
Now, I made a little StarWars game for iOS (with the open-source UIKit plugin) with images, animations and dynamically loaded (java)scripts.
See:
http://privet.bplaced.com/v/qt_ios_starwars.swf
(the movie is 8 MB large)
(a pure QML game)
So, the basics are working!!! -
Have managed to embed Apple's iOS WebKit into a QWidget, so there is a way forward for web content on Qt/iOS... :) Going to try to match the QWebView API as much as possible (for QUIWebView), but unfortunately it can't be a 100% drop-in replacement (due to there not being an equivalent of QWebPage and QWebFrame on iOS)...
-
@SumWon That's great news. Thanks for sharing this. Any news on the app store approval test?
-
@thomasbonte: Got a bit side-tracked, as I am working with a customer to get their Qt (widget) app onto iOS. I'm going to have to get back on the case soon though... Will post here when there's any news on that... :)
-
-
Three ports? Hm, you mean one in 4.8, old iOS port without Lighthouse (which evan don't have good QtGui support) and closed-source one? For me it looks like we have only one port - which is mentioned in Labs blog post.
-
Hi,
I built now two small Apps for iOS to test the Qt/QML features of the UIKit implementation (Qt4.8)
See:
http://privet.bplaced.net/qsw_ios.png
http://privet.bplaced.net/v/qt_ios_starwars.swf (>8MB!)
http://privet.bplaced.net/qview_ipad.pngMy first remarks:
-
I had problems with QML plugins (=/imports/*):
They aren't working, because Apple doesn't allow
dynamically loaded libs.
I was not able to compile and link these statically
So I'm only able to use the stock QML elements. -
the speed: it's slow if I have more elements and animations
(like the little star wars game with 25 stars each with own animation).
The app swallows sometimes animations.
(see the BOOM-animation after a hit on the video (this works on desktop systems))
The reaction to a touch takes sometimes over 1-2 second! -
orientation is not handled automatically and there is no helper classes for this,
so I have to handle it manually with a lot of Cocoa+Qt-code.
The calculation of the window-size in Landscape mode is buggy. -
size: min. 25 MB This is big!
A normal standard iOS app created with XCode is smaller than 1 MB -
the UIKit-webview implementation seems to be difficult, so I'm using in
this demo the Text element (Text can display richtext/html/pics)
Conclusion:
The UIKIt plugin is impressive as first proof of concept solution,
but still not enough for commercial Apps... -
-
- You have to link the plugins statically. As there is no macro for this (like there is for other Qt plugins), so you'll have to register the plugin's types yourself.
- I haven't run into speed issues, however I'm using optimised settings and a different plugin (on A4 hardware). In any case a mobile device has a much slower CPU and memory subsystem than a desktop PC, comparisons should only really be made with other mobile devices.
- Auto-rotation is not done correctly (yet) in the "proof of concept" plugin.
- The Qt libraries are not built-in on iOS. Of course a Qt app is going to be much bigger, it has to bring the whole library with it.
Conclusion:
http://en.wikipedia.org/wiki/Proof_of_concept ;)