Eike Ziller

New proof-of-concept UIKit based Lighthouse platform

Published Friday March 11th, 2011
30 Comments on New proof-of-concept UIKit based Lighthouse platform
Posted in Lighthouse, Qt

Also not quite as exciting as the Android port (but maybe a tiny bit more exciting than the new INTEGRITY platform, at least for me 😉 ), I just pushed a new proof-of-concept implementation of a UIKit based Lighthouse plugin to the qt-lighthouse repository.

This means that, if you carefully follow the instructions in the accompanying README file (in src/plugins/platforms/uikit/ of the qt-lighthouse repo), you should be able to build (parts of) Qt for iOS Simulator and Device targets, and run a few simple example Qt Quick applications. I can’t emphasize enough that this is not a real port to iOS though, and is not supported in any way. Chances are that many parts of Qt don’t work, even the parts that do compile, not to speak of the parts that I didn’t even try to compile.

That said, the goal of the little project was to get some simple QML applications running on a iPhone to check if Lighthouse is technically up to the task, and because QML is so cool technology.

Compiling and linking Qt (so it actually runs)

That was the most tedious part which required a high frustration threshold. I faced issues from link errors complaining that some processor instructions were not available, to method return values and variables suddenly being changed or zeroed while the code ran, until I figured out that the base gcc mac mkspecs set desktop related environments that confuse the iOS parts then. After getting that more or less right, since iOS is mostly a POSIX platform most things actually “just worked”.

Lighthouse platform plugin

I took the easy route and did what the example Cocoa platform plugin does, i.e. blip a QImage onto a UIView. Certainly not the most performant way (as can be easily seen when running the QML flickr demo), but suited the purpose of a fast proof-of-concept. There have been a few challenges though, for example while integrating the event loop – an iOS application is killed by the system if it doesn’t call UIApplicationMain fast enough.

The result

Lighthouse is up to it (at least now, after a few little patches), and QML is cool technology ;). And I must say that from the Lighthouse parts it was a quite nice and from the other parts at least an enlightening (haha) experience.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Lighthouse, Qt


Well done! says:

The clouds parted and the sun bursts through my window. Is today going to be a good day? Well let’s check email and see what’s happening. Wait, what’s this? No. Could it be? It _is_ going to be a good day, no wait, good year, indeed.

Can’t tell you how pleased to hear that this is even possible 🙂

Well done!

Micke Prag says:

No video demo of that QML flickr demo? 😛

Excellent Eike! This may turn out to be a good week for Qt 🙂

Eike Ziller Eike Ziller says:

@tim: that’s not the same plugin, though, and uses a different way of painting afaik. I don’t believe that the performance of the plugin that I pushed would be as good. (I haven’t had a chance to check on a iPhone4 though, but what I see on the 3GS doesn’t make me hopeful 😉 )

las says:

“Excellent Eike! This may turn out to be a good week for Qt :)”

sounds more like a year like the last year :. concept demos of new stuff running on all kinds of hardware but no real official stuff that’s ready to rock’n’roll. I mean, would it be possible to push this stuff built with this to appstore? doubtful(and same goes for android port – with appstore rules thrown out of window with both platforms it is not a surprise that qt ports over). this is a growing sentiment among guys who have seen qt demos and implementations for a decade on various random hardwares.

Daniel Molkentin says:

@las: At least for Android Market that’s not true. There are Qt-based apps available for Android, see http://twitter.com/snystrom/status/46147234882011137.

Shmerl says:

Any idea when the real iOS Qt/Android port could be done? Even rough, in a year, in a few?

j says:

do i need a commercial license to write a qt program for android, iphone or meego?

Konstantin Tokarev says:

j: As far as I can see from source files, everything is licensed under the same terms as the rest of Qt

Mark Wilcox says:

To me, the “obvious” way forward with this lies in Qt 4.8 and the QML scene graph. Basically QML on top of OpenGL ES should be easily cross-platform. Forget all the legacy widgets – don’t port them, they’re no good for mobile UI’s anyway. All the wonderful Qt utility libraries, QML and Qt Mobility ported across Android and iOS would be a very powerful combination.

You should pre-emptively think about adding an LGPL exception around code distribution and mobile app stores (if not already), so there’s no problem with things getting pulled in the future. Potentially any contributer could ask for all Qt apps to be taken down otherwise.

Brilliant. Always bet on Qt.

I would like to code a QML Wifi remote for a Qt PC app.

Do you think this early port would be up to the task ? Does QNetwork classes are working ?

aportale says:

@Benjamin Arnaud: The qml flickr demo (on eike’s screen shot) does networking to fetch the images (I believe via http). Could be that it already is a working solution for you 🙂

Mark Kromis says:

Great work. I have not gotten to play with lighthouse yet, but I have a port in progress doing it the hard way if anyone is interested. The branch is at http://qt.gitorious.org/+qt-iphone/qt/qt-iphone-clone/commits/4.7-iphone

Q胖 says:

oh, my god, it’s so good.
Now I’am working in iMac,so I hope can use Qt to develop ios application.

qtnext says:

will nokia allow static linking lgpl ?

IvanDM says:

Finger crossed it get’s a bit easier to set up 🙂
Something like “necessitas” for iOS would be SUPER!!!

Jobs says:

No matter if Nokia or Intel need or like Qt, we do what we love. I believe Qt will grow up some day, and we can prove Qt is better than any other crossplatform framework.

David says:

I’m speechless.
Write once run everywhere, indeed.

Mike says:

I know that Android doesn’t have any hard and fast rules (and hence we are already seeing qt apps in the android marketplace), but how will this play with iOS tight restrictions? Can any iOS experienced devs explain why this is/isn’t ever going to happen?

If Qt could run on Symbian/Android/iOS, it would be irresistable (at least, to me :))

Mike says:

oops, to elaborate, how will this play with iOS –APP STORE– tight restrictions?

If Qt apps could –BE SOLD– on Symbian/Android/iOS, it would be irresistable.

Konstantin Tokarev says:

qtnext: Who said Nokia disallows static linking?

gemfield says:

Splendid! seems Qt will fill up the world

IanFromAfrica says:

@Tim: that’s the plugin I’ve been working on. It uses OpenGL to do the rendering (and hence uses HW acceleration on iOS).

@las: This plugin wouldn’t pass the app store submission process (in it’s current form). I’ve been very careful to avoid anything that would fail the tests. I expect to submit a QML-based app for approval within the next month, so we will know soon enough…

@j: You would need a commercial license to make closed-source apps for iOS. The app store rules are such that you would need to link Qt statically (which can only be done with a commercial or GPL license).

Luke Tyler Downey says:


The iOS SDK excludes support at the compiler level both for creating dynamic libraries and for incorporating them into an app. Technically one could roll one’s own cross-compiler, but it doesn’t really matter because dynamic linking is in violation of the App Store license agreement and would lead to rejection. See the below linked documentation for more info.


(As a side note, I’m no Apple zealot but—in Apple’s defense—their decision to exclude dynamic linking across the board may have been done in part to protect themselves from GPL-related issues. I don’t think it’s inconceivable that someone would try to make a case against the App Store as a “derivative work.”)

That said, if all of the relevant parts of Qt are licensed under the LGPL then there’s no problem. Proprietary software may be statically linked against LGPL software, provided object files for the proprietary software are made freely available to link against future releases of the LGPL software. I can’t imagine that being an issue in most cases.

IanFromAfrica says:

@Luke: I think it’s going to be impossible to satisfy the spirit of LGPL/GPL through the Apple App Store. The intent being that the end-user could rebuild the application if a later version of the libraries became available. Merely rebuilding the application executable wouldn’t get the end-user anywhere as they wouldn’t be able to update the package anyway without breaking the signing. So they’d need to jailbreak their device to take advantage of this. Or rebuild the app and resubmit it to the app store (unless they were willing to rebuild it every 3 months – that’s how long a self-signed executable that used the developer program SDK can last).

Not really ideal, and definitely not usable, but AFAIK all you have to do (to satisfy the license) is offer the source/linkable object files. In reality I can’t imagine anyone asking for them (because they’d basically be useless).

Luke Tyler Downey says:

Hahah, after spending the last half hour reading various sections of the GPL and LGPL, I can safely say that I’m glad to be an engineer and not a lawyer!

While I agree that simply providing a set of ARM object files corresponding to the proprietary software would not satisfy the deeper intent of the FSF, the issue of whether this would satisfy a strict legal interpretation of the LGPL seems less well defined (in my non-expert legal opinion). Below are some relevant extracts from the LGPL and GPL. In all of the goop that follows, the single most important sentence, I believe, is the last one.

Do one of the following:

Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.


Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version.


“Installation Information” for a User Product [e.g. iPhone] means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

IanFromAfrica says:

@Luke: I’m with you on not having to wade through this kind of stuff for a living! In theory, to satisfy the last paragraph you quoted, I could say:

1) Buy a Mac
2) Register to be an iOS developer
3) Install XCode & the iOS SDK
4) Provision your device for iOS development
5) Rebuild the app from the object files
6) Install it on your device
7) Repeat 4-6 every 3 months
8) Repeat 2 every 12 months

Which satisfies the letter (but not the spirit) of the license. 😉

I have an “All OS” commercial Qt license, so these kind of things aren’t really going to affect me. In the end, it’s Nokia’s call as to whether they want to take anyone to court over (potential) license violations.

It would make for an interesting court-case though, which would not only test the legal definitions of LGPL, but also whether or not it was actually legal to distribute *any* LGPL/GPL apps via the Apple App Store… 🙂

Mike says:

@Luke & @Ian
Thanks for that very detailed discussion! Honestly, I’m still a bit confused, but less so 🙂 So basically, if you have a commercial Qt license, there’s nothing at a technical or licensing level to stop you from publishing onto the app store as long as you statically link all the required Qt libraries? (ie, obviously no smart installer)

IanFromAfrica says:

@Mike: More or less. The first hurdle is getting any Qt-based app approved on the app store. I hope to do this in the near future (I’ve been very careful to avoid anything that would prevent this in my plugin, as well as having made minor patches to Qt where necessary). Then we’d have to wait for Qt 4.8 to be officially released (Lighthouse is officially part of Qt 4.8), as Lighthouse currently falls under a “technology preview” license which forbids distribution. Finally it would have to be determined which OS license is required for iOS (Mac OSX or embedded Linux – iOS uses a lot of the OSX code paths in Qt, and QPA/Lighthouse is the successor to the embedded Linux QWS). If you have an “All OS” license, this is of course moot.

Commenting closed.

Get started today with Qt Download now