Qt Apps banned from Mac App Store?

[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!

[wysota]

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.

You can place your settings wherever you want, nothing needs to be "fixed" for this.

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!

Sheets are available in Qt for ages now so no fix needed here as well. People just need to use them.

[Oliver Knoll]

@wysota: Off course can paths be fixed! The question is by whom, the application itself or Qt. I have never used the mySQL lite in Qt, but since the mentioned path is related to that DB the question is justified whether it is the DB writing that file by itself, or whether the app has control over that location!

As for the "sheets": Did you understand to what my comment relates? The topic was that sheets are buggy and someone said that this does not belong here, and I backed up another opinion that it really does, as this might influence Apple's acceptance testing! And that is what this thread is all about? Did you not read the previous posts? Did you not understand the context of this discussion?

Cheers

[wysota]

@wysota: Off course can paths be fixed! The question is by whom, the application itself or Qt. I have never used the mySQL lite in Qt, but since the mentioned path is related to that DB the question is justified whether it is the DB writing that file by itself, or whether the app has control over that location!

By the application, of course. If Qt was upgraded just like that, it would break all the existing applications that previously saved the database in the default place.

As for the "sheets": Did you understand to what my comment relates?

Maybe I didn't because there is a missing closing bracket in your post and the place where you put the bracket changes the meaning of your whole sentence completely.

And that is what this thread is all about?

About sheets? Not really

Did you not read the previous posts? Did you not understand the context of this discussion?

Bearing the fact that I particiapated in this discussion from the very beginning you should probably answer your question yourself.

[AronR]

So we submitted a Qt based app to the App Store and had it rejected for the following reasons:

- Improperly named files in ~/Library/Application Support/*
- File created at ~/Library/Preferences/com.trolltech.plist

The first was a result of using QDesktopServices::storageLocation() for QDesktopServices::dataLocation or QDesktopServices::cacheLocation

They need you to create the directory not like
~/Library/Application Support/Company Name/Product Name

but as

~/Library/Application Support/bundleId (com.company.App)
The following patch will change Qt to use the QCoreApplication:rganizationDomain() and QCoreApplication::applicationName() fields to build the path to store for data and cache. This is ONLY valid if you bundle Id exactly matches the above values
qt-mac-app-store-cache-location.txt


The following patch will add an exported function called void qt_force_trolltech_settings_to_app_area(bool bVal) which you must call FIRST thing in your main function. To access declare an extern to it for proper linking. This will put all items found formally in com.trolltech.plist as a group "Trolltech" inside the default plist file for your app (See above patch about domain and name for proper bundle id usage).
qt-mac-settings-in-app-area.txt

[Oliver Knoll]

So we submitted a Qt based app to the App Store and had it rejected for the following reasons: [...]

They need you to create the directory not like
~/Library/Application Support/Company Name/Product Name

but as

~/Library/Application Support/bundleId (com.company.App)

Now that was a really informative post on that subject, thanks for sharing even the patches.

One question though: did you in any form contact/inform Nokia about this, e.g. as a "Suggestion" at http://bugreports.qt.nokia.com/?

I haven't studied your patches in detail yet, but I think there should be a Qt API which lets the application control where the Qt configuration is stored, and how the own application settings are called.

From what I understand from your post is that currently one has to patch the Qt sources, as to make certain functions visible, is that right?

Thanks for sharing!
Oliver

[wysota]

One question though: did you in any form contact/inform Nokia about this, e.g. as a "Suggestion" at http://bugreports.qt.nokia.com/?

They won't include it. It would break compatibility with existing apps. Since this is something the application developer is fully in control of there is no point in modifying Qt. You just have to go past the happy "hey, let's use the defaults" approach.

I haven't studied your patches in detail yet, but I think there should be a Qt API which lets the application control where the Qt configuration is stored, and how the own application settings are called.

There is. Have a look at available constructors for QSettings.

[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

[weaver4]

Anyone know if the new 4.7.3 Beta Release fixes this issue?

[dhjdhj]

I am wondering the same thing.....a month later!

[cnnbboy]

http://lynxline.com/submiting-to-mac-app-store/
see it,it's really?

[cincirin]

seems to be really. GLC_Player is other Qt based application placed on Mac App Store

[claurel]

I just had my Qt-based app Cosmographia approved by Apple. They review process was quick: three and a half days, including a rejection because I had messed up and linked the executable to Qt framesworks outside the bundle.

Here's what I did:

- Rebuilt the Qt 4.7.3 libraries with the three patches from Aron Rosenberg: https://bugreports.qt.nokia.com//browse/QTBUG-16549
- Added "-gdwarf-2" to QMAKE_CFLAGS and QMAKE_CXXFLAGS to force building the Release version with DWARF+dSYM mode
- Created a custom Info.plist with the app category and bundle ID; forced qmake to use this instead of the default by setting QMAKE_INFO_PLIST in the project file
- Did a full rebuild
- Generated symbols:
dsymutil AppName.app/Contents/MacOS/AppName -o AppName.app.dSYM
- Signed the app bundle:
codesign -f -s “3rd Party Mac Developer Application: My Name” AppName.app
- Built the package:
productbuild \
--component AppName.app /Applications \
--sign “3rd Party Mac Developer Installer: My Name” \
AppName.pkg

Definitely test the package afterward so you don't get rejected for a silly reason:
sudo installer -store -pkg AppName.pkg -target /

My app uses nearly the full set of Qt libraries, including QtDeclarative. Apple doesn't seem to mind as long as the app works and doesn't write files outside of its sandbox.

--Chris

[ChrisW67]

Are you using Qt under the commercial licence or LGPL?