Re: Apple's Mistake
Chris H.I've been reading a lot of blog posts during the last year about how bad it is that Apple acts as a gatekeeper to the App Store. I don't mean to suggest in this post that Apple's system is without its flaws, but I don't believe the situation is as bad as all these prominent developers make it out to be. I say this both as a user, and as an admittedly inexperienced developer. One thing that is a problem though is that it has taken this long for Apple to address the concerns of the developer community. While I think the individual problems are somewhat overblown, there clearly is a problem. I'm not so sure the solution is so easy as many developers make it out to be though. There are tens of thousands of developers, more than a hundred thousand applications, and tens of millions of users. Any changes have to satisfy lots of paying customers.
There are a number of common threads in all the discussion about how bad it is:
- You can get rejected for no reason whatsoever.
- It takes forever for an application to get approved.
- It is evil of Apple to act as gatekeeper -- regardless of the implementation.
Apple's Mistake?
I've read dozens of posts like Apple's Mistake by Paul Graham. It's well-written and thought out, and the author lays out a case that Apple is really pissing off developers, with some quotes and examples sprinkled throughout.
I'll respond to a couple quotes from his article, and then conclude with some of my own thoughts.
How would Apple like it if when they discovered a serious bug in OS X, instead of releasing a software update immediately, they had to submit their code to an intermediary who sat on it for a month and then rejected it because it contained an icon they didn't like?
It's a bit of a cheat, but my response here is that a patch to fix a serious bug should not include unnecessary new content and code. It should fix the bug, period. This seems like the best way to get through the approval process as well. You have nothing new in your application for Apple to object to. They don't have to spend time verifying new artwork is original, etc. Of course, one reason that a developer might want to bundle updates is that the approval process takes time. Every time you read about something in a blog, they cite these ridiculous large numbers, like 4-8 weeks, for an update to get approved. How many of the 100,000s of app updates have taken more than one week? A hundred? A thousand?
Which means it's a disaster to have long, random delays each time you release a new version.
This brings up point #1: which apps, and which updates take a long time to get approved? Is it really a random process as suggested by Paul? I don't believe that it is. There are always exceptions, but I have to say that most of the apps that are the focus of angry blog posts about Apple's long approval process in some way are pushing the boundary of what's acceptable in the App Store. When you create an application that in any way comes close to violating the terms; e.g. duplicating functionality, using a lot of bandwidth, etc. you are taking a risk! Your app might get rejected outright, and if it's approved, it probably is not handled by the standard approval agents. I can not recall ever reading about some application clearly staying away from the gray areas that Apple has laid out getting rejected or delayed for months. A criticism to my argument here is that Apple is so vague that every application is in a gray area. I just am not outraged that often when I read about a rejection or delay. This could be because of the rejected developers attitude -- they almost never acknowledge that they are in any way doing something Apple could conceivably find objectionable.
As a result of their process, the App Store is full of half-baked applications. I make a new version almost every day that I release to beta users. The version on the App Store feels old and crappy. I'm sure that a lot of developers feel this way: One emotion is "I'm not really proud about what's in the App Store", and it's combined with the emotion "Really, it's Apple's fault."
If the version in the App Store is crappy, it is because this developer submitted a crappy application to Apple. As for it being old, I really just have not seen a lot of evidence that the approval process takes that long. I have heard 7-10 days for new apps, and 3-5 days for updates. Exceptions to this rule that I've read about are almost exclusively applications that are in one of the gray areas above. I suspect that the vast majority of the 100,000 apps in the store got through the process reasonably quickly.
I believe that they think their approval process helps users by ensuring quality. In reality, bugs like ours get through all the time and then it can take 4-8 weeks to get that bug fix approved, leaving users to think that iPhone apps sometimes just don't work. Worse for Apple, these apps work just fine on other platforms that have immediate approval processes.
Again, I just don't believe that 4-8 weeks is the expected time for a bug fix to go through the approval process. If you have multiple examples of cases where bug fixes take this long, leave a comment, and I will have to rethink my position. I have seen one example of this in the real-world. I can't remember the name of the app, but some company submitted an app with a bug in it. They then tried to release a new version, and artwork that they had been using all along caused the application to get rejected. This is one case where Apple really did drop the ball. The bug fix should have gone through immediately, and then they could have argued about the artwork afterword. I still do not believe that this is a common occurrence though. If you are aware of other examples, please leave a link to them in the comments.
The other argument here is that Apple should not act as a gatekeeper at all. I disagree. Have you developers ever read through developer forums? Have you read rejection notices for developers besides the popular ones? There are people doing pretty stupid things in their applications. Things that I certainly don't want any application on my phone doing. I'm glad, as a user, that these mistakes get caught by Apple's people, rather than me. There are examples of popular applications doing stupid things too, not just Joe Schmo doing iPhone development as a hobby. There was the application that transmitted your address book over the network unencrypted, I believe without even warning you it was about to do anything to your address book. While Apple did not catch this during the approval process, they did have a process in place to stop distribution, and who knows what else they have caught? No one is going to write an angry blog post about how their popular application tried to do something very stupid with user data, but Apple put a stop to it.
Alternatives?
Another thing about Paul's article, and others like it, is that no alternative is suggested besides in this case, creating a new platform, which isn't really a fix at all. I will admit that the needs of developers of an application with one million users are different than the needs of a developer satisfying a small niche. What can be done about this to balance allowing indie development, and doing everything possible to ensure a good user experience? A new vendor releasing new hardware is not going to fix the underlying problem.
One fundamental problem here is that developers want to push things as fast as they possibly can to beat the competition. This guy pushing beta builds to users daily? I am not interested in running those on my phone. I have had my phone for 18 months now. I can wait another week, or another two weeks for you to polish your application and do thorough bug testing before you submit it. I'm constantly amazed by some popular applications I use that have gone numerous release cycles during the year I've owned them and still have nasty bugs that have never been properly squashed. Many users and developers are pissed off at Apple because the applications are buggy. The solution is so easy though... stop releasing buggy applications. Okay, so it's not that easy, especially if you are dealing with user generated content and don't know exactly what it will look like. But perhaps we'd all benefit, users and developers alike, if developers would take an extra day and do serious bug hunting rather than push off apps to Apple and fix bugs later.
Reader Comments (3)
I tend to think things are much simpler than other people but here is my summary.
The authorzation process attempts to make things safe and protect the majority of users. Apple made the design of the iPhone intuitive and that makes it awesome and also makes it so that lots of people who aren't devs or even computer inclined can utilize it. OS X is kinda the same principle. Lots of unix power with an intuitive interface. Something Linux is still not fully able to do. Anyways the approval process is just trying to protect the customers and I think it's necissary from their business standpoint. Blackberry had no app store and it was worse. Rogue apps that were crappy as all hell. Blackberry apps didn't have to get approve so noone put time into them and the quality was crap. There couldve been other reasons too. Lack of interest in the device or bad API. I don't know what android does but if it's an open market I'm scared for the phone support company and ignorant users.
The real problem is that developers have been and will always be lazy. They argue about bug fixes and quick iteraions but really, and you said it, they need to release bug free software. We accept that it's not possible and then developers get more lazy. They end up with the attitude that since software will always have bugs and now it's kinda accepted by the community, LET THE USERS TEST THE CODE AND ILL WORK ON MORE FEATURES. It's not just the approval process. It's the fact hat since testing is being done lax, not only do you have approval time, you have the time yo get feedback from users and THEN go through the cylce again. This takes a long time. If we assume that no bugs ever exist, then there is no problem. Release version after version queue each in the approval process and users just suffer from the 1 week delay of approval to have the newest version. That's not bad and it's doable but that's not what's happening. If your app has that many bugs you shouldn't have gotten approved in the first place!
Oh I forgot two things.
If you don't believe devs want users to test software for them, why was gmail bets for a million years?
The other point was that the only options are to open the AppStore to allow eveyonr to submit which I would be really against. Or, make a beta channel where people can install app awaiting approval at their own risk or if they have a developer license themselves. This would at least allow other developers to test the stuff and keep out the average user who has no business taking that risk.
Oh. And the biggest point is that at least you don't have to use some apple specific protocols IN the apps. If this was a microsoft device you'd have to run a windows IIS server just to transfer data and have some other MS specific crap to deal with. As far as I can tell they do a pretty good job of being liberal within means and understandable for a business.
As far as I see it the approval process from a business standpoint is the same as os x having to run on apple hardware. Does anyone recall how hard it is develop for windows? It's a nightmare! Is the zine programmable yet?
Now I'm mad. If you don't like it don't develop on it. I don't want to use your crappy program anyways. Ugh.
Android has a Marketplace and a way to distribute apps via your own website. Perhaps this hybrid approach would work well. There's less risk for users, and more free exposure for smaller developers in the Marketplace, but Facebook, etc. can release their apps on their own presumably at whatever pace they want. The problem is though that I don't think apps in the Android Marketplace are selling very well. I read that one developer at least is pulling out since their iPhone offerings get 400x the downloads. I'm not sure if this is just an extreme case or not.