no, Qt won't be a problem because it's just a wrapper which get compiled into your program
like any other C/C++/ObjC source code (if you're using static libraries).
Flash or Java are other programming languages or complete apps which Apple can easily
filter out.
In theory, Apple would not even notice that an app was written using Qt.

I'm skeptical of this Qt for iPhone. i believe it when i see it working fully. I have some doubts on it both technically and legally. Here are some of those:

First of all, compiling Qt core is one thing, but making the UI, widgets etc work and feel native is much more difficult. Qt is much more than just a UI so it's huge task to port that all to iphone, even if MacOS X is already supported.

Static linking is an bad idea.because you can't then just update the framework and expect that all Qt applications will start using the new Qt version automatically. Statically linked applications do also waste memory, and there is never too much RAM free on devices like smart phones. Well that might not be an issue on IPhone because you can't multitask user applications anyway.

It's not clear at all if LGPL license legally allows static linking whitout releasing the application source code. I know that some people claim that it does, but I really would not count on it. There has been lots of debate on this, but no clear resolution has ever made. So if application developer wants to develop closed source Qt application then static linking against Qt is an bad idea, unless application developer wants to buy a commercial license for Qt.

If we assume that LGPL does allow static linking then there is still problems.

LGPL says that application user must always be able to re-link the application against the same or another version of the LGPL'd library. This is not any problem if application is dynamically linked. If application is statically linked against LGPL'd code then application developer must provide application source code or atleast linker objects so that user can do the re-linking. If some special tools for the process are needed then developer must provide those too.

The only official source for iPhone software is AppStore. If you have iPhone which is not jailbreaked then you can install apps only from the AppStore. If I'm correct then some kind of digital signing is used to make sure that no unofficial applications can be used.

My question is, how is the user going to re-link the application he downloaded from AppStore? And how is he going to do it so that application still works on phone which is not jailbreaked? I think he can't do that because he can't get the application signed. So if developer provides source code or linker objects to user, then user can re-link the application against Qt but the result is not installable on phone. That's not good. Again, LGPL requires that user must be able to re-link the application and the result must be usable.

So is this Qt for iPhone going to be used only on jailbreaked iPhones or how are they going to solve that problem caused by LGPL requirements? The solution can't be that the user has to jailbreak his phone just because he wanted to re-link the application against new Qt.

Ofcourse one solution would be that application developers buy a commercial Qt license.

Neither me nor Nokia have a problem with a GPL App+LGPL Qt and closed-source App+commercial Qt constraint.

we already have the same situation for many other Linux devices:
the kernel is GPL and you could compile it yourself but you cannot upload or replace
the kernel image of the device without a root hack (see Android).
So with a GPLed App everybody could compile it and easily port it to other platforms
like Maemo, but only a ADC member could upload it to AppStore.

about 24% Iphone Apps are free, ca 51% cost < $1.
I would be nice if they used a LGPL Qt so that we can easily port them to Maemo.

I guess Qt-Iphone project is stacked. Isn't it?