Mac App Store

[serkol]

Did anyone submit his/her Qt application to Mac App Store? I mean the new Mac App Store for Mac OS X applications (for desktops and macbooks).

I'm still working on my first Qt application, so I cannot try submitting it myself yet, I need another month or so...

The reason I'm asking: if Apple accepts Qt applications, I will distribute the Mac version exclusively through Mac App Store, and I will not program my own copy protection and automatic upgrade for the Mac version (App Store will do that). If they reject Qt applications, that's not a big deal, I still will be able to sell my application through different sources, but I will have to program my own copy protection (and trial version), and automatic updates. So I don't know, should I start programming these features, or I can spend my time on other things.

[john_god]

I'm not a expert in the subject, far from that , but this link (http://news.softpedia.com/news/Hear-This-Apple-May-Reject-Your-Mac-App-If-It-s-Too-Complex-162758.shtml) says "Cupertino “ported” the same strict rules it applied for iOS devs over to the Mac App Store guidelines".
So I don't think it's possible to deliver a Qt app to the Apple store

[Oliver Knoll]

This might be of interest:

http://www.readwriteweb.com/archives/apples_guidelines_revealed_apps_you_cant_sell_in_t he_mac_app_storep2.php

However, these are rules which "leaked" out of Apple somewhere, they might not be up to date. But they can serve as basis what the current rules would look like.

Especially "problematic" is point 2.5: Apps that use non-public APIs will be rejected

"Public APIs? So everything which is (in C++ speak) declared public: or protected:? So is Qt a non-public API or not?" Go figure! Very sketchy, to say the least.

A taste of what that could mean for Qt is the following point: 2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected

Now technically Qt is not deprecated - for sure Apple never shipped Qt themselves, so technically it can't be called deprecated by Apple. And it is also never "optionally" installed by Apple, it has to be shipped together with the app anyway (and that is easy).

So while Java is explicitly ruled out we are left with the very sketchy point 2.5. And after all, Qt also makes use of the "public API" and technically is just another layer between our code and the OS API - just like all the other layers our own applications provides anyway.


Given the numbers of Qt developers nowadays, and given the fact that Qt really integrates very well into the system (after all, it does not depend on a "runtime environment" like Java does, and the Qt libs are very easy to ship inside the app bundle) makes me hope that "Qt apps will eventually be accepted" - at least when you follow all the other points, especially "make it look/behave like a Mac application" ;)

And I also hope that some other "major big-mass applications" like Google Earth or Opera (yessss, Qt based ;) go first and clear the path for us ;)

Anyway, in a few days we'll know more.


Oh, one more thing... you should quickly abandon your "copy protection", should you really want to distribute your app via iStore:

2.19 Apps that require license keys or implement their own copy protection will be rejected

;)

[squidge]

2.5 simply means that you use only published (public) Mac API functions. MacOS is full of undocumented functions and they don't want you to use any of them, which is fair enough as being undocumented the behavior of those functions could change with any OS update.

However, it could be argued that by using Qt, you are using a competitor to Apple's own Cocoa UI library.

[Oliver Knoll]

2.5 simply means that you use only published (public) Mac API functions. MacOS is full of undocumented functions and they don't want you to use any of them, which is fair enough as being undocumented the behavior of those functions could change with any OS update.

Totally agreed! And I hope that is exactly the "definition" of "only use public API".


However, it could be argued that by using Qt, you are using a competitor to Apple's own Cocoa UI library.

... and that this "foreign API" would be considered "non-public API" and hence be restricted.

However we have seen several Qt apps being submitted and solely (and rightfully) been rejected due to wrong file paths being created/written to, such as file being created via QDesktopServices (most probably fixable on an application level) and ~/Library/Preferences/com.trolltech.plist (created by Qt and most probably must be fixed on a Qt level -> patch, new Qt API method which lets the application control where/if to place that file).

Refer to similar discussions on e.g.

http://www.qtcentre.org/threads/35292-Qt-Apps-banned-from-Mac-App-Store

and

http://stackoverflow.com/questions/4337855/qt-applications-on-new-mac-app-store

The later also lists a file like ~/Applications/APPname.app/Contents/Resources/databasename.sqlite, but I think that one is controlled on an application level, that is easily fixable.

The only real issue so far I think remains with ~/Library/Preferences/com.trolltech.plist, which to my very knowledge cannot be controlled by the Application.

On Windows I think these entries result in registry entries under HKEY_USERS\...\Software\Trolltech (the equivalent of said com.trolltech.plist file, right?), and store e.g. the known plugin directories etc.). I think also there the application does not have control about the registry entries, but so far there is no MS App Store either ;)


The bottom line: so far Apple did not seem to complain about the fact that these apps are Qt based. Maybe their test suite did not reach the point of whether that test would complain, because it stopped earlier because of these wrong file paths. But time will show - so far it is looking not too bad ;)

Cheers, Oliver

[wysota]

However, it could be argued that by using Qt, you are using a competitor to Apple's own Cocoa UI library.
Qt uses Cocoa behind the scenes (to be exact one of the three Mac ports does). Whether "Cocoa" and "Cocoa UI" is the same, I don't know. I would guess yes (the Aqua widget style probably redirects calls to Cocoa so it depends on Cocoa UI and not competes with it).

[john_god]

I have zero experience in deploying in the App Store, and perhaps I'm being naive by asking this question, but, don't they have some support email where one can openly ask "Do you accept apps developed with Qt ??????"
Also one has to pay to try to submit the app, or only after the app is accepted ? It would be very frustanting to pay for something that get's rejected in the end.

[jimaz]

I just got my Qt application rejected from the app store due to usage of a non-public API. The call is from Qt itself (using GetNativeWindowFromWindowRef in Carbon.Framework). As my application is using only Qt and no direct calls to Carbon or Cocoa, I am not sure how to proceed - there could be several other non-public APIs used even if I managed to get around this one.

Jim

[wysota]

I just got my Qt application rejected from the app store due to usage of a non-public API. The call is from Qt itself (using GetNativeWindowFromWindowRef in Carbon.Framework).
Try the Cocoa port of Qt. It's the one for 64bit Macs (it shouldn't contain calls to Carbon). The 32 bit is based on Carbon which I think (I may be wrong) is (or soon will be) deprecated by Apple anyway. But probably there will be an equivalent call to Cocoa there :)

Here is a link that might be helpful if you don't find anything better: ftp://ftp.qt.nokia.com/qt/source/qt-mac-cocoa-opensource-4.6.3.dmg

[jimaz]

Thanks wysota, I was actually not aware of a separate Cocoa port. I should have done my homework, I guess :) Will keep posting updates in this thread if my app gets accepted.

Thanks again,

Jim

[wysota]

Is there some online tool you can run your app against to see if it will pass compliance tests for AppStore? It would be cool if there was something like that.

[jimaz]

Unfortunately there is no tool to check if the application should pass the AppStore approval process. When submitting an application in XCode, the last step before actual submission is a "Validate" step, but that is only signing the application with the developer key if I understand correctly. I originally assumed this step would check for basic mistakes as missing referenced libraries or usage of private APIs.

Jim

[jimaz]

My Qt app now got approved, after following wysota advise to use the Cocoa port :)
Thanks again, wysota!

Jim

[wysota]

Nice, congratulations. Maybe you could provide a list of steps you needed to take to have your apps approved so that others might benefit from it? I mean the things you had to do or ones you had to avoid.

[jimaz]

Actually, the only step necessary was to bundle the Cocoa version of Qt instead of the Carbon version. The actual packaging of the application is not really specific to the app store, I basically followed these instructions for XCode packaging: http://doc.trolltech.com/4.7/deployment-mac.html - I bundled the frameworks as described there and made sure I only included the release versions of the QtGui + QtCore).

Cheers,

Jim

[jooncheol]

Great news!
Could I see your app in the Mac App store now? I really want to see your qt app.

[jimaz]

Not sure if I'm allowed to post a link, since it's a commercial app. Admin - feel free to delete the post if I'm breaking any rule.

http://itunes.apple.com/us/app/eventclock/id403026288?mt=12

It's not a typical app, since the only visible window is the dock icon - and an about dialog :)

Unfortunately the current version has a bug, dock menu items don't get triggered - I hope it's because of a bug corrected in Qt 4.7.3. I will try to update it in a few days and see.

Jim

[raphaelcruzeiro]

Jim,

I had the same problem that you had with the dock manu items. Did you ever found out if the bug was fixed on Qt?

Tks

[jimaz]

Raphael - I have not checked it, but I should be able to test this soon.Right now I have some deployment issues with the new XCode 4 that I'd like to resolve before upgrading to a more recent Qt.

Regards,

Jim

[thru]

Not sure if open a new thread for this question, let's start here specifically addressed to Jim that may have experience about it.

In the documentation about the App Store I see they refer to implementing the "app purchase api". Did you have problems or too much work with that? I ask in therms of having to call the api in Objective-C format or other things that may be complex for a Qt developer that didn't scratch the surface of native Mac developement.

Thanks!
Juan

Edit: Reading deeper I see that the app purchase api apparently refers to the cases of selling goods rather than software apps so maybe my question doesn't apply, anyway, in a more broad meaning, did you have to dig into non-Qt technologies to make your app compatible with the appstore?

[Robson Ramiro]

Hi,

Since August I´m trying to approve one App, all of trouble was solved but "/System/Library/Frameworks/Carbon.Framework/Versions/A/Carbon GetnativeWindowFromWindowRef" persists, I can´t use cocoa port because Qt3Support is not supported by. (I´m using Qt 4.5.2)

There are solution for this??

Thanks!

Robson