Qt Apps banned from Mac App Store?

[wysota]

Yes, it does.

[jfk]

Does that mean Qt 'Apps' are completely out of the question? Where has Apple drawn the line? After all they distribute Python and Ruby with their Operating System. Surely Objective-C can't be the only guest to the new App Store!

[wysota]

Does that mean Qt 'Apps' are completely out of the question?

Officially, yes.

[squidge]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted. All others will be rejected.

So Qt applications will be permitted as long as your careful, but they really want you to create native applications using Cocoa so they can ensure to keep control of the look and feel of applications for their platform (eg. if too many people switch to Qt, people ignore the Apple API and Apple lose control of their own platform, so they keep it on a tight leash)

[wysota]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted.

Qt is an "optional library", if at all you can install it through App Store. I doubt they will accept any application that depends on a library you can't install through App Store. Of course when speaking about desktop Macs. For iPhone there is no official Qt port anyway.

[serkol]

Qt is an "optional library", if at all you can install it through App Store.

Do you really have to "install" Qt? It does not have to be "installed". Qt is just several files inside your application bundle.

By the way, is it possible to compile a Qt-based application for Mac OS X in such way, that the application file contains all necessary parts of Qt? I'm new to Qt (I'm finishing my first app, targeted to Windows and Mac OS X).

[wysota]

Do you really have to "install" Qt? It does not have to be "installed". Qt is just several files inside your application bundle.

So if you have 10 Qt-based applications you get those "several files" ten times each, right? I know disk space is cheap but is it really a good approach?

By the way, is it possible to compile a Qt-based application for Mac OS X in such way, that the application file contains all necessary parts of Qt? I'm new to Qt (I'm finishing my first app, targeted to Windows and Mac OS X).

Yes, you can compile it statically which makes your application really huge.

[SixDegrees]

Yes, you can compile it statically which makes your application really huge.

Also, you open yourself up to additional licensing issues when you create static builds. The GPL and many of it's variants consider your application to be derivative when statically linked, but not when it is linked dynamically. In general, when you statically link another library you are actively bundling and using it from a legal standpoint, and not simply taking advantage of an existing environment. You run a much higher risk of losing control over your own source code when you statically link, especially with large, complex external libraries whose dependencies may be difficult to discern.

[john_god]

Bought myself one mac some months ago, thinking in giving a shot at iphone development. I'm somewhat disappointed with the xcode tools developer, it doesn't have c++ and compared to Qt, seems like I walking backwards. I really enjoy Qt development, and besides with new technologies there's always a learning curve one has to cross. So for now, I will postpone my i-phone development and keep on playing with Qt. Apple, being the major app store player in the market, for now can afford all the restrictions. Nokia just recently released the ovi store, android market is running wild, so let's see what the future will bring, if with all the competition Apple will keep their restriction policie.

[serkol]

I keep programming my first Qt app (Mac/Win). I try to make the Mac version look as much "native" as possible.

I've came across 2 Qt/Mac bugs that bother me. If they bother you too, could you possible vote for my bug reports, so that they are fixed sooner?

http://bugreports.qt.nokia.com/browse/QTBUG-15474
http://bugreports.qt.nokia.com/browse/QTBUG-15475

[wysota]

And how is this related to the discussion in this thread?

[serkol]

It is related. I don't see any technical reasons for Apple to reject a Qt app that includes Qt framework inside the bundle, UNLESS the app does not look like a native Mac OS X app - breaks the GUI guidelines. One of the 2 bugs - modal dialog that permanently loses its focus - is definitely one of those bugs that can be a reason for Apple to reject a Qt app.

[Oliver Knoll]

Please also have a look at http://stackoverflow.com/questions/4...624284#4624284

A similar discussion is going on there.

And yes, whether Qt Apps really behave like "native Mac apps" is relevant as well, even though posting individual bug reports here is maybe really the wrong place (even though I voted on them

For instance, if Qt creates ~/Library/Preferences/com.trolltech.plist files which might be on the wrong place (in the above link I rather suspect the file path ~/Applications/APPname.app/Contents/Resources/databasename.sqlite, since ~/Applications is not a standard location) then this is an issue and should be fixed by Nokia.

Also if the Apple guidelines require "sheet" dialogs instead of modal dialogs (and I honestly don't know the detailed Apple requirements - yet and those are buggy and that would be a reason for Apple to reject the app... well then, let's hope it gets fixed as soon as possible!

But that said: these are issues which are relatively easy to fix (file paths, dialog focus issues...).

But the good news is that according to Stack Overflow the app in question did not get rejected (yet?) because it was using Qt per se!

[mgoetz]

I've posted QTBUG-16549 to Nokia. Make sure to vote for it.

[jh]

Opera in Mac Store!
Isn't Opera build with Qt? So, there should be no problem to get you Qt app to the MacStore.
Regards,
jh

[koan]

So if you have 10 Qt-based applications you get those "several files" ten times each, right? I know disk space is cheap but is it really a good approach?

This is the Mac way; applications are packaged in bundles. It avoids DLL hell but at a cost in disk space. At least you know that installing a new application won't mean updating a library to a version incompatible with another app.

Please see http://doc.qt.nokia.com/4.7/deployment.html

Also, you open yourself up to additional licensing issues when you create static builds.

You dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied. However, the Mac store may place other restrictions on top that are not compatible with copyleft licensing, re: http://www.theregister.co.uk/2010/05..._apple_itunes/

[wysota]

This is the Mac way; applications are packaged in bundles. It avoids DLL hell but at a cost in disk space. At least you know that installing a new application won't mean updating a library to a version incompatible with another app.

I'm not sure you are right. There is also a concept of "frameworks" and as far as I understand it that's what Qt is.

You dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied.

No, you are wrong. GPL will certainly not be satisfied with that. But since SixDegrees meant static builds I don't see how your opinion on dynamic builds is relevant here

[koan]

I'm not sure you are right. There is also a concept of "frameworks" and as far as I understand it that's what Qt is.

Frameworks are like libraries and they can be packaged up in the application bundle. Thanks for casting doubt on my answer.

No, you are wrong. GPL will certainly not be satisfied with that. But since SixDegrees meant static builds I don't see how your opinion on dynamic builds is relevant here

I meant to say LGPL would be satisfied up to this point, but as I said the other restrictions would probably invalidate this and the possibility to try GPL. Since dynamic builds would have been feasible had this not been the case then there would have been no need to be worried about static builds.

[jfk]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted. All others will be rejected.

That's what I'm hoping for! On the other hand, I'm already worrying that my App-to be gets rejected according to:

Apps which appear confusingly similar to an existing Apple product will be rejected.

Apps which appear confusingly similar to an existing Apple product will be rejected.

To copy to clipboard, switch view to plain text mode 

In any case I'll give it a shot!

[SixDegrees]

Also, Apple is a notorious for closed systems. Apart from keeping control of the look and feel, this also allows Apple to charge inflated prices for the "official" development toolkit, charge high annual fees for developer "licenses" and otherwise squeeze cash out of their customer base in every way possible.