iPhone App Store roulette: A tale of rejection

Think back to May 26, 1995. Steve Jobs was wandering in the desert, fiddling with some company called Pixar that made animated movies of dancing desk lamps, and planning his next step for NeXT. Bill Gates ruled the computing world and wrote a famous memo announcing that Microsoft was falling terribly behind in dominating the Internet, which Gates was sure to be a "tidal wave." Microsoft control was slipping and he could feel it.

My brain keeps returning to the moment in time when Gates recognized the difficulty in controlling the creative impulses of the world -- because I've been twiddling my thumbs waiting for Apple to approve my iPhone App version of my book, "Free for All."

[ There are many worthwhile productivity apps you won't find at the App Store. See "21 apps Apple doesn't want on your iPhone." ]

A long time ago in March, I hatched a simple plan. I would dump the raw text of my book on the open source movement into HTML, render the HTML on the iPhone screen, and give away copies. Just for grins, I would also write a new forward to the book, call it the Gold version, charge $1 per copy, and give all of the revenues to the Committee to Protect Journalists, a charity that seems as deserving as any these days.

It was an easy idea that didn't require understanding much about the trickier parts of the iPhone API, like the accelerometer or the camera. All it takes is a few calls to a UIWebView object, a part of the iPhone OS that implements the WebKit HTML rendering engine. Boom -- it's done.

The programming for this plan was very simple, but the distribution has been nearly impossible. Apple's App Store is the only way to share your applications with the world, and it is lorded over by an inscrutable team of guardians devoted to maintaining control over the platform. During the last four months I've spent little time working on the application itself and almost all of that time waiting for Apple to respond.

A man, a plan, an App Store It is possible to skip the App Store if you want to give your application to a friend, but even this requires getting Apple to sign off on the transfer. The iPhone wants to see a cryptographically signed note from its mother before firing up any binary code. The ad hoc distribution mechanism puts a strict limit on 100 copies and enforces this by requiring a copy of each iPhone's unique identification code to be bundled with the digital signature. Anyone who thought that cryptography was going to liberate the world was sadly mistaken.

[ If you are unable to see the images in this article, please click here. ]

There's also an Enterprise plan that might help companies, but it's just a Web site designed to work around the same basic limitation: iPhones won't do something unless Apple allows it. In addition, there are a number of very talented people devoted to cracking the iPhone's security layer and taking complete control of the iPhone, a process they call "jailbreaking," but that option isn't practical for most users or most developers.

So everyone is stuck with the App Store. In the last three months I've submitted slightly different versions of my book reader to Apple close to a dozen times, but the code has been approved only twice.

If this count sounds a bit sketchy, it's because it is. In preparing this text, I just discovered that one database at itunesconnect.apple.com tells me that the Gold version of my application was rejected. But the e-mail note I received two days ago just said that it was "requiring unexpected additional time for review." Is it rejected or am I just waiting for the reviewer to come back from a meeting? Other developers confirm that notes like this are the equivalent of a sailor on shore leave in Marseilles saying, "I'll call you."

One of my two applications -- the free version without the new forward -- was accepted and published by the App Store after several months of rejection. I like to think of this as a victory even though the charity version with the new forward was rejected again about the same time. The only difference was an extra block of text. It wasn't even HTML -- just ASCII. Somehow the bouncers patrolling the velvet rope decided that one twin with slightly shaggier hair couldn't join the other at the bar.

[ If not the iPhone, then what? See "How to choose a mobile development platform," "A developer's-eye view of smartphone platforms," and "The cross-platform option: Web apps for smartphones." ]

Even this success has been frustrating for me because some users started complaining about the scrolling mechanism I implemented in JavaScript. I like the idea that a single tap at the top or bottom of the screen sends the HTML scrolling up or down. The problems the new users found never appeared in testing, no doubt because the testers were too familiar with the app. (Remember, ad hoc distribution rules make it onerous to recruit testers.)

There are other problems. If I were distributing the software, I could communicate directly with the customer. The bug reports would come to me. There would be a direct link. Apple, though, controls all of the interaction. Users' complaints show up only in the product reviews. There's a URL for support listed in the store, but Apple owns the customers.

So I guessed a bit, duplicated some of the users' problems, and rushed out a bug fix. There was no need to scramble, though, because the App Store team took about two weeks to approve the dozen or so new lines of code I had added to my application. What was the holdup? Who knows, but users continued to be frustrated, and I couldn't get the new code to them even if I knew who they were. Other developers report the same problems trying to fix bugs.

Even when you seem to be home free, you're not. Two months after the first acceptance and several weeks after approving version 1.0.2, the mysterious masters of secrecy decided there was something very bad in the code. The App Store rejected the app anew. Where it stands now, I don't know.

New and new again The bottleneck in the approval process is amplified by a weird structural effect the App Store shares with Craigslist. The newest apps get the most play on the front pages of the App Store, so everyone has an incentive to upload a new version as often as possible. It's pretty clear that the iPhone users spend much of their browsing time on the list of the newest applications; getting a new version approved leads to a burst of sales. (Forget about the thesis of "The Long Tail.") Craigslist doesn't bother filtering, but the App Store does, and this just means more work for the bouncers at the door. Everyone is frantically trying to get reapproved, so the workload is endless.

Some developers suggest that the reviewers are delaying approvals to reduce the effects of this clamoring for attention. That is consistent with the way that I often got a rejection notice almost exactly one week after I submit the app. My personal conspiracy theory is the approval team is rated on statistics, such as how many applications are processed within a week of being submitted. But maybe it's something else. We get to know about Dick Cheney's plans at the CIA, but some secrets are better protected.

I would feel better about the App Store's decisions if they were understandable and predictable when they finally arrived, but they seem capricious and often outright wrong. Some of the rejection letters claimed I was misusing the UIWebView. They cited section 3.3.1 of the agreement: "Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs."

My app just dumped pure HTML in the UIWebView. When I wrote back and showed examples from Apple's documentation that used the APIs in exactly the same way, I heard nothing. Apple didn't "think different" when it created its customer service team for the iPhone developer. The company just borrowed standard operating procedure from the worst bureaucracies in the world (say, the DMV from Soviet-era Russia). Then it put the process behind an e-mail wall, giving the whimsical fascists the ability to operate without any contact with their cat toys. At least the old Soviet-era bureaucrats in "The Lives of Others" had to watch the effects of their games.

Some of the delay came because I chose to build my application on an open source project called PhoneGap. This project is a thin wrapper around the UIWebView object. You write your application in HTML and JavaScript, and the code loads it into UIWebView. It saves you the trouble of building out all of the Cocoa code.

You might think that Apple would welcome a toolkit like PhoneGap because such an open source project can reduce a lot of the common bugs that developers encounter at the beginning -- but that's not the experience of many. While Apple doesn't explicitly forbid the use of PhoneGap, it's clear they reject many -- but not all -- projects that use it. Many PhoneGap users report they received the same text in their rejection letters as I did: PhoneGap is an "external framework" and those are forbidden.

Some PhoneGap developers have had some success, and they've shared this with others. The men and women behind the curtain only look at the linking tables to see the names of the objects. So someone wrote a Python script that would replace the word "PhoneGap" with your own made-up package name. Voilà -- it often works.

But make sure you delete words like "gap" from your HTML too because Apple's powerful anti-PhoneGap tool (grep) can sniff them out. When I fixed my code to get rid of the external framework, I inadvertently left in an HTML page with a thank you message to the PhoneGap team. Oops. That file was soon flagged. So I deleted the thank you note and settled down for another few weeks of waiting.

The latest twist is that my application is again rejected (a few weeks after it was approved) because PhoneGap is now officially forbidden. There is hope, though, because Apple says it is in communication with the PhoneGap organizers at Nitobi. When I checked with the folks at Nitobi, they told me that PhoneGap is 100 percent in compliance and they're working on educating Apple. But Apple has told them little except to pay attention to the rules.

School rules Through all of this, I received little guidance from Apple. Whenever I sent in a question asking how long the review would take, I would get back a polite but worthless e-mail saying that every "app submitted to Apple has different capabilities, features, and complexity, which means that individual review times vary. Once the application review process has been completed, you will receive an e-mail notification."

If I asked deep questions -- like why they consider open source code to be external frameworks that must be forbidden -- I got no answer. I began joking that iPhone development is like elementary school. You have to do all of the work yourself. Don't even think of copying that method from some Apache code because that might be seen as a "private API." (Yes, I know that Apple cribbed much of the OS X running on the iPhone from the BSD project, but again this is like elementary school. The teachers can photocopy the worksheets, but the students need to do everything on their own.)

There are other puzzling rejection notes. While all I do is dump HTML in a UIWebView, one time the App Store Magic-8 ball scolded me, "An Application may not itself install or launch other executable code by any means, including without limitation through use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s)."

Anyone who has spent much time trying to understand the more philosophical aspects of computer science will wonder at this impossible distinction. In the most abstract models, there's no difference between a program and data. The data that gives an address for a restaurant can be thought of as a compact program for drawing a map and vice versa. While I'm sure everyone agrees that "good" is "good" and "bad" is "bad," I'm also sure that there's no guaranteed way for detecting a program that is about to download good data or a bad program.

Needless to say, this blocks many useful mechanisms for the app developer. You can't download new fixes for old bugs or even include functionality like a widget in your application. It also blocks great applications like an emulator for old Commodore 64 games. I feel sorry for the developer who apparently went to the trouble to get a valid Commodore license only to be rejected by a squirrelly rule.

Apple is terribly inconsistent on this point. Some ad companies like AdMob and Medialets seem to have no trouble distributing precompiled code that downloads sophisticated ads from the Internet. These programs are explicitly designed to change their behavior after the fact, presumably against Apple's rules, but somehow Medialets has managed to interact with iPhones 1 billion times. And then there's the biggest reason of all: Mac and PC users survive with self-updating applications all of the time.

After a bit, I started bothering everyone I knew who worked at Apple to inform them of how arbitrary and infuriating the whole process could be. A few were polite, but they seemed to be tied up by the requirement to act like good corporate citizens.

1 2 3 Page
FREE Computerworld Insider Guide: IT Certification Study Tips
Join the discussion
Be the first to comment on this article. Our Commenting Policies