Dealing with Apple’s App Review What we learned from more than 1.000+ successful app submissions

Apple has long been famous for their rigorous app review process, and even Google increased their efforts to review apps to keep spam and malware from Google Play. There are many misconceptions what a rejection actually means. So much so, in fact, that some indie and small developers take a rejection as the final verdict on their work and choose to ditch their project altogether.

Given AppManager’s track record – of helping our clients publish 1000+ apps on the App Store in 2019 alone (and many more updates) – we are sharing the most common reasons for rejections, how to resolve issues in advance, and how to prepare for Apple’s review team.

AppManager’s background

Our customers range from small start-ups with new app ideas to huge enterprises with new mobile offerings for their existing services. Even though 60-70% were rejected following their first submission, we managed to get 98.5% of them into the App Store.

General strategy

The general strategy we recommend is: (1) persistence, (2) not taking criticisms or reviewer responses personally, and (3) being friendly and open to feedback.
Consider how you would feel after spending your entire day reviewing endless apps, only to get a snappy reply from a developer? If your imagination isn’t enough, just head over to glassdoor.com and check out the job reviews.

Having said that, you may be wondering what I mean by “persistence.” Don’t give up after the first or even third rejection. Ask questions if you are not sure what a reviewer is trying to convey. In many cases, rejections are generic so try to politely “force” them to pinpoint the main problems. We’ve seen some issues magically go away after having enough information to make a clear case and strategic improvements.

Above all, maintain professionalism and use a friendly tone of voice when communicating with your app reviewer.

Most common rejections and how to avoid/resolve them

2.1 App Completeness

Issue: Your app has a login functionality and either the credentials are incomplete, incorrect or missing.

Solution: Provide credentials that are current and that function throughout the entire app review process. Be considerate to your reviewer by avoiding long and complex logins and passwords. Provide a test/demo account that has some meaningful data. If you have 2-step logins, non-traditional logins, or custom flows, then include that information in the review notes.


2.3 Accurate Metadata

Issue: There’s something wrong with your metadata, usually the screenshots or any text either in the store descriptions or the app itself. Most of the time we’ve seen this as a reference to other app stores – hi there Google Play 👋!

Solution: Make sure to take screenshots on the correct devices and with Apple hardware/simulators. Use the right device frames for the correct screenshot category. Be creative, but don’t “overextend” and promote too much in the screenshots. When it comes to metadata and text, do not mention Android or other stores if it is not absolutely necessary (e.g. developer tools). Don’t use the wrong product names or mention bugs with Apple’s software.

For a more complete list, check out precheck from fastlane.


3.1.1 In-App Purchases

Issue: You’re trying to sell access to digital products and services and do not use Apple’s in-app purchase mechanism.

Solution: The rule is simple: Any digital products and services (e-books, videos, music) sold in your apps have to go through Apple’s in-app purchase gateway and you have to pay the 30% “Apple tax”, like it or not. Anything remotely physical (books, DVDs, taxi rides) must not use in-app purchases and you are free to implement your own payment system (Stripe, PayPal etc.). There’s no real discussion on that.

The only way around the “Apple tax” is to only provide access to (previously) purchased content (read: Audible, Netflix or Prime Video). However, this will put you in the awkward position of having to tell your app users how they can access/purchase new content, because you cannot simply link to the browser or write in “too direct terms” how to do it. For instance, Prime Video uses the following lingo: “Unable for purchase on this device: In-app purchases are not allowed on this device. You can watch videos, which you previously purchased or rented on Amazon.”


3.1.5 (b) Cryptocurrencies

Issue: Cryptocurrency-related issues are typically complex and require individual review. Most of the time they are related to: (a) being primarily an affiliate (iii), or (b) offering trading or ICO access (iv).

Solution: Not surprisingly, with all the hype around cryptocurrencies in the last few years, we’ve seen many new apps enter this space. Apple has a relatively conservative and regulated approach to these apps (and to financial apps generally, for that matter). Their policies require offerings from an established bank, security firm, futures commission merchant, or another approved financial institution.

Based on our experience, most reviewers cast a pretty wide net and simply reject most crypto apps with the 3.1.5(b) (iv) clause, even though no actual trading or transactions were happening in the app. Though we can only speculate about the reasoning behind this, Apple’s legal team likely thought the expansive requirements would spook sketchy publishers.

If you work within the cryptocurrency space, your best bet is to go the extra mile to explain what your app does. Bear in mind that Apple might require additional legal paperwork, depending on your country of origin.


4.1/4.2 Copycats / Minimum Functionality

Issue: Your app is either not very original (4.1) in the eye of the reviewer, or it provides a limited (read: less than average) user experience (4.2).

Solution: We’ve seen this to be the number one guideline for app rejection. Highly vague and subjective, clause 4.1 offers reviewers a lot of room for interpretation. The same can be said for 4.2, albeit this bears on the actual user experience within the app. On a personal note, I take issue with clause 4.1, because even though it should only be invoked to prevent rip-offs, I’ve seen it used countless times to simply shut down a new app.

Again, persistence is key. Try to find the elements that make your app stand out and show that you are responding to a different pain point than other developers. When it comes to clause 4.2, ensure your app is easy to use, intuitive, and looks great (across all devices). To avoid overcomplicated interfaces that are not mobile-friendly, test your app on real devices. After all, Apple cares most about the end user’s experience – not the technologies used to provide it (e.g., native vs. hybrid vs. web).

If you are working on a niche app, tell the app reviewer about your customers, provide a use case, and highlight the value you are providing. Granted, this can require a lot of back and forth, but it’s definitely worth it and also might give you some great insights and feedback on how to improve your app.


4.2.6 Commercialized template

Issue: Your app uses (licensed) code from a 3rd party and/or is not directly published through the licensee’s developer account.

Solution: This is another clause we’ve seen used quite “proactively” in the wild, but it can mean a few things:

  1. You are using a commercialized template (which is fine), but the app seems to be published through the developer account of the party providing the template. This was possible a few years ago, but Apple (and also Google for that matter) now prefer the actual “content owner” to publish the app through their own developer account. In the end, Apple probably wants it to be clear to the customer who is actually “providing” the app.
  2. You are using a commercialized template and are trying to publish the app through a personal developer account. Sounds like the same issue as above, but there’s a small difference: If you want to publish any app for your company and the company is incorporated (LLC, Inc, S.a.r.l, Ltd., AG etc.) you must get a company account. This requires you to get a DUNS number which costs the same as an individual developer account and comes with many more useful features, like an actual team management, so it’s definitely worth it.
  3. If the app is a single binary that hosts all client content or a “picker” model, it needs to be submitted through the licensor’s developer account.

5.1 Privacy

Issue: Your app violates some of Apple’s privacy-related guidelines. Check out the screenshots app review usually attached to your ticket for the specific screen, interaction or similar.

Solution: Since Apple takes a consumer-friendly approach to privacy and publicly advocates for that, it’s no wonder that they take third-party apps seriously.

In this domain, one of the most common rejections we’ve seen is that purpose strings are too generic, i.e., the brief text users are presented with to gain access to their location, camera, microphone, or similar. Be as specific as possible for sentences like: “App name needs access to your location to customize your app experience.” Show that you value your end user’s privacy decisions by providing a clear privacy policy.

5.3 Gaming, Gambling, and Lotteries

Issue: Your app provides (unlimited) access to age-restricted gaming, gambling, betting and/or lotteries.

Solution: It should be fairly obvious that you need a valid gambling permit to provide such services, even in an app format. In most cases, we’ve also seen a “two way” location restriction being required from Apple that: (1) allows only permitted countries at App Store Connect, and (2) has a mechanism in the app that checks whether the user is within the permitted country.

tl;dr

Even though it can be frustrating, the reviewer’s primary goal is to protect Apple’s customers from bad experiences and harm. Reviewers are just doing their jobs and following internal policies and guidelines when they reject apps.

The App Store review protects Apple and their customers – Keep in mind that while the Apple ecosystem provides a great opportunity for other companies, the primary goal of their guidelines is to keep low quality and untrustworthy apps from entering the App Store.

Complaining publicly doesn’t help – Work with reviewers. Treat them like human beings and understand they must follow Apple’s guidelines. Be persistent. If you’re not getting anywhere with the reviewer, escalate to a supervisor or the app review team.

Don’t compare your app to another one with the same functionality – Apps are judged on a “case-by-case” basis. Convey what makes your app stand out or how it solves a problem differently.

Document everything – It helps to have every “black on white” documented at the resolution center. Phone conversations with a reviewer (who may not be the one who actually reviewed your app and issued a rejection) nearly always consist of them simply reading you the rejection text rather than clarifying the situation or offering an explanation.

Be persistent – Be as constructive and cooperative as possible. Don’t get too worked up with feedback from the app review. Keep the conversation going. Most issues can get resolved.

While the app review process is a necessary evil for many developers and publishers, if you remain as constructive and cooperative as possible most issues can be resolved. Undeniably, Apple’s ecosystem is a great opportunity for companies to reach millions of new customers, so keep the conversation going and hopefully you can join our 1000+ clients on the App Store.