How to Get Your iPhone App Approved by the iTunes Store

By John Houghton on January 8, 2014

One of the most vexing parts of publishing an iPhone app is getting it approved by the iTunes store.  It can take a week or longer, and many first-time or unprepared developers get their apps rejected.  My collective team and I have submitted and received approval for dozens of iOS (iPhone/iPad/iPod) apps, and we would like to tell you about our experiences.  The Apple approval process is actually good for you and your users.  For you to successfully get your app through this process means that you get Apple’s seal of approval, and have permission to sit with what is right now the world’s top brand.  Here are the most important tips for getting into the store.

Start Early.  First of all, you have to know that you need to start early if you have a deadline.  It’s best to submit your minimum viable product when it’s available, and then work up to your main release, versus submitting your final release a week before your deadline.  I’ve seen apps submitted 6 weeks before an event (this was an app for a specific event), only to be rejected and resubmitted twice, which ended up with the app being released a month after the event.  It’s a little unusual for an app to take two and a half months to get through the process, but it’s not unheard of.  Success depends mostly on the team member who is submitting it.  In this case they were inexperienced, didn’t read the documentation (although there is a lot to read), nor follow instructions, so the app that was designed for an event, missed the event.  You have to think somebody lost their job over that one.

No Exceptions.  Even if you’re famous, Apple is not concerned with who you are, and they’re not going to make an exception for you.  Maybe you’re the SVP of Mobile for a Fortune 10 company, or you’re Madonna; it isn’t going to get you any special favors from Apple.  (See the story at the end of this article.)  Nearly everybody who is important has an app, and Apple deals with VIPs every day.  You will be treated the same way as everybody else, and overall their treatment is pretty fair.  They are not going to change their processes just for you, grant your app an exception, or give you a special phone call that’s outside of their stated normal procedures.  Even if you have a multi-million dollar app for an event such as the Olympics and you’re on the Olympic committee, they won’t go outside of their processes and provide special approval for your Olympics app.  You can learn about these processes by reading the iTunes Connect Guide.  It tells you all about how to work within the parameters of the app submission process, as well as other pertinent information you’ll need around release time.

Stay Within the Guidelines.  The other important thing to consider is whether your app violates Apple’s policies.  This is why its a good idea to submit your minimum viable product (MVP) early, so you don’t invest as much time perfecting an app that can’t be released.  Apple has many restrictions on the types of apps that can be hosted on the Apple store, as well as rules regarding the content (text, images, video, audio) that an app might contain.  Many types of apps are simply not allowed.  Registered iOS developers can find out more by logging into their developer account and reading the App Store Review Guidelines, which is relatively clear about what is and is not allowed.  Perhaps a third of the app ideas that people tell me about are not viable on iOS because they violate some of Apple’s guidelines.  The guidelines aren’t arbitrary or excessive in my experience, and there is a usually a good reason for them.  I’ve seen entire apps go through months of development, only to find out they were not allowed in the store.

Make it Good.  I was once privy to an instance where an app was under review and rejected in two minutes.  If an app can be rejected in 2 minutes, how many apps can this person be looking at each day?  If he or she works an 8-hour day, that means they can theoretically look at as many as 240 apps a day.  Can you imagine how many bad apps they have to look at every day?  Many of them must be terrible (just look at the average app on Google Play where they don’t have an approval process).  Because the Apple reviewer didn’t understand this app by looking at it, they quickly rejected it.  They didn’t take the time to read any of the supplied documentation, where considerable effort was spent clearly explaining exactly what the app does.

The lesson here is that if your app looks similar to other apps they reject, they are not going to read anything you have written and you aren’t going to stand a chance.  Your app needs to look like it fits on an Apple device.  For more information see our article on How to Design an iPhone UI.  Yes, you can be rejected for having an unsightly app.  It has to be well-designed, have strong graphics, be tested thoroughly, serve a functional purpose, as well as delight the user.  Good design looks easy, but it takes a lot of work to achieve it.  Take the example of an Olympic athlete.  They make it look so easy, but in reality you are seeing the result of a great deal of time and work.  One important document you need to read is the iOS Human Interface Guidelines.  Following these guidelines when designing and developing your app will help make your app look like it belongs on an Apple device.

Make it Useful.  Your app must be useful.  If your app could just as easily be a static website, it will likely be rejected.  A lot of developers want to make business card apps, where the app is nothing much beyond a mere business card with an app icon.  It looks cool to the developer and her friends, but Apple won’t allow this on the iTunes store (it might be fine, however, in Google Play).  You could make an app that is essentially a high-quality brochure for your products and services, as long as it uses the unique capabilities that an app provides, such as the ability to download fresh new videos on a periodic basis, or present other types of dynamic content.

Don’t Cite Existing Apps.  After a rejection, arguing to the reviewer that there is another approved app already on the store that has the same behavior or issue as yours is not an effective strategy.  All that matters are the policies, and you must abide by their policies and procedures just like everybody else (the other app may have been approved before this certain policy was in place).  I hear this rationale a lot when different folks try justifying design decisions, and the same logic applies.  Just because you see it on the iTunes store, doesn’t mean it’s an example of good design.  There are many apps on the store with poor design.  Some of them are popular apps, and they have made it despite their design flaws.

Good Code.  Make sure your app is technically well-designed and coded.  Apple can reject your app if your technical house is not in order, or if you’re using the wrong APIs to achieve various tasks in the app.  That being said, it can be quite a long process if a customer calls us with an already-developed app and they want it submitted to the iTunes Store.  If the developers have done a great job, then the process will be quick, but if a lot of things need to be fixed, then we need the time to fix those things, which sometimes can take weeks or longer.  One file that needs special attention is the info.plist file.  This file stores the settings, configurations, and device requirements for the app.  There are potentially hundreds of settings, and this is not a place for novice developers to experiment.

You might wonder where these Apple app reviewers sit?  These folks are at Apple in the San Francisco Bay Area.  I know a guy who is responsible for release management for a successful social company that has a top app.  One of his employees was having a beer in San Francisco and actually met the guy who approved his app (which had been rejected in the past).  He asked, “Can’t we coordinate a little bit or at least talk on the phone?  We’ve been one of the most popular apps on the store for a while now.”  In the end, the Apple guy was nice, but my friend’s employee couldn’t get any additional cooperation.

Posted in App Development, iOS Apps, iPad Apps, iPhone Apps, Mobile Apps

Comments

Comments