I’m happy to announce that we’ve released a new version of our iPhone & iPod touch Superguide, which compiles all our best information about the iPhone and iPod touch in one handy guide. Already available as an excellent e-book in PDF format for $13, the book is now also available (appropriately enough) as an iPhone app for $5.
We’ve never published a book specifically for the iPhone and iPod touch before, but we figured it might be useful for iPhone users to have our book with them as they’re out and about with their handheld device. It’s a bit of an experiment to see if people really want to consume this sort of reference material in this fashion. We’re using the same technology behind Lexcycle’s excellent Stanza e-book reader to present the content of our book. As a result, you get some of the great Stanza features, including the ability to set typefaces and font sizes, and even quickly toggle between day mode (black on white) and night mode (white on black).
Story behind the story
Now, as some of you may have read elsewhere, getting this app up on the App Store was not as easy as you might think it would be.
We submitted our app to Apple, and it was rejected. The app reviewer we spoke with suggested that there was a formatting bug in the e-book reader itself. We consulted with Lexcycle on this one, and resubmitted, confident that we had addressed the issue.
At this point in the process, things had gone about as smoothly with Apple as they had with our previous app, App Gems. That app was rejected a single time for an understandable (albeit somewhat frustrating) reason. We made a change, re-submitted, and we were live on the store.
However, with the iPhone and iPod touch Superguide, everything suddenly derailed. The person on our staff who was in charge of submitting this app to Apple got a message from a new app reviewer (or, as I’ve started calling them, app rejector) with an entirely new list of demands.
Our rejector started by demanding that we change the name of our book about the iPhone from “iPhone Superguide” to “Superguide for iPhone,” because apps are not allowed to use Apple trademarks as part of their brand name.
I Am Not A Lawyer, but let me try to explain this. Since Apple controls the entire App Store process, from display to sale, the company’s lawyers obviously feel that Apple must aggressively protect its rights. I’d imagine that Apple executives are also not thrilled about the idea of someone making a fortune on a game called “iPhone My Car” or something similar. If you submitted “iPhone My Car,” Apple would reject it and suggest you call it something else, like “My Car for iPhone” or “Style my Car.”
But here’s the problem: Our book isn’t named “iPhone Superguide” because it runs as an iPhone app. It’s named “iPhone Superguide” because it’s content about the iPhone. Calling it “Superguide for iPhone” is not only inaccurate, but it makes it more difficult to sell future Superguide books for iPhone since they'd all be Superguides for iPhone of one sort or other.
In the real world, we can publish books about the iPhone and use the iPhone’s name because we’re part of a free press, and Apple doesn’t have the right to restrict our use of its product names so long as we’re using them in an editorial context. Like, say, a book about a product. What we suddenly discovered was, according to our rejector, the real-world rules didn’t apply in the App Store.
What’s worse, our rejector—his name was Steve, though it’s not the one you’re thinking of—told us that we had to change our app’s icon, too. The icon was a simplified representation of our book cover, which was—big shock—a picture of an iPhone. No graphical representations of the iPhone are allowed in iPhone apps, we were told. It’s a lesson that Marco Arment learned a while back when he dared to create an icon that illustrated what you did if you tilted your iPhone by showing an iPhone being tilted.
Once again, we were confused and a bit upset. We responded to Steve, explaining that we were publishing a book about the iPhone, but he was insistent that the rules were the rules. We decided to compromise and change the name of our product. We redesigned our icon to omit the iPhone but include the word “iPhone,” to differentiate it from other future Macworld-related apps.
We thought we were on safe ground with that one, mostly because we had looked at David Pogue’s book about the iPhone, also available on the App Store. His book’s app icon didn’t include a picture of the iPhone, but did feature the word “iPhone” in big, bold lettering.
Pogue’s book was also called “iPhone: The Missing Manual,” which we pointed out to Steve, because we thought it was inconsistent with what he was telling us. Steve very politely told us that he wouldn’t discuss already-approved apps or allow us to use them as precedents, and that for all we know, his next call would be to David Pogue to demand that he change his app’s name, too. (I checked with Pogue. He hadn’t heard a peep about it, and his book hadn’t had trouble getting into the store.)
So we re-submitted, hoping that we’d compromised enough to get through the front door. But Steve rejected us again, saying that even the word iPhone was not acceptable in an icon. And he didn’t want to talk about David Pogue’s icon, either. That topic was off limits.
At this point, the person on our staff who had been dealing with Steve suggested that we just continue to compromise, releasing an app whose purpose could not be understood by either its name or its icon. Macworld art director Rob Schultz set about creating a third icon, this one just representing a chunk of the Macworld logo.
Me? I was mad. So I did what I do sometimes (often to my detriment) when I’m mad: I expressed my displeasure publicly. My tweet was picked up and posted to Daring Fireball and Engadget. Some people who know me later said they also wrote to contacts within Apple, asking what the heck was going on.
Two hours after I posted my tweet, out of the blue I got a phone call and an e-mail from someone at Apple, apparently in the app-submission group. (I’d never heard his name before.) What he told me was that he had heard about my situation and that it had all been a mistake on Apple’s part. This gentleman said that it was Apple’s policy to approve apps that were based on existing published works, and that since that was the case with us, they would be happy to approve our app with the original title, “iPhone and iPod touch Superguide.”
But then I asked him about the icon—and he also referred to Apple’s no-trademarks policy for icons. This time, though, he was responsive when I mentioned my example of David Pogue’s book. My new contact told me he’d call me back in a few minutes. When he did call back, he explained that Apple’s policy toward printed material also meant that if we represented our book cover as our icon, our app would be approved. He also asked me to e-mail him as soon as we’d resubmitted our app, and he’d push it through onto the store.
He also said something that really irked me. He suggested—again, perfectly politely—that if we had a problem with our app rejection, we should just reply to the rejection, because app reviewers pay attention and respond to complaints. I had to explain to him that we had entered into a back-and-forth with our reviewer. It just hadn’t helped—it was like talking to a brick wall.
At that point, the gentleman from Apple on the other end of the phone couldn’t do anything but apologize that the system hadn’t worked as it should have. And that’s where we left it.
Just to be sure, I went back to Macworld art director Rob Schultz and asked him to create a fourth app icon, this one showing the entire cover of the book, rather than the simplified version we had created before. We really didn’t want to take any more chances. We re-submitted the app and, within a few hours, it had been approved.
Another black eye
What did I learn from all this? Not a lot, sadly. We've known for a while now that Apple’s submission system can be pretty messed up. We’ve seen versions of this story before with Drivetrain and Eucalyptus and Podcaster and Ninjawords and Tweetie and Slasher and CastCatcher and MailWrangler. The only difference was that this time, it happened to me.
Apple’s insistence on reviewing every single app submitted to the App Store has created a slew of problems. It creates delays, which frustrate developers. Some apps don’t get approved at all, which can create a chilling effect with developers who make a living writing software.
If your app is rejected for good reasons (as our App Gems app was originally, more or less), the system actually works fairly well. But when you run afoul of an app rejector who has decided that there’s some reason your app can’t be approved, you’re completely powerless. If the person you’re dealing with has been given a rulebook and told to follow it to the letter, it’s hard to argue with that person. If they’ve misunderstood something, or don’t know the bigger picture, that’s just too bad. That was our situation. The person we were dealing with was polite as all get-out, but he thought he knew the rules and he wasn’t really interested in listening to what we had to say. He was interested in us following his orders. And there doesn’t really seem to be a way to push a big red button and say, “I need to talk to your manager.”
There are plenty of ways Apple could improve this process. It could train its reviewers/rejectors better, for one. It could perhaps train reviewers in specialized areas of the store, so that someone analyzing book submissions would be well-versed in the rules for book apps, rather than completely oblivious. There are lots of other suggestions that many app developers have made, including the radical suggestion of letting the free market work its magic.
Personally, I think Apple needs to get out of the way as much as it possibly can. The App Store has been a raging success, but developers are still frustrated. The more Apple greases the skids for developers, the happier they’ll be and the stronger the platform will be. Perhaps Apple should loosen its rules and create a feedback mechanism that allows users to flag apps for post-release review, in case they’re bad. Perhaps Apple should green-light “trusted” developers and give them unfettered access to the store, so long as they behave. There are a lot of options. I’d like to see Apple try more of them, rather than just hiring more reviewers until every human remaining on Earth is either an app reviewer or an app developer.
In the meantime, Apple will continue to get beat up by random, embarrassing stories of app rejections. Each one is a small story, but they have a cumulative effect. When Verizon advertises the Droid by saying “iDon’t allow open development,” there’s no doubt what the ad is referring to—it's playing off Apple’s reputation of arbitrarily rejecting apps from the only source where iPhone apps are sold.
I keep hoping Apple will address the issue before it gets its next black eye. Before the bad feelings start seeping through to the general smartphone-buying market, most likely due to aggressive ad campaigns from competitors. But it hasn’t happened yet.