I present evidence of the ability to port Qt Lighthouse to iOS (UIKit)
I finished the implementation of the test port of the Lighthouse plug-in, which works “on top of” UIKit (the source code is available in the qt-lighthouse repo on the guitarous ). While not as impressive as the port for Android (but maybe a little more impressive than the port for the new INTEGRITY form , at least for me). And this means that if you carefully follow all the instructions in the attached README file (which can be found in the qt-lighthousesrc / plugins / platforms / uikit / repository branch ), you can build (partially) Qt for iOS (for both the simulator and and for devices), and also run a couple of Qt Quick applications from standard examples. I draw your attention that this is not a real port on iOS and does not have any official support or official status. There is a huge possibility that many parts of the Qt API are not working, even those that have successfully assembled (not to mention those that failed to build). In general, the goal of this R & D project was to launch a couple of QML applications on an iPhone to check the potential of this venture in general. And of course, to show how cool QML technology is.
Building and Linking Qt
It was the most tedious part, which at first strongly disappointed. I ran into a huge number of problems, starting with compiler errors related to the fact that some instructions were not available, ending with the fact that the values of functions and variables suddenly changed or were reset in runtime. As a result, I found that the base mkspec (Qt build configuration file) for gcc for a Mac contained specific values for the desktop version of Mac OS. Naturally, this blew up the brain from iOS. After that I corrected the environment variables in mkspec to more or less correct. And due to the fact that iOS is essentially POSIX platforms, almost everything immediately worked.
Plugin for Qt Lighthouse Platform
I chose the easiest way, and did the same as in the plugin for Cocoa: I backlit QImage backstore on UIView (more precisely on CALayer). Obviously, this is not the most optimal solution (and noticeably with the naked eye, if you run the QML flickr demo), but the solution is fully consistent with the concept of "R & D project". Although all the same there were a couple of problems. For example, during the integration of an event queue handler (QEventLoop), the system killed the iOS application, if during the processing of the event control was not transferred to the main application loop in certain time frames. A good solution for drawing would be to use the OpenGL surface as the backstore in Qt. Then all the drawing would happen to this surface. And in UIKit, present this surface as a buffer for the CALayer of the corresponding UIView. Thus, the overall video buffer would be obtained, in which Qt would draw, and the UIKit iOS subsystem would be perceived as “its own” and rationalized it with all its hierarchy, not really understanding how there and what happened. ')
Result
Lighthouse is able to work on iOS (at least after small patches) and QML is a very cool technology :-). Well, it's worth noting that for the Lighthouse is a useful plugin, well, plus at least a very instructive experience.
Here is a couple of video demo:
Qt Mobility on iOS - accelerometer is used to emulate the depth of space:
QML interface:
QGraphicScene
I would very much like some commercial organization to take on the release of this port and present the world (even for money) the Lighthouse plugin, which allows writing commercial iOS solutions on Qt. This would once again confirm and reinforce the slogan: “code less, create more and deploy everywhere”.