Language requirement for Mac App Store

Question

I was thinking about creating an application for the Mac App Store, but was wondering if they will only accept programs made in Objective-C using XCode.

I was thinking about making the program multi-platform by using Qt, so I can release Windows and Mac versions.

Answer 1

Considering that I don't represent Apple, and haven't seen any examples where this debate has played out yet in favor of one side or the other, it's difficult to give you a definitive answer to this question. Instead, I'll post what look like the relevant sections of the Mac App Store Review Guidelines and let you decide for yourself.

First up is Section 2 on "Functionality". This a pretty broad topic area, and it appears to me that there's lots of potential for violations using a third-party GUI library. Of course, I also think all of these can be worked around, if you're sufficiently interested.

2.5   Apps that use non-public APIs will be rejected

. . .

2.14   Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed

2.15   Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations

2.16   Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected

. . .

2.24   Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected.

. . .

2.29   Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected

Section 6 on the "User Interface" is also worth considering for an application that uses Qt. I refuse to use the library on Windows because it doesn't use standard platform GUI elements. I can only assume it does the same thing on the Mac, and it remains to be seen how Apple will react to that. (I suspect alternative cross-platform GUI libraries that behave correctly and use native widgets are free and clear here.)

6.1   Apps must comply with all terms and conditions explained in the Apple Macintosh Human Interface Guidelines

. . .

6.3   Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected

. . .

6.5   Apps that change the native user interface elements or behaviors of Mac OS X will be rejected

Answer 2

To elaborate on how the GUI requirements posted by Cody Gray will make it hard for a non-trivial Qt app to be accepted, consider some of the Mac-specific features that will have to be implemented or at least checked for correctness for the case of a simple text editor:

• correct keyboard shortcuts, including the emacs keybindings that are standard for Cocoa text controls
• proper menu structure, including:
  • preferences in the application menu, not the edit or tools menu
  • access to the special characters tool from the edit menu
  • "Open Recent" submenu of the file menu, with a clear menu entry, as opposed to the recent files list embedded in the file menu on Windows
  • a proper Window menu, including the "bring all to front" item
  • a help menu with an integrated search box
• the ability for the application to stay open after all windows/documents have been closed
• proper dock icon behaviour, including the window list in the context menu
• the window title bar file icon, which can be dragged and dropped on to other apps, or right-clicked to get a menu of the directories in the path of the file, so that you can open the enclosing folder in the Finder

As you go down this list, the probability that the feature can be easily implemented with a cross-platform toolkit decreases. All of these features have been omitted by at least one Qt Mac app in my experience. Some of these features could probably only be easily added to Qt by using non-public APIs. However, most of these features are free or almost trivial to implement in a Cocoa project, so they are almost ubiquitous in native apps, and Apple would be right to reject your app for screwing them up.

If your app is non-trivial and isn't a fullscreen OpenGL game, then you are probably better off writing a native GUI with a cross-platform back-end. The alternative is code that is full of #ifdefs but still never quite gets the job done right.