Chapters
Chapters

Chapters

Hide chapters

iOS App Distribution & Best Practices

First Edition · iOS 14.4 · Swift 5.3 · Xcode 12.4

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: iOS App Distribution & Best Practices

Section 1: 17 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 2 chapters
Show chapters Hide chapters

7. Preparing for App Review
Written by Pietro Rea & Keegan Rush

Getting through App Review is one of the most confusing and stressful things about publishing an app to the App Store. Even a decade later, App Review continues to be shrouded in mystery. Apple is prolific about how to pass App Review but publishes almost nothing about what it is.

Here’s what we do know: Apple hires and trains employees whose main responsibility is to review incoming app submissions. These reviewers make sure submissions adhere to the App Store Review Guidelines. If something falls in a gray area, which is not uncommon, they make a judgment call. App Review also includes automated checks to catch things that would be hard for a human to detect, such as the use of private APIs.

If you do get slapped with a rejection, you can use the Resolution Center in App Store Connect to work it out with Apple. If you have broader disagreements with the guidelines, you can also make an appeal to the App Review Board.

It’s difficult to internalize all the guidelines you need to follow. App Review is based on long documents that change frequently and are sometimes hard to understand. The good news is that you don’t have to be an expert. Understanding the guiding principles behind them can help you sail through App Review, even as the specific guidelines evolve over time.

Apple doesn’t publish its guiding principles, so the following comes from real-world experience and a close reading of the guidelines:

  1. Provide value: Apps need to be useful, unique and provide lasting value. Apple won’t accept your app if it’s simply a wrapper around a static website. You might also run into trouble if you’re building an app in a category that’s already saturated — think flashlight apps — without adding anything new.
  2. Ensure quality: App Review rejects apps that crash, don’t work correctly or look incomplete. All metadata must include fully-functional URLs. Scrub all placeholder content, like “Lorem Ipsum”, and stock images. Also, make sure you keep up with the latest SDKs and platform requirements. From time to time, Apple purges old apps that don’t work anymore from the App Store.
  3. Don’t cheat: Don’t try to circumvent or cheat the App Review process. Use Apple’s platform capabilities in the way Apple intended. If you do get creative, don’t do it maliciously. Don’t take advantage of users, harm them or profit from them unfairly.
  4. Respect users: Beyond the mandate not to cheat or harm your users, Apple also wants you to respect their data and privacy. Properly ask for permission when requesting sensitive information. Assume they don’t want to see offensive or questionable content. Don’t track them if you don’t need to. Be extra careful if you build apps for kids.
  5. Assume full responsibility: You’re responsible for everything that happens in your app, even if it’s driven by back-end systems or third parties. As an example, if you show user-generated content, Apple expects you to provide some measure of content moderation. Ensure that all software frameworks and dependencies also adhere to the App Store Review Guidelines.

At the end of the day, Apple wants the App Store to be a safe and healthy ecosystem. Apple wants users to feel safe as they discover and download any of the nearly two million apps in its App Store catalog. Doing so keeps users coming back, which benefits Apple as well as third-party developers (that’s you!).

Following the App Store Review Guidelines

The guiding principles mentioned above help you understand the guidelines and anticipate changes, but they can only take you so far. Sometimes you can’t predict what Apple’s guidelines have to say about your particular use case. The only way to find out is to read them.

For example, did you know that you cannot use Location Services to control an aircraft?

5.1.5 Location Services

“Location-based APIs shouldn’t be used to provide emergency services or autonomous control over vehicles, aircraft, and other devices, except for small devices such as lightweight drones and toys, or remote control car alarm systems, etc.”

However, most developers have never read the App Store Review Guidelines. When most people think about them, they picture a dense legal document. That’s not the case at all. They’re written in plain, easy-to-understand language. Sometimes the language is so direct it’s funny. For example, here’s what Apple has to say about non-essential apps:

4.3 Spam

“… the App Store has enough fart, burp, flashlight, fortune telling, dating, and Kama Sutra apps, etc. already. We will reject these apps unless they provide a unique, high-quality experience.”

If you’re in the business of making apps, particularly if you decide what to make, it behooves you to read the App Store Review Guidelines. That gives you an intuition about what’s possible on Apple’s platforms.

You should also read the guidelines if you plan on doing something that no one’s ever done before on the App Store. Before you invest time and money into a project, wouldn’t you like to know in advance if Apple will accept your app?

Unfortunately, Apple never gives you pre-approval. They tell you to develop your app and submit it for review. A close reading of the App Store Review Guidelines is your only recourse if you want to do something radically different.

Reading the guidelines

The App Store Review Guidelines contain the bulk of the information you need to know, but it also links to a handful of other documents. There seem to be guidelines for everything. Some tell you what you shouldn’t do, while others amount to gentler recommendations about how you should build your app. Here’s a list of the most important documents:

App Store Review Guidelines

https://apple.co/36hVYg4

This document is the holy grail for all App Review questions. The structure of the document gives you an idea of the breadth and reach of App Review. There are five big sections: Safety, Performance, Business, Design and Legal. Apple also provides guidance about what to do before and after you submit to App Review.

Apple Developer Program License Agreement

https://apple.co/36iA78f

You accepted the license agreement when you joined the Apple Developer Program. The license agreement covers more ground than just App Review. The sections that deal with App Review often include more details than the review guidelines themselves. The license agreement reads more like a legal document, but it’s accessible even if you’re not a lawyer.

Human Interface Guidelines

https://apple.co/3jfeSYS

The App Store Review Guidelines and the license agreement largely outline what you shouldn’t do. The Human Interface Guidelines (HIG) tell you how you should build your apps. Apple’s HIG contains everything from abstract design themes, like clarity, deference and depth for iOS, to concrete advice on how to use UI controls.

In the past, Apple was more likely to reject apps for violating the HIG but, anecdotally, it’s not as common anymore. Unless your app is completely unusable, you have some leeway on product design. Everyone making apps for Apple’s platforms should also read the HIG at least once.

Brand and Marketing Guidelines

How you market your app is mostly up to you, except when it comes to Apple’s brands and products. Apple publishes guidelines for using its brand, trademark and products in your marketing materials, such as your website and emails. There are also marketing guidelines specific to Apple Pay and Apple Wallet.

Apple won’t search through your website and emails looking for violations. However, if you deviate from Apple’s marketing guidelines in your App Store Connect screenshots or inside the app itself, you run the risk of getting a rejection.

Submitting to App Review

Chapter 3, “Submitting Your First App for Review”, walks you through how to submit an app for review once you have a build and app record in App Store Connect. Refer to it if you need a refresher on the basics.

This section covers more advanced options that the earlier chapter didn’t have space to cover. Before moving on, make sure you’re familiar with this diagram from that chapter:

An app submission contains several parts: app-level information (left box), version-level information and a build (right box). Another way to say it is that App Review’s jurisdiction includes both the actual app and all the metadata that comes with it.

Any piece of your submission can hold up the entire submission. For example, even if your app is perfectly compliant, a single screenshot in App Store Connect can be grounds for rejection.

The rest of this section is an overview of the advanced options you can set on your app submission. Apple only lets you change many of them when you submit an update for review. These are all options that affect the outcome of App Review or how you release the app afterward. As such, there’s no sample project to follow along with.

Add-ons

An iOS app can be associated with a macOS app, tvOS app or watchOS app, as well as an App Clip, iMessage app and one or more In-App Purchases. Apple has guidelines for all of these add-ons, so you can only start offering them after going through App Review.

You can use the same App ID from your iOS app to publish a macOS or tvOS app. Even though apps for different platforms can share the same App ID, you must submit each platform-specific app separately.

Note: Even though Apple sometimes refers to iPadOS as a separate platform from iOS, iPad apps and iOS apps are bundled into a single, universal binary that you submit to App Review. Reviewers review your iPhone app and your iPad app at the same time.

To add another platform in App Store Connect, go to your app record page. In the sidebar, click Add macOS App or Add tvOS App, depending on what you need.

An iOS app may also contain an App Clip, an iMessage app and a watchOS app. From a code perspective, these are additional build targets that you ship alongside the main app’s target. Unlike macOS and tvOS companion apps, you don’t need separate builds to support them. These additional targets come bundled in the iOS build that you upload to App Store Connect.

If you do ship an App Clip, iMessage app or watchOS app, you must fill the corresponding sections on your app’s version page in App Store Connect.

Refer to Apple’s documentation for more information about submitting an App Clip, watchOS app or iMessage app with your iOS app.

Lastly, you can offer In-App Purchases (IAPs) in your app. IAPs allow your customers to buy additional digital content inside your app. You can use four types of IAP: consumables, non-consumables, auto-renewable subscriptions and non-renewing subscriptions.

You first have to create each IAP in App Store Connect. To do so, go to your app record page. In the sidebar, under In-App Purchases, click Manage. Click + to get started.

There’s a review process for each IAP you offer your customers. If you’re submitting your first IAP, you must submit it alongside a new version of your app. After the first one, Apple reviews IAPs separate from the full App Review process.

In-App Purchase is a large topic. Creating them in App Store Connect, integrating your app with the StoreKit framework and testing IAPs all take special consideration. Refer to Apple’s documentation to learn more:

App Review Information

Reviewers want to go through your app as a regular user would. If your app requires signing in, you need to create a test account in your production environment that reviewers can use.

To provide login information:

  1. Open your app’s version page on App Store Connect.
  2. Scroll down to the App Review Information section.
  3. Check the checkbox next to Sign-in required.
  4. Type the login information in the Notes section.
  5. Fill out the required Contact Information fields, in case someone from Apple needs to reach out with questions.

Use the Notes section to communicate any app-specific settings or anything else a reviewer might need to review your app fully. This information carries over from version to version, but you can update it at any time.

Pre-orders

Before releasing your app for the first time, you can publish it on the App Store as a pre-order. During the pre-order period, users can sign up on your App Store product page. Once you officially release the app, customers that signed up for the pre-order receive a notification and your app downloads automatically to their device. If you have a paid app, users get charged for your app at that time as well.

To submit your app to App Review as a pre-order, click Pricing and Availability on the sidebar. Then, check the box next to Make available for pre-order.

You can continue publishing new builds during the pre-order period, but new versions have to go through App Review again. Users receive the latest version of your app once you officially release it. Publishing your app as a pre-order is a good way to drum up demand and start getting the word out while you wrap up development.

Availability

One of the benefits of the App Store is reaching customers worldwide. By default, your app is available in all countries and regions, which covers 175 territories as of this writing. However, you can deselect territories where you don’t want your app to be available.

Why might you want to do this? Each territory has different laws and regulations governing the entities that do business within its borders. If it’s too difficult to adhere to the rules in a particular territory, companies often hold back their app.

To change your app’s availability, go to your app record page in App Store Connect. On the sidebar, click Pricing and Availability. Click Edit to deselect territories.

Version Release options

When App Review approves your app, it doesn’t automatically go live in the App Store. There are three release options you can choose from.

To see your options, click the version you want to set a release option for. Scroll down to the Version Release section.

Here’s what the options mean:

  1. Manually release this version: After approval, you have to go back into App Store Connect to release your app officially. This is convenient if you need to perform last-minute sanity checks or coordinate with other team members.
  2. Automatically release this version: You authorize Apple to release your app to the public as soon as it’s approved without additional intervention from you. It takes up to 24 hours for Apple to fully distribute your app worldwide, but this is the fastest option available. This is a good option for time-sensitive updates.
  3. Automatically release this version after App Review, no earlier than: This option is similar to automatically releasing your app, but it lets you hold back the release until a predetermined date in the future. Waiting for App Review to finish can take you past this date, which is why the option says “no earlier than”.

After your initial release, you can do phased releases over a seven-day period to an increasing percentage of your users that have turned on automatic downloads. On the first day of the phased release, 1% of these users get the app’s new version. This percentage grows over the span of seven days until all users that turned on automatic updates have it.

You can also pause a phased release if you find a problem. This is a good option if your update is risky in some way. Make sure to monitor your analytics and customer feedback during the seven-day period to react appropriately.

Note: Doing a phased release in App Store Connect is the only officially sanctioned way to release an update gradually.

App Store Review Guidelines, under Section 2, Performance, states:

2.3.1 Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end-users and App Review.

Many companies ship a feature “dark” and gradually turn it on after the app is on the App Store. Even though this is a common practice, it’s technically against the App Store Review Guidelines. You can find some useful Q&A in Apple Developer Forum around this with comments from Apple that provide more context and tips to properly use this approach without violating App Store Review Guidelines.

Ratings and reviews

Customers have the option to rate your app on a scale from 1 to 5. They can also write reviews, which you can respond to in App Store Connect. Your App Store product page shows a summary rating as well as all customer reviews and any responses from you.

For example, here’s what ratings and reviews look like for the official raywenderlich.com iOS app:

Positive ratings and reviews make new customers feel comfortable downloading your app for the first time. However, negative reviews keep people away. Fortunately, if you’ve worked hard to address customer feedback, there’s a way to reset your app’s summary rating when you release a new version.

To do so, click the version you’re submitting to App Review. Under Reset iOS Summary Rating, select Reset rating when this version is released.

Note: The option to reset your summary rating only shows up in App Store Connect after your initial release.

After App Review, your summary rating on your App Store product page will reset when you release the new version. Customer reviews always remain unchanged.

Expedited App Review

App Review doesn’t start immediately after you click the Submit button. Your app submission goes into a queue. Depending on the volume of submissions and other unpublished factors, App Review can finish the same day you submit or take days or weeks.

Apple gives no guarantees about the speed of App Review, but it does publish some guidance. As of this writing, Apple states that it reviews 50% of apps within 24 hours and over 90% within 48 hours.

Although you probably wish that every review could finish in record time, sometimes you have to release a truly time-sensitive update. For example, suppose you discover a critical bug or security vulnerability that puts your entire business at risk. In that case, you’ll want to distribute the bug fix to your customers as quickly as humanly possible.

In those cases, you can request an expedited app review. Apple cannot guarantee that it’ll honor every request, but it’s worth asking. Once you submit your app for review, log into the developer portal. In the sidebar, click Contact Us. Select App Review, then select Expedited App Review Request. Here’s a direct link to this page: https://apple.co/2LvTD9y.

Fill out your contact information and your app’s information. Select a reason for the request and provide a written explanation.

Make sure to provide enough context in your explanation, especially if the reason for the request is not a critical bug fix or a time-sensitive event. Otherwise, Apple may deny your request.

Understanding app statuses

Submitting an app to App Review is a complex, multi-step process, and knowing what to do next isn’t always clear. Sometimes, Apple is waiting on you to do something. Other times, you’re waiting on Apple. To help move things along, you can consult your submission’s app status.

The app status is prominently displayed in several places. In App Store Connect, app status first makes an appearance on the top-level Apps page under your app icon. When you click your app, app status also shows up on the sidebar next to the version number.

There are 17 different app statuses in total. Here are the most important ones:

  • Prepare for Submission: You’ve created a new version of your app in App Store Connect but haven’t submitted it for review.

  • Waiting for Review: You submitted your app for review. Apple received it but it’s still waiting in the queue.

  • In Review: Apple is actively reviewing your submission! Anecdotally, most of the waiting happens in Waiting for Review. Once you’re In Review, you’ll get an answer fast.

  • Pending Developer Release: Hooray! Apple accepted your app, but you still need to go into App Store Connect to release it manually. You’ll only see this status if you selected Manually release this version as your version release option.

  • Ready for Sale: The wording of this status is a bit unintuitive. It really means “Finally on the App Store!”. This status means either you or Apple released the approved app to the App Store. When you see this status, you can celebrate.

  • Rejected: Your app didn’t pass App Review. The next section deals with how to work through an app rejection. Also, look out for a related status, Metadata Rejected. It also means Apple rejected your submission.

Note: Don’t confuse “app status” with “build status”. App status applies to the entire app submission, which includes the build, metadata and App Store Connect configuration. Each build you upload also has its own status — for example, Processing, Invalid Binary, etc. Read more about build statuses here: https://apple.co/2Ls0yjV.

App status is the primary way Apple communicates with you. Whenever an app submission moves from one status to the next, Apple sends an email notification to all App Store Connect users with access to the app. If they have the App Store Connect iOS app, they’ll also receive a push notification. To read more about app statuses, refer to App Store Connect’s documentation: https://apple.co/2YRwSQv.

Resolving app rejection issues

Even experienced developers have their apps rejected from time to time. Knowing what to expect and how to react can help you unblock yourself quickly.

You’ll first hear about the rejection from an app status notification. Your new app status will be either Rejected or Metadata Rejected.

To see what the problem is, log into App Store Connect and click the version that received the rejection. The following two screenshots come from Apple’s documentation. The red banner on the version page indicates there are one or more issues that need your attention. Click 1 unresolved iOS issues.

Doing so opens Resolution Center. Each rejection has an entry on the left, which corresponds to a thread between you and Apple on the right.

Apple starts off the conversation by telling you about the issue they found. The amount of information you get about the issue varies. Sometimes, Apple simply links to a section of the App Store Review Guidelines without additional context. In other cases, Apple uploads screenshots of what the reviewer saw and provides debugging information.

Before making any changes, make sure you understand the problem as Apple reported it. Resolution Center is a tool for you to communicate with Apple. It gives you a few options. You can:

  • Request more information if you’re not clear about the issue.
  • Tell Apple that you disagree with the rejection and provide your rationale.
  • Request to speak with someone from App Review on the phone if you’re having trouble getting your point across.

Once you understand the rejection and what Apple wants to see changed, move on to fixing the problem. The app status Rejected means there’s a problem with your app. You likely need to make code changes, generate a new build and submit it to App Review.

If, instead, your app status is Metadata Rejected, Apple took issue with your app’s name, description, keywords or other metadata. Once you fix the faulty metadata, you can re-submit the same build.

Note: Your Apple Developer Program enrollment comes with two Technical Support Incidents (TSI) per year. A TSI is a request for code-level support for Apple’s framework, APIs and tools. If you’re having trouble reproducing or fixing an issue that came up during App Review, you can use one of your TSIs to get help from Apple support engineers.

For more information, refer to Apple’s documentation page, Requesting Technical Support: http://apple.co/2ZbeNx3.

As a final piece of advice, remember that App Review is dynamic and revolves around people making decisions. Different reviewers notice different things at different times. Despite Apple’s best efforts, you may encounter inconsistencies in the App Review process from app to app and over time.

Even if Apple approved your app for years, it doesn’t mean a reviewer won’t raise an issue with a longtime feature at some point in the future. Furthermore, for any imaginable rejection you could receive, there might be other apps currently on the App Store that suffer from the same problem but have gone unnoticed. Pointing these things out in Resolution Center won’t help you. Aim to understand the problem as Apple sees it and as it applies to your individual app.

If you reach an impasse in Resolution Center, you also have the option to appeal the rejection to the App Review Board to determine if Apple should reconsider your app. As of this writing, that process is relatively new. You can start an appeal by filling out a form on the developer portal: http://apple.co/2NeRgIv.

Key points

  • Apple hires and trains employees who make sure incoming app submissions adhere to the App Store Review Guidelines.
  • The App Store Review Guidelines change over time, but they’re based on timeless principles: provide value, ensure quality, don’t cheat, respect users and assume full responsibility.
  • The App Store Review Guidelines link to a number of documents that you should also abide by, including the Apple Developer Program License Agreement, the Human Interface Guidelines (HIG) and the Brand and Marketing Guidelines.
  • An iOS app can be associated with a macOS app, a tvOS app and a watchOS app. It can also support App Clips, iMessage apps and In-App Purchases. App Store Connect supports all these add-ons.
  • Fill out the App Review Information section in App Store Connect to provide reviewers with login information and any other notes they might need.
  • Your app is available in all countries and regions by default, but you can opt-out of territories where you don’t want your app to be available.
  • After you pass App Review, you can choose to release your app manually or you can let Apple handle it. You can also do phased releases after your initial release.
  • After your initial release, you can choose to reset your summary rating on your App Store product page when you release new versions.
  • If an app update is time-sensitive, you can submit an expedited App Review request on the developer portal.
  • Resolve app rejections in App Store Connect’s Resolution Center. Communicate with Apple to clarify their request, make any necessary changes and submit a new build for review.
6. TestFlight
8. App Approved! (Now What?)
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.