Hear this article read aloud.
The app is finished. It works on every phone in the office, the launch date is on the calendar, and the store listing is written. Then the review comes back with a rejection, a guideline number and two sentences of explanation. A fix takes a day. Getting back to the front of the queue can take longer.
We have shipped about a dozen iPhone and Android apps, for Wave Agency and for clients, and most of the delays we have seen had nothing to do with code. They came from things a reviewer checks that nobody on the project thought to prepare. Here is what Apple and Google actually look at, so you can have the answers ready before you submit.
The app has to be more than a website
Apple’s Guideline 4.2, minimum functionality, rejects apps that are a thin wrapper around a website. If the app is your mobile site in a frame, a reviewer will say so. An app has to do something a mobile site cannot, natively: work with the camera or location, send useful notifications, keep content on the phone, or simply feel built for the device rather than borrowed from the browser.
Guideline 4.3, which Apple calls spam, is the related trap. It flags apps that look like copies of each other or like a template. If you publish several apps for similar businesses, expect detailed questions about who each app is for, what problem it solves, and why it is not part of another app. Answer specifically and honestly. A vague reply tends to bring a second, more pointed question.
If you are still deciding whether you need an app at all, we wrote about that in Should your business have its own app?.
Give the reviewer a way in
A reviewer has to be able to use the app. If it signs people in with a code sent by text or email, the reviewer has no phone number or inbox that will receive it, and the review stops there.
The answer is a demo account that works without a real phone or inbox: a fixed, review-only login that you hand over in the review notes. Build it so it can be switched off later without a new release. While you are writing those notes, explain anything a stranger would not find on their own, such as where a feature lives or why a screen is empty for a new account.
Accounts and other people’s content
Two rules apply to a lot of apps and are easy to miss.
- Account deletion. If people can create an account in the app, they must be able to delete it from inside the app (Guideline 5.1.1(v)). Deletion means deletion, not deactivation, and not an email to support.
- User-generated content. If people can post anything others see, such as comments or posts, Apple expects a way to report content, a way to block other users, a moderation approach and a published contact (Guideline 1.2).
Put directions to both in your review notes. A reviewer who cannot find the delete button will assume there is not one.
The privacy answers must match the app
The App Store’s privacy labels and Google Play’s Data safety form ask what the app collects, why, and whether it is linked to the person or shared. These are statements about your app, made to the people downloading it, and they have to match what the app really does.
They cannot be filled in by guesswork. Work through every screen, every analytics or crash tool, every sign-in method and every service the app talks to, and write down what each one collects before you open the form. If a third-party tool in the app collects something, that counts too.
Build and store details that trip people up
A few technical and store settings cause trouble out of proportion to their size:
- Use a released version of Xcode for the final build. Builds made with a beta version are accepted on TestFlight, so they reach testers and look fine, and then are refused at App Store submission.
- Expect Google Play’s declarations. Play asks about content rating, target audience, ads and data safety, and some categories carry their own, such as a publisher declaration for news apps. Some of these only surface at the moment you try to submit.
- Decide country availability on purpose. An app with no availability set ships worldwide by default, which may not be what you want for a local business or a regulated product.
Taking money inside an app
Payments are where rules matter most, and the general shape is this. Digital goods and subscriptions used inside the app generally must use Apple’s in-app purchase on iPhone and Google Play’s billing on Android. Real-world goods and services, such as event tickets, restaurant orders or a booked appointment, can use your own checkout. Donations to a registered nonprofit fall under their own rules and can generally go through the organization’s own payment page.
The details change, and they depend on where the app is sold, so check the current guidelines for your case before you design the payment flow. Getting this wrong is one of the more expensive rejections, because it can mean rebuilding a checkout.
Plan for review from the start
Most of this is cheap to build in early and expensive to add the week before launch. A short list we keep in front of every project:
- What does this app do that the website cannot?
- How will the reviewer sign in?
- Can a person delete their account and report or block others?
- What does every part of the app collect?
- Which countries, which payments, and which store declarations apply?
App review is also not a one-time event. Every update goes through it again, which we covered in keeping an app alive after launch.
Where we come in
We plan, build and submit iPhone and Android apps with review in mind from the first meeting, and you can read more about how we work on our mobile application development page.
