IOS - which parts of Qt are supported on iOS devices (especially QWebView)?

there are already demos working Qt-QML on iOS (iPhone or iPad) (using lighthouse)
These videos show simple QML games.

I know, QtGui is not supported by the Qt-port for iOS.

Is there a description about what is working on iOS and what don't work?
It would be very interesting to know, if QWebView (within or without QML) is working?
Are some database-plugins or imageformats working?

Is there somewhere a list of supported parts of Qt on iOS?
Is there a description, which parts are planned to port to iOS?

Ciao

P.S.: the "qt-iphone"-project seems to be dead or not officially supported by Qt...

I don't remember any official announcements about iOS support. Yes, there were some experiments that were posted in Labs, but it is not an announcement, just a showcase of Lighthouse usage.
Btw, there were some threads about unofficial port to iOS at this forum, search for them

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.

@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

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

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

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.

The "open governance" model is meant to offload the maintenance of Qt ports to the community. The idea being that if the "community" is interested in an iOS (or whatever) port, then they should do it themselves. The logic is somewhat flawed, as why would anyone spend thousands on hardware and software licenses and countless man-hours on development so that Nokia can improve it's product portfolio for zero cost to itself? At the same time, why would Nokia spend any time or money on developing support for its competitors' products?

For these reasons, it's highly unlikely that the UIKit plugin will be much more than a "proof of concept", or that there would be a high quality "free" port of Qt to any unsupported platform... IMHO, for this model to work, Nokia has to sponsor (ie. pay for) "community" ports (to platforms "of interest") if they are not willing or able to port to those platforms themselves...

[quote author="SumWon" date="1317939895"]The "open governance" model is meant to offload the maintenance of Qt ports to the community. The idea being that if the "community" is interested in an iOS (or whatever) port, then they should do it themselves. The logic is somewhat flawed, as why would anyone spend thousands on hardware and software licenses and countless man-hours on development so that Nokia can improve it's product portfolio for zero cost to itself? At the same time, why would Nokia spend any time or money on developing support for its competitors' products?[/quote]

Have you ever considered that Nokia offers you Qt for free? That "thousands on hardware and software licenses and countless man-hours on development" spent by Nokia are provided youfor free?

[quote author="SumWon" date="1317939895"]For these reasons, it's highly unlikely that the UIKit plugin will be much more than a "proof of concept", or that there would be a high quality "free" port of Qt to any unsupported platform... IMHO, for this model to work, Nokia has to sponsor (ie. pay for) "community" ports (to platforms "of interest") if they are not willing or able to port to those platforms themselves...[/quote]

[quote author="Lukas Geyer" date="1317978505"]
Have you ever considered that Nokia offers you Qt for free? That "thousands on hardware and software licenses and countless man-hours on development" spent by Nokia are provided youfor free?[/quote]

I have had an "all OS" commercial license for some years. All those hours of development were funded by me and other commercial Qt licensees. In any case, Nokia does not pay money to develop Qt so that they can give it away for free. They develop Qt so that they can use it on their own platforms (ie. provide a high quality port of Qt to Symbian/Maemo). My point was that they may need to pay something (either by tasking their own developers to it, or sponsoring a 3rd party) if they want to have high quality ports of Qt to other platforms too.

You people are going crazy.... Ufffff.. I wonder whether you all are having an extra brain...

I don't know what this porting is all about, and I doubt whether it is as complex as Special Theory of relativity or as easy as Second law of thermo dynamics.. Please somebody make a tutorial, what these porting stuffs, wrapper classes are.. And how only Qt makes it viable for porting?.. Is it because of the assembly code the compiler generates for different OS's?.. Or What is it?.. You guys are coming telling that you are contributing to Qt (porting) like sipping a cup of tea!..

If somebody out there explains this procedure I hope more people will be able to contribute to Qt. I'm also willing to contribute to some open source projects ant let Qt be the first on the list (Actually I tried to contribute to Linux, considering myself good at programming and went on to download the Kernel package after an hour of squeezing-brain activity, I just banged my head on the wall for considering myself a programmer at first :-)).. So I request someone to start a wiki page or something to explain how anyone can contribute to Qt and what knowledge should they have. Whether it is about assembly or c.. Like things..

The Qt for iOS SDK has been released now. This includes a workalike QWebView which embeds Apple's WebKit. The 'FancyBrowser' sample at https://qt.gitorious.org/~ianfromafrica/qt/qt-ios-plaszma has been updated to demonstrate its usage (in fact, it's a 1 line change to include the QUIWebView header file in place of the QWebKit one).

[quote author="qtnext" date="1312878111"]it's strange to have at least 3 known different port of Qt ios ! perhaps it's time to merge it ?[/quote]

[quote author="Denis Kormalev" date="1312878318"]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.[/quote]

These ports have (more or less) merged now in the qt-ios-plaszma repository on gitorious. There wasn't a lot that could be salvaged from the qt-iphone project, however some of the GUI work they've done can possibly be used in a future CoreGraphics iOS platform plugin (both QPA plugins currently use OpenGL). The qt-ios-plaszma version of Qt 4.8 adds some APIs to QPA which are necessary for iOS. The version of the 'UIKit' plugin there also has had some extensions, and will probably be the basis for any ongoing opensource work (either by the original author, the qt-iphone project or someone else).

[quote author="vadimv" date="1337687081"]so is there a support for QWebView in UIKit ? how can I use it ?[/quote]

There is no support for QWebView in the 'UIKit' platform plugin. The QUIWebView workalike class (which embeds Apple's WebKit in a QWidget) is only available when using the 'iOS' platform plugin. It should be possible to build and use the Qt WebKit on iOS (with either platform plugin), however Apple will not allow such an app on the App Store (whereas it would allow an app using QUIWebView, as it uses Apple's WebKit).

Only Qt 4.8.x is supported on iOS. There is no support planned for Qt 5.x until such time as the technical issues which prevent V8 (and hence QML2) from being able to be used.

An evaluation version of the (commercial) 'iOS' plugin is supplied with the Qt4iOS SDK. Have a look at the 'fancybrowser' sample in the 'qt-ios-plaszma' repository on gitorious if you want to see the QUIWebView class in action.