Apple's App Store Submission Process & Java Verified

There’s a lot of discussion going on at the moment about Apple’s App Store submission process and the role that carriers play in vetting applications. When the App Store was announced, I na├»vely believed that Apple had successfully cut out the carrier middleman responsible for crippling every other mobile development platform. Unfortunately, the carrier protectionist oligopoly lives on, albeit on a slightly smaller scale.

But it’s not all doom and gloom. I see two major issues:

  1. Carriers are barring applications they deem disruptive to their business
  2. The submissions process is completely opaque

If history is anything to go by, the first issue is going to be very difficult to resolve directly. It’s the second issue I think we’re in a position to easily fix.

First, I think it would be productive to look at the J2ME platform.

One of the biggest issues that’s plagued J2ME has been greedy carriers standing in the way of developers trying to bring their applications to market (ring any bells?). To access run-of-the-mill features like the address book, networking or GPS APIs you need to sign your application. Problem is, certificates from well known CAs like Verisign are stripped from carrier-branded phones in favour of carrier issued certificates. Many carriers run their own developer program to facilitate code-signing of applications that will run on their network.

The industry’s “answer” to this problem was to come up with Java Verified, a process that allows developers to submit their applications to one of a handful of “Authorized Test Houses” and pay around $300USD to have it taken through a standard test procedure. If it passes, you get a signed application which will run on most carriers and devices. If it fails, you pay again for the privilege of having it retested. Also note that you’re paying to have your application tested on a specific device of your choosing, so if you’d like your application tested on multiple devices, you pay per device.

Disregarding the fact that the Java Verified process will leave you thousands of dollars poorer once you’ve released a few versions of your application to a handful of devices, it’s quite similar to Apple’s verification process. You submit your application, it gets tested according to a criteria that carriers are happy with, and if your application passes you’re good to go.

BUT, there’s one minor difference; the Java Verified testing houses are all following the same open, standard test script. It’s called the Unified Testing Criteria (PDF), and it’s made available to developers so that they know how their applications are being scrutinised by the testers.

I think Java Verified’s Unified Testing Criteria would form a great basis for a similar document to be written for the App Store submission process. It would cover areas like:

  • High-level APIs being used (GPS, address book etc.), how frequently they’re used, and whether or not they remove user data (address book entries etc.)
  • Remote content used in the application. Where does it come from? Is it interpreted and/or executed to change the behaviour of the application? Could it contain offensive content? Does the application’s rating take into account mature content?
  • Data usage over 3G, including a clear set of quantitative guidelines that take into account what carriers deem appropriate on their networks
  • Rights to publish content, either through ownership, licensing or fair use
  • Use of advertising
  • Whether or not behaviour, usage and metrics about the user are recorded
  • Stability, performance, memory, network and battery usage tests
  • Adherence to the Human Interface Guidelines (HIG)
  • Handling of memory warnings
  • Handling of registered URL schemes
  • Ability to run during a call or tethering
  • Ability to handle lack of network access or network delays
  • Appropriate use of the keychain for secure storage

The document would likely take the form of a questionnaire, with a clear definition of pass/fail conditions for the various questions. If a developer filled out the questionnaire and received a clear pass but Apple’s testing produced a fail, the difference between their questionnaires would form the basis for productive communication to resolve the issues and allow for resubmission. The document would evolve over time, hopefully reaching a point where if you filled out the questionnaire yourself and got a pass, you’re almost guaranteed to get through the submission process.

I really think this would make a world of difference, and wouldn’t require any drastic changes for Apple other than a little bit more open documentation of the existing process.