App Store "rejection" versus "Information Needed": what is the difference?
When an app does not go straight to approval, most developers describe the result as a rejection. Apple's messages are more varied than that word suggests. Some say that a specific part of the app breaks a guideline. Others simply say that App Review needs more information before it can finish. The two look similar in an inbox, but they mean different things about how the reviewer sees the app.
Understanding the difference helps you read a message accurately, which matters because the next step depends on what Apple is actually telling you. This guide describes the categories and what each signals. It does not tell you how to resolve any particular case.
What a true rejection says
A rejection normally names a guideline number and a short title, for example a guideline from the Performance or Safety sections, followed by a description of what the reviewer found. The finding is specific: a crash, a missing feature, content that crosses a line or a store-listing problem. The message reflects a judgement that the submitted version, as it stands, does not meet the guideline cited.
Because the finding is about something the reviewer observed, a rejection is usually tied to a particular build or to the listing. It tells you what was observed more than what to do about it, which is why the same guideline number can describe quite different situations from one app to another.
What "Information Needed" signals
An Information Needed message is different in kind. It says that App Review cannot complete its assessment without additional material from the developer. The guideline it cites is often the general completeness guideline, 2.1, and the message lists the items Apple wants, such as a screen recording on a physical device, a description of the app's purpose and audience, how to access the main features, the external services the app uses and whether it behaves differently by region.
This kind of message is common for new apps and for developer accounts with a limited review history. It is not a statement that the app is defective. It is a statement that the reviewer needs context. The app is still waiting for a decision rather than having received an adverse one.
Why the label on the message can mislead
Both kinds of message can arrive in the same place, with the same sender, and with a status in App Store Connect that suggests the submission has not been accepted. Statuses such as Rejected or Unresolved Issues describe where the submission stands, not the reason for it. The reason is in the body of the message.
Developers sometimes read an Information Needed message as a verdict, change the build and resubmit, only to find that the reviewer was waiting for an answer rather than for new code. That is one reason it pays to read the exact wording before drawing conclusions about what the reviewer thinks of the app.
Where Google Play fits in
Google Play has comparable distinctions, though they appear differently. A policy violation notice names the policy and the app or release affected. Separate messages can ask for declarations, such as the permissions declaration or details for a sensitive category, before a release can proceed. As on the App Store, the wording of the notice, not just its existence, tells you whether Google has found a problem or is asking for something.
Who can see the message
On the App Store, the detailed messages sit in App Store Connect, and typically only team members with certain roles can open them. If a person on the team cannot read the message, the email notification they receive may name the status without the guideline, which can make a straightforward request look mysterious. Knowing that the full text lives in App Store Connect, and who can open it, explains many of the "we don't know why it was rejected" situations teams describe.
Why new accounts see more information requests
Apple has indicated in its messages that submissions from developer accounts with limited review history may be asked for extra detail. The reasoning appears to be that the reviewer has less background on the developer and wants to understand the app, its audience and the services behind it before approving. It is therefore common for a first app from a new account to receive an information request before any substantive finding.
That does not mean the app is likely to be rejected afterwards. Many apps are approved once the questions are answered. It does mean that the first review of a new account can look different from later ones.
How the two kinds of message affect timing
A rejection normally returns the submission to the developer with a defined finding. An information request leaves the submission open, waiting for the reply. In both cases the clock effectively restarts when something new is submitted or answered, so the experience of waiting can feel similar even though the underlying situation is different.
Common questions
It can be. The request is a step in the review, and the outcome depends on what is found afterwards.
Not reliably. The same number can appear in both, so the wording of the message is what distinguishes them.
Google can ask for declarations and supporting material, though the presentation differs from Apple's.
Review processes change often. This guide is a plain-language explanation written by AppReviewFix, not official guidance. Check Apple's App Store Review Guidelines and Google's Developer Program Policies for current details.