Creating a mobile app is complicated enough in its own right, but navigating through the App Store Review process can be its own bag of worms.
The Jed Mahonis Group has submitted hundreds of apps to the store, and through that experience, we wanted to share with you some of the lesser-known rules of the store which may lead to your app getting rejected.
If you're looking to build an app for the iPhone or iPad, you need to look through the guidelines yourself. It's true that Apple sometimes reject apps for reasons you could not anticipate up front, but reading through that document should help you understand the types of apps that Apple wants to have on its platform.
Note: the App Store Review Guidelines is an ever-changing document. We wrote this article in August of 2017, so things may have evolved since then.
1.1.7: App Store Reviews: Use the provided API to prompt users to review your app; this functionality allows customers to provide an App Store rating and review without the inconvenience of leaving your app, and we will disallow custom review prompts.
Prompting a user to leave a review inside your app is a contentous topic among UX designers. Apps need to have a strong rating inside the App Store in order to see success, but presenting a box that takes a user out of the flow of their app is annoying. Unfortunately, without nudging your satisfied users in the direction of leaving a review, you are left at the mercy of your dissatisfied users, who often will leave a negative review out of spite.
To combat this problem, Apple recently released a new API which allows developers to use a standardized prompt for reviews. A developer can specify an appropriate time, and then leave it up to the system whether or not to display the prompt. Typically, the system will allow 3 prompts for reviews over the course of a year.
Once prompted, the user can simply tap one of 5 stars to leave the rating and type an optional review, all within the app. Conversely, they can even turn off these prompts altogether.
Takeaway: Custom dialogues for getting a user to leave a rating/review in the App Store are no longer permitted. Use the Apple-provided prompts instead.
1.2 User Generated Content: apps with user-generated content or social networking services must include: - A method for filtering objectionable material from being posted to the app - A mechanism to report offensive content and timely responses to concerns - The ability to block abusive users from the service - Published contact information so users can easily reach you
Apple places a strong emphasis on protecting its users' experience and privacy (as we'll discuss towards the end of this list). If you are building an app which allows users to browse content uploaded from other users (like a social network), Apple expects you to implement a few mechanisms which help protect its users from being harassed or exposed to "objectional material."
From our experience, when conceiving the next great social network, "blocking users" is never a top priority for platform creators. After all, usage is everything, and limiting a user from speech is not condusive to growing as fast as possible.
The minimum moderation tools required by Apple give you the ability to police your platform, but this leads to a broader discussion about the types of conversations your platform will facilitate. Take a look at Twitter: Twitter is notoriously critisised for being hesistant to remove tweets. This leads to an ecosystem that allows racist and sexist comments and threats to thrive. Twitter is absolutely able to actively block hate speech, yet they seem to be unwilling to do so.
As a software owner, you have a responsibility for the platform you are putting out in the world. Giving users the ability to report content and block offensive people is the table stakes for playing the game, but one of the unsexy sides of app development is the moderation you'll be required to do to keep your platform healthy and positive for everyone.
Takeaway: If you are building a social network, consider the ways in which trolls can overtake your platform. At a minimum, Apple requires you to give users the tools to help you combat the garbage.
2.2 Beta Testing: Note, however, that apps using TestFlight cannot be distributed to testers in exchange for compensation of any kind, including as a reward for crowd-sourced funding.
Kickstarting an app project is not as popular as it once was, but it is still one possible way to raise money to get software developed. One recent notable example is Iconfactory's Twitter interface for the Mac.
If you want to reward people for backing your project by inviting your users into your Testflight beta for early access to your platform, Apple is explicitly saying here that you are out of luck. You will need to find a different way to reward your users.
Takeaway: If you use Kickstarter or another crowd-funding platform, you can't use TestFlight as a way to reward your backers.
2.5.4 Software Requirements: Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. If your app uses location background mode, include a reminder that doing so may dramatically decrease battery life.
When multitasking was first introduced in iOS, it provided a limited scope of apps with the ability to do tasks in the background. Essentially, if your app didn't play music in the background or provide turn-by-turn navigation, you were not allowed to function in the background.
Clever (dare I say, nefarious?) developers attempted to use these background modes in unintended ways in order to give their app the opportunity to stay alive indefinitely. Facebook, for example, claims they made an honest mistake when they were caught playing a silent audio clip in the background to keep their app alive and running.
With this App Store Guideline, Apple is saying that they provide background services to accomplish specific tasks, and if you use those background services in an unintended way, you may face a rejection.
In addition, if you keep track of a user's location in the background, you need to keep a reminder in the app store's description stating that your app will make their phone die sooner. We've forgotten this provision in the past and have been rejected as a result.
Takeaway: Only use background services if you are gonna use them for their intended purpose. If you use background location services, put a note in your App Store description stating that using the app may lead to decreased battery life.
4.2.6 Minimum Functionality: Apps created from a commercialized template or app generation service will be rejected.
This rule, admittedly, is one which benefits our mobile app consultancy. Regardless, we believe it benefits the app ecosystem as a whole, and is worthy of a special callout in this post.
There is certainly a time and a place for templated software. In the world of web development, platforms like Wordpress allow you to take a skeleton of various blog components and apply a skin in the form of a template. This lets you get your website running quickly and securely while maintaining a professional appearance.
The world of app development, however, functions a little differently. Instead of an entire skeleton you can use to get an app up and running, we have what one might call the "internal organs" of an app (things like table views, cameras, push notifications, etc.).
You can't just take a couple of those internal organs, toss them into an app, and ship it. With more than 2 million apps currently available in the App Store, you need to find a way to stand apart. Using an app generation service to build an app is not going to help.
In our experience, most people who use an app generation service or app template don't really need a mobile app at all. Most people only use 9 apps in a given day. If your app is just a template, will your customers really be using that over apps like Facebook or Buzzfeed?
If your app is essentially just your website, make it easier on your customers and just make your website responsive. That way, customers don't need to install another app just to get content, and you won't need to spend a bunch of money developing a mobile app.
Takeaway: If you are considering using an app generation service to build an app, consider building a responsive website instead.
5.1.1 Data Collection and Storage: (ii) If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law.
A few years ago, it was commonplace for everyone to ask us to "just throw a Facebook login in" a new app scope. The reasoning was sound on their part: signing into Facebook gives you access to a user's private information, which, as we'll discuss below, is a huge goldmine.
Apple recognized this and started asking a farily obvious question: why are these apps forcing users to log in when the vast majority of the app could be used without doing so?
Takeaway: If your app doesn't really need users to log in, remove that feature.
5.1.2 Data Use and Sharing: (i) You may not attempt, facilitate, or encourage others to identify users or reconstruct user profiles based on data that you say has been collected in an "anonymized", "aggregated", or otherwise non-identifiable way. You may not use or transmit someone’s personal data without first obtaining their permission and providing access to information about how and where the data will be used.
We've been saying for years that as the smartphone revolution continues, users will incresingly become aware of the immence value of the data automatically generated by their phone.
While a reasonable person may have a hunch that having their location tracked at all times could be concerning, they may also share the belief that "if I have nothing to hide, why worry about privacy?" Users constantly trade their location data for access to "free" services like Google Maps and Facebook.
Personally, until I became a mobile app developer, I was in the same camp. For millenia, unless you had someone walking with you at all times with a pen and paper, there was no way you could track a person's movement throughout a day. And even if someone did take the time to collect all that data, it would take forever to synthesize that information into something useful.
However, with smartphones and the servers which power their backends, that synthesis can happen faster than you can snap your fingers. Actually, it can happen before your brain can even fire the synapses in your mind to even contemplate snapping your fingers. All that data can lead to insights and patterns about you that even you aren't aware of.
Privacy will continue to be a topic of concern throughout the early 21st century, especially as smartphone technology becomes faster and more embedded in our lives. You, as an app producer, have the obligation to act as a steward of your user's privacy and create value for your users with their data, and not just have that data create value for you in the form of advertising dollars.
Apple uses section 5.1.2 to make that obligation even more compulsory. You can't just take your customer's data and do whatever you want with it without telling your customer what you're going to do with that data.
Takeaway: Treat user's data with respect, let a user know how you're going to use that data, and only use that data when it provides the user with value.
As a mobile app development company, it is our job to help you navigate the confusing world of App Review. If you have any questions about whether your app may be subject to an App Review rejection, contact us today and we'd be happy to help!