Seeing Returned next to an item in App Store Connect reads like a rejection, and it sends people scrambling to fix something that is not broken. In most cases Returned is not a content judgment at all. It usually means an in-app purchase came back because no app binary was submitted with it. Rejected is the one that carries real feedback. Here is the difference and what to do for each.
Short answer
Rejected and Returned mean different things. Rejected means an item was reviewed and not accepted, with a message citing the issue, so you fix it and resubmit. Returned is usually about an in-app purchase: Apple sends it back because it could not be reviewed without an accompanying app binary, with the message that your products were returned as the required binary was not submitted. It is a procedural return, not a content judgment, so the fix is to attach the in-app purchase to a new app version submission and resubmit them together, rather than changing the item itself.
What you should know
- Rejected carries feedback: the item was reviewed and not accepted, and the message says why.
- Returned is usually procedural: an in-app purchase came back because no app binary was submitted with it.
- Returned is not a content fault: there is often nothing to fix in the item itself.
- The first IAP rides with the app: a new in-app purchase must be reviewed alongside an app binary.
- The fixes differ: Rejected means change something; Returned means resubmit it attached to the app.
What does "Rejected" mean?
It means App Review looked at the item and did not accept it. When your app or an in-app purchase is rejected, you receive a message describing the problem, usually with the App Review Guideline it relates to, and the item cannot proceed until you address that and resubmit. This is the status that requires a change on your side, whether that is a build fix, a metadata edit, or a different approach. The defining feature of Rejected is that there is feedback to act on, so the first step is always to read the message rather than to resubmit blindly. A Rejected status can apply to the app version itself, to a metadata-only issue, or to an in-app purchase reviewed on its own merits, and in each case the message names what failed, which is what makes Rejected actionable in a way Returned is not.
What does "Returned" mean?
It usually means an in-app purchase was sent back to you because it could not be reviewed on its own. Apple's wording is that your in-app purchase products were returned because the required binary was not submitted. In-app purchases are reviewed alongside an app version, so if the binary they needed was not part of the submission, or the app submission was removed or rejected, the in-app purchase has nothing to be reviewed against and is returned to an editable state. That is a process outcome, not a verdict on the item, which is why there is often nothing wrong with the in-app purchase itself. You can confirm this by reading the return message: it talks about a missing binary, not about a guideline your in-app purchase violated, which is the quickest way to tell a return apart from a rejection.
Returned vs Rejected at a glance
The two look similar in the interface but call for different responses. The table sorts the common statuses.
| Status | What it means | What to do |
|---|---|---|
| Rejected | The item was reviewed and not accepted; the message cites the issue | Read the feedback, fix the issue, then resubmit |
| Returned | An item, usually an in-app purchase, came back because no app binary was submitted with it | Attach it to a new app version submission and resubmit together |
| Metadata Rejected | Your metadata was not accepted | Edit the metadata and reply, no new build needed |
| Developer Rejected | You removed your own submission from review | Resubmit when you are ready |
How do you resolve each one?
By matching the action to the cause. For a Rejected item, open the message, identify the guideline or bug it names, make the change, and resubmit; the work is in the fix. For a Returned in-app purchase, you generally do not change the item at all. Instead, put it back into the editable state, attach it to a new app version submission, and submit them together so App Review has the binary to evaluate it against. It helps to add a note to the reviewer pointing at the in-app purchase. The mistake to avoid is editing a Returned item as if it failed review, when the real issue was that it had no binary to ride with.
What to watch out for
The first trap is panicking over a Returned status and rewriting a perfectly good in-app purchase, when all it needed was to be submitted with the app. The second is the root cause: the first in-app purchase for an app has to be reviewed alongside an app version, so submit them together to avoid the return in the first place. Both of these are submission-flow issues rather than security findings, so they sit apart from a pre-submission scan; a scan such as PTKD.com (https://ptkd.com) checks the binary against OWASP MASVS, which is a separate concern from how App Store Connect labels your submission state. Read the status for what it is before you act on it.
What to take away
- Rejected means an item was reviewed and not accepted, with feedback to address before you resubmit.
- Returned usually means an in-app purchase came back because no app binary was submitted with it, which is procedural, not a content fault.
- Fix a Rejected item; for a Returned item, attach it to a new app version submission and resubmit them together.
- Submit the first in-app purchase alongside its app version to avoid the Returned status, and keep the binary check separate with a pre-submission scan such as PTKD.com.
