Risk Management in iPhone Projects

Let’s be frank: it’s not the best time to be an iPhone developer right now. In just one year of existence, the App Store seems to have evolved from the hottest to the lamest status, without any time to breathe in the middle, but with some warning signs every so often.

Several iPhone developers have publicly stated their opposition to the Google Voice fiasco (starting with Riverturn themselves, the developers of the application), and many have simply stopped creating iPhone OS applications altogether; just to name a few, Fraser Speirs, Steven Frank and Andrew Wulf have publicly stated that they don’t want to deal with the App Store process anymore. And I’m sure that there are many more developers evaluating this very possibility out there; when you have Om Malik or Michael Arrington bashing the iPhone, it sure creates a lot of buzz and uncertainty in the market.

However, and this is my official position, even if I do not agree with the current App Store policies, I’m not quitting the iPhone OS platform anytime soon. I’ll build more applications for the iPhone in the future – heck, I’ve got 2 already approved and 3 more on the approval process pipeline, with at least 3 more in the development phase. My plan, and what this article is about, is about managing the risk represented by Apple in this business. It might be hard, but it’s not impossible, no matter what others say.

NOTE: I’m not a lawyer, so take this advice as it is, and check with your attorney before taking any important business decision. I will not take responsibility for any business or financial loss, application rejection or removal that will arise, directly or indirectly, for following these guidelines. Use this information at your own risk.

The advice in this article applies mostly to consulting firms and independent consultants; obviously, if you develop your own products, you are the only one to hold the responsibility (and the only one to reap the benefits). Nevertheless, in the case of consulting, or when developing custom iPhone applications, you should shield yourself from the risk represented by Apple – and yes, I mean and stress the use of the word “risk” here.

In concrete terms, whatever your application does, there is a certain (relative) risk of being rejected or removed from the App Store by Apple, with or without valid reasons, in almost a random fashion. Being pessimist from the very beginning leaves you with the possibility of having a nice surprise later! If you work in consulting contracts, you must know, evaluate, and take this risk into account while doing estimations and contract negociations; the basis of this reasoning is that if your clients’ applications have a certain degree of risk of being rejected, you must not be held liable in that case. Finally, you must do whatever you can to avoid your application from being rejected; this is your obligation, and the only means you have to increase your chances of selling your applications through the App Store.

iPhone software development is a highly risky activity: consistent project management practices, human resource management, prototyping, education, quality management, memory management, code organization, keeping an eye on compiler warnings, all these factors help reduce the risk of having your project enter the dreadful CHAOS statistics. However, Apple’s own politics regarding the App Store introduce a new level of risk into your project, unforeseen and, unfortunately, hard (but not impossible) to manage.

Explain the risks to the customer

Your customer must know about the App Store review process and all of its quirks. This is a reality. She might not need all the details, because more often than not, customers want an iPhone application just because “they have to be there”, without caring that much about the latest geek details about the App Store rejection policies. But they must at least know the following facts:

1. Depending on its features, an application might not be accepted in the App Store at all; some reasons for rejection are known, but the most important thing to know is that “Apple reserves the right, in its sole discretion, to reject an application for any reason”, including, but not limited to, the (bad) mood of the reviewer.
2. Moreover, even if it has been approved in the App Store, and even if it has been already sold to some customers, Apple reserves the right, in its sole discretion, to remove an application from the App Store at any time. Boom.

As incredible as they might sound, your customer must know these facts, and you must keep a written track stating that your client acknowledges these facts, before the project starts. It’s their risk, not yours; if once they acknowledge all of these factors, they still want their iPhone application, they will have to take care of this risk, and you shouldn’t be taken as responsible for any problem caused by Apple.

I can’t stress this enough: as always, keep a written track of the acknowledgement of these facts by the client, stating explicitly that you, as a developer, cannot be held responsible by arbitrary rejections not based in explicit facts. This means that if the rejection is due to non-respect of the UI guidelines, then yes, you must solve the problem as part of the warranty; but if the rejection is due to non-specified reasons, then it’s not your responsibility at all.

Reading a draft of this article, Stephan Burlot made an interesting comment about this particular point: if you go to your customer and tell him, just like that, “your app might never see the light of the App Store”, you can be pretty sure he’ll just run away, and hire another developer who will keep some of this truth away from his eyes, at least to get the contract. So the important thing here is to be professional and keep an eye on the most obvious factors that make Apple angry:

• Telephony services
• Porn and erotic content
• Exchange of music
• Access to the local music libraries of the device

Release dates cannot be guaranteed

Even if Apple acknowledges that 9 out of 10 applications are nowadays approved in about two weeks (the incubation time is apparently increasing), you can never be sure of the date when you will receive the nice “your app is ready for sale” e-mail.

Remember Schrödinger’s cat? Well, there’s a bit of randomness in the date in which your application will be approved (if that ever happens at all), which means that you must not commit to a defined application release date in your development contract. Hence, when submitting your app, select a date at least 1 or 1.5 months in the future, and begin your marketing efforts as soon as the application is “ready for sale” in iTunes Connect. You can change the release date once your application has been approved.

Reduce the chances for rejection

Closely follow Apple’s own iPhone Human Interface guidelines for your applications, use some common iPhone UI patterns, avoid known UI design mistakes, and finally check out the App Rejected and Application Submission Feedback sites, and use the information as checklists for your applications, in order to verify as much as possible before submitting them to the App Store. Make this a part of your quality management process, at the very end of the development cycle.

Apple also published some interesting tips last week, which can be considered as “official” guidelines, even if I think that the information in the App Rejected and App Submission Feedback sites is (at the time of this writing) incomparably better.

Conclusion

To summarize: I (like many others) still believe in this platform. And I believe Apple will slowly remove some of the cruft from all of the process and make it more transparent.

Moreover, the risk exists, that Apple’s review team stands between you and the App Store; but even so, this risk is highly relative and manageable: at the time of this writing, there are over 63'000 apps already approved, and in July 2009 alone, 7'600 applications have been approved! So chances are, many, many apps will still be approved, and yours has a large, large chance of getting into the party soon.

Interestingly, in June 2009, 9'887 apps have been approved, while 10'203 have been submitted; this means that only 3% of the applications submitted were rejected… that leaves a 97% of approved applications! Even more important: the rate of rejected apps seems to have a negative slope (both in absolute and relative figures)!

(Data derived from 148apps.biz: app submissions and total app count)

Hope this helps! As I said above, I am not a lawyer, so all of this information is based in my own experience, working as an iPhone development consultant for over a year now. Feel free to add your own experiences in the comments section below, so that all of us can benefit from it.

Acknowledgements

Thanks to Stephan Burlot for reading and commenting drafts of this article!

Update, 2009-08-03: Don’t miss this brilliant MacWorld article about the current evolution of the issue.

Update, 2009-08-04: Just found some more tips to avoid application rejection (including a second part).

Update, 2009-11-28: A new site is tracking down application rejections: http://apprejections.com/ (apparently http://www.apprejected.com/ does not work anymore).