Eike Ziller

Update on UIKit lighthouse platform

Published Tuesday August 9th, 2011
58 Comments on Update on UIKit lighthouse platform
Posted in Lighthouse, Qt

Hi, it’s been a while since you heard from me regarding the experimental, proof of concept, unsupported UIKit lighthouse platform. So, I thought I’d give you some overview on what happened in the meanwhile, and give you some instructions how to actually try this stuff for yourself. This is a bit of a long post :).

(Note that there also is a community effort going on to port pre-4.8 Qt versions to iOS on qt.gitorious.org, which is not to be confused with this one.)

Since Lighthouse grew up, also the UIKit platform plugin went into the stock Qt 4.8 mainline, so if you get the sources for Qt 4.8, you’ll be able to also try out Qt on iOS. More on how to get up and running below. But there also have been a few fridays since then, and luckily I had some time to improve things on the initial version.

Open GL ES 1/2, Performance!

The platform plugin now uses OpenGL ES for drawing, instead of painting to an image with the raster paint engine and blipping that to screen. This works out quite nicely, and gives usable performance.

Challenges: Qt’s Open GL ES 2 code path resets the used frame buffer in between to a default value, in the unmodified case to the system frame buffer (0) – which doesn’t exist on iOS (all rendering done in FBO’s). The workaround is to override this by setting QGLPaintDevice::m_thisFBO (a protected member) in a custom subclass class and using that instead.

Nicer Fonts

The initial implementation used pre-rendered fonts shipping with Qt. Now it uses the BasicUnixFontDatabase from Qt, that is also able to handle ttf fonts. It’s still using fonts shipped together with the application, not the actual fonts on the device though.

Challenges: None for me, since this was kindly contributed by IanFromAfrica, thanks a lot!!!

Text Input Support

The platform plugin now reacts on Qt’s RequestSoftwareInputPanel and CloseSoftwareInputPanel events, by showing/hiding the iOS software keyboard. You can even input text / send key events by typing on it! 😉

Challenges: Showing the panel and handling simple key events is easy. (Implement UIKeyInput protocol on the main UIView.) Unfortunately Qt/QML doesn’t seem to send sensible close events… . For the QDeclarativeView case the plugin checks the QML Item with activeFocus, and if this item looses activeFocus it closes the panel again. The application must make sure no input relevant parts are covered by the input panel. Also, there is no integration with the iOS clipboard, or magnifying glass.

Interface Orientation

If you specify initial and supported interface orientations in your application’s Info.plist (UIInterfaceOrientation and UISupportedInterfaceOrientations), like it is done for any iOS application, the platform plugin will handle these. Your application will receive resize events, like it is standard in Qt applications, and the contents will be drawn flipped as needed.

Challenges: It would be nice if Qt could be told to draw rotated directly, since, as it is, the only way to do it is to draw the framebuffer transformed to screen (instead of directly transforming in GL), which probably has some performance implications.

Sound via Phonon

You can play sound using the Phonon API now. Nothing else really to say ;).

Challenges: None to speak of. Phonon and AVAudioPlayer API fit quite nicely. (Except for these prefinishMark notifications, which are just not supported atm. Not that any of this work is “supported”, mind you :).)

Try it Now!

If you have access to a Mac OS X machine (you might want 10.6 or later) you can check Qt running on iOS right away. You don’t necessarily need an actual device or be part of the (paid) developer program. The development tools and the iOS simulator are available for free (though you need to register with Apple to get them). So here is what you need:

  • A Mac OS X computer
  • Xcode developer tools, free download (need to register with Apple though)
  • A recent Qt 4.8, preferably from gitorious (you can also download a tar-ball from https://qt.gitorious.org/qt/qt/commits/4.8 if you really want)

The second part can turn out to be tricky, because Apple does a good job on hiding away their free offering. If you happen to run Mac OS X Lion (10.7) you can just open the Mac AppStore that is installed in /Applications and download and install latest Xcode 4. If you are not running Lion, and are not registered with the paid iOS developer program, you can install Xcode 3 – if you find it. Here is a list of clicks: http://developer.apple.com, “iOS Dev Center”, “Downloads/Xcode 4”, “Looking for Xcode 3? Download Now”, Scroll down to the end to “Register as an Apple developer/Learn more”, “Get started”, then register, fill out all forms, accept all agreements, and finally download Xcode 3+iOS SDK. Only 4 GB, time to get some coffee 😉 .

(If I have forgotten anything, please tell me, I’ll then update the list.)

After you got the three things above you can go ahead and compile Qt. The README in src/plugins/platforms/uikit includes the necessary configure lines for the simulator and the device. You need to create shadow builds of Qt with the names qt-lighthouse-ios-simulator and qt-lighthouse-ios-device respectively (at least the examples require them to be there). E.g. if your Qt sources are located at /Users/me/Qt/qt-src you do a simulator build with

mkdir /Users/me/Qt/qt-lighthouse-ios-simulator
cd /Users/me/Qt/qt-lighthouse-ios-simulator
../qt-src/configure -qpa -xplatform qpa/macx-iphonesimulator-g++ -arch i386 -developer-build -release -opengl es2 -no-accessibility -no-qt3support -no-multimedia -no-phonon-backend -no-svg -no-webkit -no-scripttools -no-openssl -no-sql-mysql -no-sql-odbc -no-cups -no-iconv -no-dbus -static -nomake tools -nomake demos -nomake docs -nomake examples -nomake translations
cd src/plugins/platforms/uikit

(Isn’t that a beautiful configure line.)

If you get weird configure erros, check that you use the iOS SDK 4.3. If not, consider either upgrading your iOS SDK, or adapt the QMAKE_IOS_SDK variable in mkspecs/qpa/macx-iphonesimulator-g++/qmake.conf and mkspecs/qpa/macx-iphonedevice-g++/qmake.conf .

After that finished, you can open the example Xcode projects in qt-src/src/plugins/platforms/uikit/examples, make sure that the “<example> simulator” target and the “iPhone 4.3 Simulator” platform are selected in the top tool bar, and press the (Build &) Run button!

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

Posted in Lighthouse, Qt


qtnextA says:

Cool 🙂 🙂

Will this plugin be supported ?
Has anoyne succeeded to register an application to apple store (look and feel) ?
In short can we dream that in a near futur it will possible to deploy simple qml application to Ios, Android … and symbian for commercial apps and not for hobyist … or it’s better to switch to native/or other sdk ?

Eike Ziller Eike Ziller says:

I would not expect Nokia to support this (since you mention it, it doesn’t support Android either), someone else would need to pick up the “support” aspect in the light of open government or such. Similar regarding the AppStore – nobody has tried yet afaik, somebody would just need to. I don’t think the “look and feel” will be any problem as long as you don’t try to mimic standard UIKit components. I’ve even seen applications with their own implementation of a software keyboard in the app store :). A big unknown is what APIs we use in Qt that might trigger an “use of undocumented API” check on Apple’s side. But I’ll be happy to merge fixes to make this possible.

About dreaming – a dream often only comes true after hard work 😉

mgoetz says:

Great news!
Will Nokia allow Qt static linking especially for iOS without having a Qt commercial license from Digia?

qtnext says:

about dreaming … that why I have hardly work to invest time in learning Qt …. there was a lot of Nokia stuff last year about Qt in mobile area (Symbian, Meego), encouraging to invest time in Qt for mobile and everything has been broken the 11 Februar ! .. That why I hopes that there is new start with at least Android, and Ios for mobile !

But thanks for your great works 🙂

Chris says:

Thanks for your (and Ian’s) contributions to this port – iOS support (in addition to the awesome Android port) has the chance to boost Qt’s popularity even more!

My first question is similar to qtnextA’s regarding the publishing issues with Apple’s App store: is there a Qt-based app (either QML or QGraphicsView-based) already published, or will it be possible?

Secondly, will there be any mutli-touch support anytime soon?

Thirdly, a phonon-specific question for iOS: is it possible to play multiple audio files simultaneously, as games often need that feature (playing background music, together with short audio effects)?

qtnext says:

I suppose the most tricky part is QtMobility port (like in android port) … but if we have already a Qt port without Mobility … It’s fore sure a very big news !

Eike Ziller Eike Ziller says:

@chris: Reg phonon: yes, multiple simultaneous audio files work.

Eddy says:

@ Eike,
There are severall Qt based apps in the apps store already

here is an example af a Qt based app in the apps store :Simlab

It is in the Ambassador Showcase too :

qtnext says:

@Eddy : You are using uikit plugin in Qt4.8 for you iphone apps ? have you use Qt-components ?

jb says:

Could it make sense to use the phonon-VLC backend with libVLC on iOS to have full phonon capabilities?

Eike Ziller Eike Ziller says:

@jb: For some use cases that could make sense (e.g. for a media player). When you just want some application/game sounds (fire and forget style), where you even control the file format etc, I don’t see a reason to pull in another meg or two in external dependencies. If in need, you are free in your application to import and use a different phonon backend.

dialingo says:

Your links point to desktop Mac programs. Is there already one single Qt based program in appstore for iPhone?

Konstantin Tokarev says:

mgoetz: nobody forbids you from static linking. Read LGPL more carefully.

qtnext says:

But if we need to provide object files on demand … how can we protect commercial software (on desktop I use hardware dongle, so providing object will means distribute a version without protection) and for ios apps store : it means that anyone can take the object file and redistribute the software … Why Nokia not add a special licence exception allowing to static link using lgpl (like Ogre3D has done previously when it was lgpl ..http://www.ogre3d.org/tikiwiki/StaticLinking) ?

Eddy says:


There was a thread in devnet forum some time ago. But it has been deleted. 2 developers responded to it saying they alread have Qt based programs in the apps store. I could only remember this one. It has been there for a while already. I don’t know how they did it exactly. Just added this info because I thought it could be interesting to know.

mgoetz says:

@Konstantin Tokarev: Yup, it’s not forbidden. But th ways I know to do it are feel a bit messy. What would you recommend?

Rachel says:

Qt on iOS! Awesome!!

I can’t wait until I have the time to try this out. Thanks!

3DH says:

Great news! I’m happily surprised! So I can look forward to deploy own native apps to iOS devices in the not so far future!

Great work guys!

Okan says:

During the configure step, I’m getting:

The OpenGL ES 2.0 functionality test failed!
You might need to modify the include and library search paths by editing

OS: Snow Leopard. I have the latest XCode/iOS SDKs. I checked the mkspecs and I have the OpenGL framework at the specified location.

Any ideas?
PS: Thank you for the awesome work. Looking forward to hearing more good news on this.

SumWon says:

@Chris: There are some apps currently in the App Store which use Qt Core and Network. There aren’t any Gui or QML apps at present, but I expect to submit some in the near future. It makes more sense to use QtMultimedia for game type applications. I’ve ported the audio part of Multimedia to iOS and will release patches for that in the near future.

@qtnext: Parts of Mobility have been ported already. So far there is location (GPS) and sensors (accelerometer).

qtnext says:

@SumWon :
does it means that you will provide patch for the uikit in qt 4.8 (gps, accelerometer, multimedia, … and all others thing that you are refering in the thread http://developer.qt.nokia.com/forums/viewthread/7271/ ) or do you plan to release (or not) your plugin in other way ?

Super-duper news! I think this project should be great for enterprise apps – write ones, work everywhere (where are you Java?).

Not a lawyer says:


Nobody cannot clarify anything on static linking because the ultimate question is: If a closed-source app was sued for using statically-linked LGPL libraries, would a judge think it constitutes a derivative work or not? Until such a case is brought to the court, it’s impossible to know for sure.

The spirit of the LGPL is to make sure changes you make to the library itself are shared back, and that people can link your app with other versions of the library, so what I would do is:

1. Act in good faith: do mention all libraries you use in your software in the about box, do share any fix / patch that you make on them.

2. Advertise on your website the possibility to download the object files of your app so that anyone can download them and relink with another version of the library.

Jeremy Friesner says:

This sounds promising!

Say I have a GUI application that currently compiled and runs using Qt 4.8.0 (under Mac, Windows, and Linux). Would it be feasible to use this to compile and run the same application under iOS? How much tweaking would that require? Is it worth attempting, or will I end up needing to rewrite/redesign most of the app anyway?


Albert says:

@Okan: I had the same OpenGL ES 2.0 problem but it’s because I had the iOS 4.2 SDK not the 4.3 SDK installed, and the path to the SDK in the mkspecs was for 4.3.

I got Qt compiled OK now but when I try to compile the examples, it’s trying to link against libquikit from the ios-device target (and there doesn’t seem to be one in lib/ for the ios-simulator target)

I’m trying to build the ios-device target now, though I’m getting compile errors in some powerpc asm code (wut)…

David Huang says:

I’d be a lot more excited about this if Qt weren’t abandoning support for Xcode.

Eike Ziller Eike Ziller says:

@okan: @Albert: right, you need the matching iOS SDK to what is specified in the mkspec. And, gah, I failed to mention that you need to run make in src/plugins/platforms/uikit too! Adding the missing parts now.

Eike Ziller Eike Ziller says:

@jeremy: Please note that this platform implementation is mostly concerned about running QML-based GUI on the device, i.e. the state of widgets is a) unknown, and b) definitely not what you want to use. But actually you will most probably need and want to redesign a desktop application’s UI for mobile anyhow. If you are using QML for your application you might be able to share parts from the UI too, in addition to the backend. If you want to port a mobile QML application for symbian/meego/android you can probably share *most* parts (even though you still will need to tweak the UI for each platform, the screen sizes and form factors are just too different).

Konstantin Tokarev says:

@mgoetz: IANAL too, but you don’t have to offer public download of object files _for everyone_ (especially if your application is paid). You need to offer such downloads only for _users_ of your application (e.g. those who bought it). You are free to offer object files only when somebody requests them but you should inform users that they can do it

not_impressed says:

@David Huang: Is this “Qt weren’t abandoning support for Xcode” refering _again_ to the facts that (a) the Qt side did not change _anything_ and (b) XCode 4 is dysfunctional or even crashes (google for it, or search stackoverflow, or discussions.apple.com) on reading project files that previous considered valid?

SumWon says:

@Jeremy: This plugin isn’t really suitable for running widget apps. Neither is desktop UI design suitable for mobile devices. Of course it all depends on the app, as to whether it can be easily ported to a mobile device. In any case, most Qt apps can be built with minor (if any) modifications for iOS. Getting them to work properly is dependant on the plugin used and what is being done in the app.

@David: XCode is only needed to link the final executable and sign the application bundle. Everything else can be done with Qt Creator.

@qtnext: GPS, accelerometer are parts of Qt Mobility. In any case, Qt 4.8 needs an API change to allow Mobility (and apps) to talk directly to the platform plugin. These capabilities won’t be available in Qt until 5.0.

nsicad says:

@Eike Ziller,

< QML-based GUI on the device, i.e. the state of widgets is a) unknown, and b) definitely not what you want to use.

PhoneGap and QuickConnect using JavaScript for iOS, Android, etc. are doing UI and backend as well. Why Qt QML-based GUI could not do that using WebKit? Why not? I proper WebKit with QML with the backend (i.e. real sqlite3/spatialte, not html websql) is the way to go. If Nokia is really serious about Qt Quick (QML) as alternative to C++. QuickConnect has demonstrated using Javascipt in iOS and Android.

<If you want to port a mobile QML application for symbian/meego/android you can probably share *most* parts..

QML for symbian/meego/android has never shown us example how to do a "proper" mobile database backend in (i.e. real sqlite3/spatialite database).

In these examples, they are not a real sqlite backend but HTML Websql. You can not extend it to use spatialite, or connect to existing sqlite3 database. It is offline websql.

This is real sqlite backend integration implemented in Javascript in QuickConnect.

Hope to see Qt lab can demonstrate QML with real sqlite3 and spatialite databases, not HTML websql offline for storing GAME stores. Better syncs device database with remote database (oracle, postgresql, mysql). QuickConnect has done this as well.


Eike Ziller Eike Ziller says:

@nsicad: As far as I can see, the mentioned frameworks are pure HTML5+JavaScript (injecting some of the device API). Qt/QML is not supposed to replace Qt/C++. It is supposed to complement it. Take the best tool for the best task. QML is great for the fluid-UI part of an application, including some of the more trivial application logic like “if-clicked-here-then-go-into-this-state”. Qt/C++ is great for backend functionality, including QtSql for database access, and for time critical things like physics or other non-trivial game/application logic. Qt is a great framework for bringing the two together, with it’s metatype system on top of C++. viewer.rootContext()->setContextProperty("databaseStore", new MyDatabaseStore) is your friend, if QML’s Offline Storage API doesn’t suit you.

SumWon says:

Eike: “It would be nice if Qt could be told to draw rotated directly, since, as it is, the only way to do it is to draw the framebuffer transformed to screen (instead of directly transforming in GL), which probably has some performance implications.”

I’m not sure what you mean by this, it’s possible to get iOS to do all the transformation in hardware (Qt always sees the screen as “upright”, just the geometry changes). I haven’t gone as far as faking orientation reporting yet (where Qt reports the display as rotated, but doesn’t try to do transformation), but I don’t think this is very difficult. In any case, if you want to incorporate the iOS status bar the display rotation needs to be handled by iOS… 😉

nsicad says:

@Eike Zille,

PhoneGap and QuickConnect are not pure HTML5+JavaScript. You are wrong! They are XCode (Objective-C), Javascript and HTML. In the case of the QuickConnect sqlite3 is done in Objective and has binding for Javascript. The backend is Objective-C and front-end is Javascript render in DOM (Html).

You totally missed the point here, by telling me to use C++ for database backend and frontend, right? That is not what I am looking when I posted the links.

Hi Eike Ziller,

Impressive port.

I think 4.8 and Lighthouse are going to be a major milestone for Qt.

Code once, deploy everywhere !


shmerl says:

This is great! Having a functional Qt port for iOS and Android will make Qt a very attractive crossplatform toolkit for mobile development. Regarding the app store – that’s not so critical. There is always Cydia available without all Apple’s paranoid app store policies which don’t apply when you don’t use their appstore. What’s more critical, is if compiling Qt and Qt based applications is in accordance with the license of the SDK itself (because there is no way around that so far). That’s the legal question, which for example Mozilla team could not overcome (even if they wanted to use Cydia). Apple has really weird restrictions in the SDK license which prevent even compiling (!) some code legally. Hopefully Qt doesn’t conflict with any of those restrictions.

kambala says:

Hi Eike. Thank you for your work and post!

I’m trying to compile this plugin for device and I’m getting some strange errors:

compiling /Developer/qt-4.8-beta/qt/src/tools/uic/uic.cpp
linking ../../../bin/uic
cd src/corelib/ && make -f Makefile
make -f Makefile.Release
objective-c /Developer/qt-4.8-beta/qt/src/corelib/tools/qlocale_mac.mm
../../include/QtCore/../../../qt/src/corelib/arch/qatomic_i386.h: In function ‘void* qMetaTypeConstructHelper(const T*) [with T = QSystemLocale::CurrencyToStringArgument]’:
../../include/QtCore/../../../qt/src/corelib/arch/qatomic_i386.h:120: error: impossible constraint in ‘asm’
../../include/QtCore/../../../qt/src/corelib/arch/qatomic_i386.h:120: error: impossible constraint in ‘asm’
{standard input}:202:non-relocatable subtraction expression, “L__ZN7QString11shared_nullE$non_lazy_ptr” minus “L23”
{standard input}:202:symbol: “L__ZN7QString11shared_nullE$non_lazy_ptr” can’t be undefined in a subtraction expression
{standard input}:199:non-relocatable subtraction expression, “L___gxx_personality_sj0$non_lazy_ptr” minus “L30”
{standard input}:199:symbol: “L___gxx_personality_sj0$non_lazy_ptr” can’t be undefined in a subtraction expression
{standard input}:unknown:Undefined local symbol L__ZdlPv$stub
{standard input}:unknown:Undefined local symbol L__Znwm$stub
{standard input}:unknown:Undefined local symbol L__Unwind_SjLj_Register$stub
{standard input}:unknown:Undefined local symbol L__ZN8QVariantC1ERKS_$stub
{standard input}:unknown:Undefined local symbol L__Unwind_SjLj_Unregister$stub
{standard input}:unknown:Undefined local symbol L__Unwind_SjLj_Resume$stub
{standard input}:unknown:Undefined local symbol L___gxx_personality_sj0$non_lazy_ptr
{standard input}:unknown:Undefined local symbol L__ZN7QString11shared_nullE$non_lazy_ptr
make[2]: *** [.obj/release-static/qlocale_mac.o] Error 1
make[1]: *** [release] Error 2
make: *** [sub-corelib-make_default-ordered] Error 2

Do you have any clues on how to fix it? It compiled for simulator just fine. I’m using SL, ‘gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)’ and iOS 4.3 SDK (and have xcode 3.2.6 installed if it matters).

Eike Ziller Eike Ziller says:

@kambala: “../../include/QtCore/../../../qt/src/corelib/arch/qatomic_i386.h” is definitely not the right file to compile for the device. Should be qatomic_armv7.
Your Qt directory is name “4.8-beta”, are you actually trying to use the 4.8 beta? I have no idea if that would work, you should take Qt straight from the 4.8 branch, there have been some (maybe critical) changes been done in between.

SumWon says:

@shmerl: This is the big unknown. I’ve been working on my own iOS plugin for some time now, and am getting very close to the point of finding out whether Apple will approve an app based on it or not (from what I know, an app using the plugin described in this post would probably not be approved). From everything I’ve read, and my conversations with Nokia (Legal) I don’t see any problems with the work I’ve been doing (I have been paying very close attention to complying with Apple’s “rules”)… But the only way to know for sure is to submit a (non-trivial) app… 😉

Eike Ziller Eike Ziller says:

@SumWon: what are the things that you think would lead to an app using the 4.8 plugin be rejected?

Mike says:

Great work! Just a question, will this ever come to windows or linux, or is it bound to mac osx for technical reasons? Will I ever be able to develop apps on windows for the iPhone?

Eike Ziller Eike Ziller says:

@mike: You’ll have to ask Apple that question.

danny says:

“I’d be a lot more excited about this if Qt weren’t abandoning support for Xcode.”

For everyone complaining about Qt abandoning XCode, remember that the original ‘integration’ was fairly useless and a pale comparison to the plugins available for MSVC and Eclipse. The entire project had to be RE-GENERATED every time you changed a UI file, a moc-able file or resource!

I for one don’t miss it – QtCreator can replace XCode for most non-cocoa OSX development.

SumWon says:

@eike: I just had another look at your source code, and maybe it’s OK now? The setting of environment variables (as you were doing previously) seems to have been a grounds for rejection on some apps, although it isn’t specifically stated anywhere that that is not allowed (which is the most worrying part – there appears to be a whole bunch of undocumented rules for App Store approval). The biggest issue that comes to mind is the text input. The ‘keypad’ method of text input which is used in this plugin won’t make it through approval (IMHO). The text input needs to be implemented using the ‘custom edit control’ method (and support copy/paste). Also, in order to make ‘iPhone’ apps, they (still AFAIK) need to have an ARM6/GLES1 code path. ‘iPad’ apps are allowed to just have an ARM7/GLES2 code path.

@mike: ‘Ever’ is hard to quantify, but certainly not in the forseeable future. It may be possible to make Windows compatible versions of the GCC ARM build tools, but making Windows versions of the app signing tools (which are part of XCode) is not going to be that easy. Apple is almost certainly not going to make a version of XCode for Windows, as having the developer tools on Mac only is helping them sell a few Macs I’d expect. AFAIK it is possible to make ‘jailbreak required’ apps on Windows already. However, as we’re talking Qt here, you can develop/test the app on Windows/Linux/whatever and then do builds for iOS in the later stages of development (this is in fact how I’d recommend doing iOS Qt apps, as debugging Qt apps on iOS is not straight-forward).

Eike Ziller Eike Ziller says:

@sumwon: yes, that environment variable setting is gone. I suppose Apple can reject that on grounds of “Apps that use non-public APIs will be rejected” or something like that… but who knows. Regarding text input – that might be true, though I think I have seen games that don’t do it. Definitely something to pursuit further. ARM6/GLES1 actually is no problem, you can build Qt & the plugin for that code path, it even works on my 2nd Gen iPod Touch since two days now 🙂

Chris Williams says:

I love the idea of being able to take at least the Qt-based core of my applications to iOS through a Lighthouse-based port even if it is some way away. However, the emphasis on QtDeclarative/QtQuick/QML as the UI tool of choice seems to make this pathway a potential licence-compliance nightmare. Qt Quick has a dependency on QtScript/JavaScriptCore which imposes LGPL licensing even on Commercial licence holders. The Apple guidelines require a single binary application: static linking is required to the LGPL libraries. The LGPL requires that the end-user be able to replace the LGPL components themselves, an act that is severely hampered by the locked-down device, and complicated by not having a dynamic linking ability (i.e. I must publish linkable object files or source).

Maybe I am missing something here?

Eike Ziller Eike Ziller says:

Just for clarification: “Lighthouse” is solely an abstraction layer for QtGui. So the expression “Qt-based core of my applications to iOS through a Lighthouse-based port” makes semantically no sense :). If you don’t use QtGui, you don’t have to use the uikit platform plugin (though the phonon plugin might be useful, and of course there were also a few other fixes necessary outside of QtGui, and there probably still are).

Eike Ziller Eike Ziller says:

Regarding the emphasis on Qt Quick:
a) There is the other, Qt 4.7 based community effort going on that afaik go the way of implementing the Qt widgets via native UIKit controls. (Link at the beginning of the post.) I have no idea about the details or the state of that, but it’s a comparably huge effort. If you think it’s worth it I suppose they’d be glad to receive help 🙂
b) If you want controls that look like native controls than I suppose the only way is to use native controls (maybe through a) ). Otherwise you have the option with this platform plugin to either use Qt Quick, or to do something QGraphicsView based yourself (should work since QDeclarativeView is QGraphicsView based in 4.8)

SumWon says:


There’s a (c) option too (which I’ve used for WebKit), and that is to wrap UIKit controls in a custom QWidget. There’s no reason why this couldn’t be done to wrap UIKit controls in QML items as well…

Oscar Forth says:

So has anyone worked out how to do this with some form of dynamic linking on the iPhone? As I see it this is incredibly cool and I would use it in a heartbeat if I could use it for non open-sourced software. However the fact that it statically links to the Qt run time means that anything that uses it requires its source code to be released to anyone who purchases it (I wonder if the apps already out there do this?)

Eike Ziller Eike Ziller says:

@oscar: I suppose one can make it work, but any application using dynamic linking (of non-system libraries) will be rejected from the AppStore. If you go Cydia/Jailbroken it might be an option (and shouldn’t be too hard to set up).

@SumWon: yeah, some kind of Qt/QML Components for UIKit might be possible, though I suppose I would only start to care looking at such a thing after it is clear that Qt/QML apps can be accepted in principle. (For other people it might be the other way round 😉 )

breezeight says:

@oscar reading the qt-interest mailing list I’ve found this Thiago Macieira’s reply http://lists.qt.nokia.com/pipermail/qt-interest/2011-August/035172.html :

“You can statically link using the LGPL. But you must provide a way for the Qt
in your application to be replaced. The easiest way to do that is to use
dynamic linking, but you can always provide the .o for your application and a

@Eike: I suppose this means that there no legal problem to statically link an app with qt and publish on the apple store if I provide the .o, Makefile, etc. Is it right?

Israel Lins says:

For kambala may be you do the same think that I do. To compile for device just change the option -arch from i386 to armv7.

Static linking and not-sharable Qt libraries also means huge apps.

Example from ovi store by Eddy is 12MB http://itunes.apple.com/us/app/simlab-cad-viewer/id428227180?mt=8 It would be even more if you want to add QtDeclarative and maybe some components.

I wonder how many users would cancel the download just tired from waiting until the download is finished or won’t even start after noticing the huge size. It certainly doesn’t matter that much if your app is of unique service, but in this case chances are you already have an iOS native app.

Eike Ziller Eike Ziller says:

@artem: The creators of the SimLab app don’t say what Qt modules they actually use. I’m pretty sure that it doesn’t use QtGui, and what makes that application 12MB is totally unclear (to me) too. Anyhow, of course you are right that shipping Qt libs makes an application bigger. Putting some numbers on it, trying to move out of the realm of speculation:

A compressed package of a two-arch build (armv6+ES1 / armv7+ES2) of the flickrdemo is 17.5 MB. Something like 30K of that is resources (qml+graphics).

A compressed package of a single-arch build (armv7+ES2) of the ‘qmltest’ (which is the same as the declarative/touchinteraction/mousearea example, single very small qml file, no other resources) is 8.2MB.

The limit for applications to be downloadable via 3G (as opposed to requiring WiFi) is set by Apple to 20MB afair (if they didn’t increase that).

I agree that smaller applications would be preferable (though I don’t see it as critical as you; I see mostly the 3G limit set by apple as a deciding factor, if you are over that limit anyhow a few more MB don’t hurt much, if you are below, then it doesn’t matter that much if you save another few MB IMO). Unfortunately unmodified Qt 4.8 has a lot of things that are not used by applications that purely use QML for UI (e.g. all the widgets). A lot is stripped when linking against the static libs (that’s actually a advantage of the static linking as opposed to dynamic linking), but I guess one could still save some amount by removing unused things. The modularizing QWidget out into its own module, that is being done for Qt5, goes in that direction.

BTW, the definition of “unique” would mean that there is no other iOS app that covers that service. Or what do you mean with “in this case”.

@artem: I never saw an iPhone owner who watch the file size 🙂 There are a lot of popular native apps with simple functionality that have installation files larger than 10 MB. And it is fine 🙂
Qt is great for enterprise customers I guess. If it will handle ALL major platforms (except Blackberry and Windows Phone) this will allow to reduce development costs dramatically.
I’ll be happy to use Qt for iOS development too 🙂

Commenting closed.

Get started today with Qt Download now