Apple's guidelines for their new Mac App Store say that you cannot use deprecated libraries such as Apple's Java framework. But will Apple allow apps which come with a third-party Java runtime, such as SoyLatte?
+1
A:
It seems ALL java apps will be banned:
http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/
Peter Knego
2010-10-21 21:25:35
This sucks, bad.
Flash84x
2010-10-21 21:45:57
A:
No, they will not.
Consider these rules:
2.5 Apps that use non-public APIs will be rejected
2.7 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.20 Apps that present a license screen at launch will be rejected
2.21 Apps may not use update mechanisms outside of the App Store
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
5.5 Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
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
Using private or "deprecated" technologies are forbidden by the rules (2.5, 2.24) as well as code which depends on things not installed by default on Mac OS X (2.15).
2.15 would force you to bundle the whole JRE with your app. But that would violate (2.5) because the JRE will use non-public APIs to integrate with the Apple Look-and-Feel and probably 2.20 too.
Without that integration you would be in breach of 6.1 and 6.3.
Additionally that would make it your job to update the app every time Java gets a security update, because Oracle's updater for Java won't be allowed to work (2.21).
Eventually getting some letter from Oracle's lawyers (required by 5.5) might take some months, so you will be very late to the market and your app might be rejected by rule 2.7.
This has nothing to do with technology. It's a political decision just like what happened with Flash and if people try to sneak around it Apple just won't approve it. They have tons of rules on which they can base their rejection of your app.
Basically Apple doesn't want developers to write cross-platform applications and pushes them to develop Apple-"exclusive" applications in a language Apple controls.
soc
2010-10-21 21:25:54
Factually incorrect - your Mac App Store application is free to depend on anything not installed by default on Mac OS X, provided it can satisfy its dependencies using resources packaged in its app bundle (2.22) and not copied outside the app bundle (2.15). 2.24 is intended to avoid the "I downloaded this app, and now it doesn't work?" problems that relying on the user to have already installed optional resources would cause.
Jeremy W. Sherman
2010-10-21 21:29:55
I'm not sure to which paragraph you are referring to, I guess after I changed the wording to add the actual rules the phrasing you objected to is gone now.
soc
2010-10-21 21:56:41
+1
A:
Yes, provided everything needed to run your app is part of the app bundle and your UI looks and behaves completely natively. You are barred from relying on users to have already installed optional or deprecated technologies (libraries, runtimes, or what have you).
Specifically, the rules most likely to be relevant state (PDF):
2. Functionality
2.22 Apps must contain all language support in a single app bundle (single binary multiple language)
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
6. User Interface
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
Taken together, the two functionality rules quoted seem to indicate that you are free to use a third-party Java runtime provided everything needed to run your app is contained in your app bundle.
The user interface rules would bar any but the most flawless emulations of all the native UI widgets. Realistically, you would need some way to use native UI widgets from your Java application. Eclipse's Standard Widget Toolkit might meet the UI requirements, for example.
Jeremy W. Sherman
2010-10-21 21:26:08
This is definitely false. Rule 6.3 and 6.5 can't be met by Java without using private APIs (2.5).
soc
2010-10-22 22:21:15
Does the Cocoa port of the Standard Widget Toolkit use private API? And even if the UI had to be handled using Obj-C, that's not to say that you can't put all the model and controller logic into a Java application. This is similar to how a Cocoa preference pane can be created to control a faceless application, such as a daemon or utility.
Jeremy W. Sherman
2010-10-23 05:18:26
Besides, the question wasn't about whether an entirely Java application would be allowed in the Mac App store. The question was whether an app in the Mac App store would be allowed to run Java code using a third-party runtime, and the answer per 2.22 and 2.24 is as I said: you are free to use a third-party Java runtime provided everything needed to run your app is contained in your app bundle.
Jeremy W. Sherman
2010-10-23 05:21:02