mtech

Custom Xcode app icons

In case you're installing multiple copies of Xcode and want to make sure you keep track of which is which, here's a custom appicon.icns file that you can drop into Xcode's Resources (right-click Xcode.app, select "Show Package Contents", and drop this icns file into the Resources folder thus displayed, selecting "Replace" in the warning dialog).

Just for reference, this is an image of Jeff from Coupling:

App Stores Compared

Lately there's been, frankly, a lot of whining about Apple's review process for apps submitted to the iPhone app store. A lot of this concern comes from desktop developers, often Mac developers, who have never dealt with a mobile app certification process before. For the sake of educating the broader community, let's compare the App Store approval process with similar processes for other mobile platforms.

Nokia Series60

Depending on app permissions, you may need to be tested by both a third party test house as well as Nokia, according to strict published criteria. Dev must provide functional specs. Dev pays for all tests, per app per device. No distribution is included, just certification. Testing can take anywhere from a few days to several months depending on the parties involved.

Java Mobile Edition (J2ME)

Requirements vary wildly by distributor. Some phones will accept Unified Test Criteria (UTC)-signed apps. Some carriers require their own UTC-like tests. Developer typically pay per app per device for testing. No distribution is included. It's generally difficult to distribute a single J2ME binary on more than few tens of thousands of phones because of the various operator and handset requirements. Testing takes anywhere from a couple days to a couple weeks depending on the complexity of the app. Shoddy third-party testing means that most test certifications are meaningless, and app quality is generally low.

Android

Google charges once for a signing certificate, then allows devs to post whatever they want to the App Market. No testing is performed, and the consumer receives no explicit or implicit guarantee of quality. It's not clear what control the mobile operators (such as T-Mobile) have over app distribution. Android relies on post-uninstall comments by users to catch malicious or poor quality apps.

BREW

Strict third party testing is required and costly. Devs pay per app per device for testing. Distribution is at the whim of the carrier, and not automatic after verification testing passes. Popular apps are often shamelessly ripped off by the mobile operator itself, then removed from distribution.

BlackBerry

Similar to Android: devs self-test and sign. Distribution not included (though this process will be changing soon, and presumably look a lot more like the Android App Market or the iPhone App Store).

Apple: Cocoa Touch

Testing appears to be basic blackbox testing for most apps. Apple does not require functional documentation or other specs. Developer doesn't pay, other than for initial Dev Program entry (and cert renewal). Distribution is included. Approval takes anywhere from a few days to a few months(?) depending on unknown factors.

---

Analysis

There are several advantages I see with Apple's current process:

• The developer only deals with one partner to get the app distributed: Apple. The dev is effectively shielded from the mobile network operator and other stakeholders that add a lot of noise to other mobile platforms.
• Certification is necessary and sufficient for distribution. Once you pass Apple's testing, you're in the App Store, and anyone can find you via iTunes. This is tremendous, and its value can't be overstated.
• There is no per-submission cost to the developer. Once you've paid the Dev Program entrance fee (which is miniscule compared to even one round of BREW testing), you can submit as many apps as you like. But please, take the time to build a quality app before submitting it, so you're not wasting everyone's time.
• The general acceptance criteria are published. Sure, Apple testing goofs up occasionally, and some policies are vague or in flux. But most developers can find out very quickly whether the content of their app idea will be acceptable to Apple just by reading the docs.

Now, granted, there is room for improvement with Apple's process.

• Some policies need to be clarified and published. For example: Is it OK to provide an alternative to all of the built-in apps?
• The bar is too low, though it's starting to rise. Diluting the App Store catalog with yet another Flashlight app or ringtone app helps no one. It confuses consumers, reduces the price point good devs can charge for quality apps, and leads to poor user experience. So far Apple has maintained tight control over the user experience on the platform, and it should build on that, filtering out apps that provide very little user benefit.
• A little more visiblity into the testing pipeline could help. For instance, if I discover a small glitch in an app I just submitted to the approval process, should I wait for the current submission to complete, or cancel it? Right now there's no way for a developer to know how far along their app is in the testing process.

As mobile developers we should continue to push for Apple to improve the entire ecosystem surrounding the iPhone and iPod touch: this new platform has created a huge opportunity for all of us, and a fast-growing consumer fanbase. I think it helps to take time out to appreciate what a significant improvement Apple has already made over existing mobile platforms.