Introduction
When submitting an app for publication within the App Store, Apple reviews the app (opens in a new tab) - and app updates as well - to determine whether it adheres to the requirements of the App Store Review Guidelines (opens in a new tab) and of the Apple Developer Program License Agreement (opens in a new tab).
This verification isn’t performed in an automated way, but it is a human reviewer who takes care of a manual check. As a consequence, the review can take up to a few days and it is subject to the personal interpretation of the reviewer. It may happen that the reviewer doesn't fully understand the use case or the purpose for which the app has been submitted and therefore rejects it for various reasons.
This document provides guidelines on how to address your branded app’s rejection by Apple. In the Common App Rejections section you will find some of the most common issues that cause branded mobile apps to get rejected. Details provided by the Apple reviewer, including the specific App Store Review Guideline, are listed throughout the Rejection Reason sections. In the Addressing the Rejection sections you can learn how to manage the conversation with the reviewer and explain why the app you're submitting adheres to Apple’s requirements.
Use the Resolution Center on iTunes Connect to reply to the messages you received from Apple. In your reply, make sure you provide as much information and details as possible to Apple’s reviewer, and upload attachments if they can help give more context to your message.
For other info on the Branded Mobile App, find all of the details in the dedicated articles of the Knowledge Base
Common App Rejections
Rejection Reason 2.1
Guideline 2.1 - Information Needed
We’re looking forward to completing our review but to continue we need more information about how your app uses cookies.
Please review the following questions and provide as much detailed information as you can for each question.
- Does your app collect any personally identifiable information?
- Is the data collected by your app shared with any third-party data brokers?
- Is the data collected by your app linked with third-party data for marketing or advertising purposes?
Addressing the Rejection 2.1
- Does your app collect any personally identifiable information?
Yes, the app connects users to the Docebo Learning Management System. We collect personal information so that we can provide product updates or training on quality issues. As we offer FDA-regulated products, the app complies with the federal requirement to inform users of updates and changes.
- Is the data collected by your app shared with any third-party data brokers?
No. We do not share the collected data.
- Is the data collected by your app linked with third-party data for marketing or advertising purposes?
No. We do not use the collected data for any marketing purposes.
Rejection Reason 2.5.4
Guideline 2.5.4 - Performance - Software Requirements
Your app still declares support for audio in the UIBackgroundModes key in your Info.plist, but we were unable to play any audible content when the app was running in the background.
Addressing the Rejection 2.5.4
In order to allow Apple to test the background audio playback functionality in videos, you need to create a course in which you insert a video training material (by uploading a file, and not a video from social media platforms), then enroll the test user into that course. In the App Store, make sure you add the following note for the tester:
You need to play the video {video_name} in the course {couse_name} in order to test the background audio playback functionality”.
Rejection Reasons 3.1.1 and 3.1.3(a)
Guidelines 3.1.1 - In-App Purchase and 3.1.3(a) - "Reader" Apps
We noticed in our review that your app allows users to access previously purchased video / audio content or content subscriptions. However, your app includes an account registration feature for paid content.
"Reader" apps are apps that access certain kinds of previously purchased digital media. They may offer account creation for free tiers, and account management functionality for existing customers, but they shouldn't include registration for accounts that access paid content.
Next Steps
It would be appropriate to remove the account registration features for paid content from your app before resubmitting for review.
If there's additional information you'd like to provide regarding the digital content and services in your app, reply to this message in App Store Connect and let us know. If there's information you'd like us to consider in future submissions, please feel free to include it in the App Review Information section of App Store Connect (opens in a new tab).
Resources
Learn more about our policies for "reader" apps in App Store Review Guideline 3.1.3(a) (opens in a new tab).
Addressing the Rejections 3.1.1 and 3.1.3(a)
Apple rejected your application because it allows users to access paid content that they purchased outside of Apple’s ecosystem and not within the app. You can overcome this rejection by enabling the Reader App mode in the Branded Mobile App Publisher menu.
With the reader mode, you are compliant with Apple’s App Store guidelines 3.1.1 on in-app purchase (opens in a new tab) and 3.1.3(a) on “Reader” Apps (opens in a new tab) and you can safely build your Reader app and upload it on the App Store. Thanks to the reader mode, your users can access previously purchased content without any concerns.
Please note that within Reader apps users’ registration is not available, so your users need to register from the desktop platform.
If Apple’s rejection only mentions the guideline 3.1.1 and your app allows users to access paid content that they purchased outside of Apple’s ecosystem, generate the Reader App as just explained and then in the App Store reply to Apple’s rejection with this text:
The app submitted is considered a "Reader” app (App Store Review Guidelines - Business guideline 3.1.3(a)).
It allows a logged user to access previously purchased digital content (specifically audio and video) and no content can be bought inside the app.
Also, there isn't the possibility to create an account from the app itself and the main point of contact for users is the desktop website [insert your platform domain here].
Rejection Reason 3.2 (Case 1)
Guideline 3.2 - Business
We found that your app is an in-house app, intended for employees or members of your organization. As such, it is not appropriate for the App Store. For information on distributing proprietary, in-house apps, please refer to the Apple Developer Enterprise Program.
Addressing the Rejection 3.2 (Case 1)
If your app is for internal use only (app developed just for your company employees), then it cannot be published on the Apple App Store.
As an alternative, you can evaluate to publish privately the app in one of the following ways:
- Apple Developer Enterprise Program (opens in a new tab)
- Apple Business Manager (opens in a new tab)
- Any Mobile Device Management System (MDM)
Rejection Reason 3.2 (Case 2)
Guideline 3.2 - Business
We found in our review that your app is designed to be used by a specific business or organization, including partners or employees. Custom app distribution through Apple Business Manager or Apple School Manager is the best way to make these kinds of business apps available to your target audience.
Addressing the Rejection 3.2 (Case 2)
The system (and thus the app) will be used both by our employees and by users external to our organization — about {X}% of our audience is composed of internal employees, but about {Y}% of our audience is made up of customers, partners and distributors.
For those users who belong to the second group, we obviously have no control over their devices, as they are private users and independent from our organization and, therefore, we cannot control them through any form of Mobile Device Management Systems (MDM). As a consequence, in order to cover this scenario — the most important one — we need the app to be available for download from Apple's public App Store.
Rejection Reason 4.8
Guideline 4.8 - Design - Sign in with Apple
We noticed that your app uses a third-party login service but does not offer Sign in with Apple. Apps that use a third-party login service for account authentication must offer Sign in with Apple to users as an equivalent option.
Addressing the Rejection 4.8
When you submit your branded app to Apple, remember to add the following note:
{APP_NAME} app is a business app that requires the user to sign in with an existing enterprise account. Because of this reason, it is not possible to offer Sign in with Apple.
Rejection Reason 5.1.1 (Case 1)
Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage
To resolve this issue, it would be appropriate to please revise your app to let users freely access your app’s features that are not account-based.
Addressing the Rejection 5.1.1 (Case 1)
You can explain to the reviewer that every single feature in the app is account-based, that's why the user must log in in order to access the app. You can use this template:
{Client_Learning_Portal} is an account-based Learning Management System. In the app, every feature is account-based. In order to access every piece of content, the user needs to create an account and to log in. The content within the {Client_Learning_Portal} Learning Management System is proprietary information that customers can access after creating an account. The LMS requires all users to create an account to log in.
If you prefer, you can also start from the following template, adjusting it to your implementation to provide info on the content of every page in your app:
The app contains exclusively account-based features:
- The content of the All Channels page varies for each user according to their group or branch
- The My Courses & Learning Plans page is personal by definition
- The My Channel page is personal by definition
- The My Skills page is tailor-made to the user's specific skills
- The Questions & Answers page varies for each user according to their group or branch
- The My Gamification page is personal by definition
As a consequence, the login procedure is always required.
As an alternative to the two previous replies on the account-based features in the app, you can activate the demo mode for your branded mobile app on iOS devices.
Rejection Reason 5.1.1 (Case 2)
Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage
We have noticed that your application during the registration process asks for a lot of information other than the desired username. It would be appropriate to ask only for the information that is strictly necessary to provide your service. Can you explain why the username is not sufficient?
Addressing the Rejection 5.1.1 (Case 2)
Since Apple is very sensitive to privacy, in the self-registration process you should ask users only the information that is really required, and you should also explain to the reviewer why you need info different from the username.
Appealing App Rejections
If you think that more decisive action than the conversation with the reviewer in the Resolution Center is needed to have your app's rejection re-evaluated, an additional possibility that you can explore in order to address your app rejection is to submit an appeal request.
In the Support area of the App Store, Apple also offers a service allowing you to appeal the rejection of your app to Apple's review board. It may sound like a complex process, but Apple usually responds to your appeal within 24 hours.
With the appeal request, you will be able to ask to have a representative from the App Store contact you by phone to verbally discuss your app’s rejection and why your app has the right to be in the App Store. Fill in the form available in the Support area of the App Store (opens in a new tab) to be contacted by Apple’s App Review team.