IAP Localization Rejected With "Required Binary Was Not Submitted" — What It Means and How to Fix It
If you've ever updated an in-app purchase localization — added a new language, tweaked a display name, or edited the description — and been rejected with the message "The in-app purchase products have been returned because the required binary was not submitted", you are not alone. This message is one of the most misleading errors in App Store Connect: it sounds like something is wrong with your binary, but it's actually a workflow quirk in how Apple reviews IAP metadata.
This guide explains exactly what the rejection means, why it happens, how to fix it, and whether your live IAPs are affected.
What the Rejection Actually Means
The message reads:
"The in-app purchase products have been returned because the required binary was not submitted."
What Apple is really telling you is: "We can't review this IAP change in isolation — we need a binary submission to attach the review to."
Apple's review process treats IAPs as reviewable artifacts that must be tested inside a running app. When you submit an IAP metadata change (a localization, a display name, a review screenshot) without attaching it to a binary in review, the reviewer has nothing to run and no context to verify the product against. The submission gets auto-rejected with that message — even if your binary is visibly sitting in Waiting for Review on the same page.
This is not a bug you caused. It's the default behavior of the IAP review pipeline when changes aren't explicitly linked to a version.
Why "Only Adding Translations" Still Triggers This
Developers often assume metadata-only changes should be processed faster or independently. They aren't. Apple treats these updates identically to any other IAP change:
- Adding a new language localization
- Editing an existing localization's display name or description
- Updating the review screenshot
- Changing reviewer notes
- Modifying subscription pricing display text
All of them route through the same review pipeline and all of them can hit the same "required binary was not submitted" rejection if submitted standalone.
The rejection is not a quality judgment on your translation. It's a routing problem.
Your Live IAPs Are Safe
This is the most important thing to understand if you've just seen the rejection and panicked: your live, approved IAPs are not affected.
In App Store Connect you'll typically see something like:
- Approved — the live version of the IAP, still purchasable
- Updates Pending Review or Developer Rejected — the changes you submitted (the new localization, for example)
These are tracked as separate states. The rejection applies only to the pending update. Your existing localizations (the Polish version in the original case this guide was written from, for example) continue to serve users normally. No purchase flows break. No revenue is at risk.
This also means your app binary review is independent. Your version can continue through review and be approved while the IAP update sits in a rejected state. You don't need to resubmit the binary to unstick the IAP.
How to Fix It
The fix is to attach the IAP changes to a binary submission explicitly. Here's the workflow:
- Open your app in App Store Connect
- Go to the version that is currently Waiting for Review (or the next version you plan to submit)
- Scroll down to the In-App Purchases and Subscriptions section on the version page
- Click the + button and add the specific IAPs whose localizations (or other metadata) you changed
- Save the version
Once the IAPs are attached, they'll be reviewed alongside the binary and the new localizations should go through with the rest of the submission.
If your version is already in Waiting for Review and a reviewer hasn't started yet, you can usually still edit and attach the IAPs. App Store Connect permits this until the review moves to In Review. If the review has already started, attaching becomes trickier — you'll most likely need to wait for the current review decision and then resubmit the IAP changes attached to a future version (even a small bump is enough).
The "Do I Need a New Binary?" Trap
A common follow-up question: "Do I have to cut a new build just to push an IAP localization?"
Not necessarily — but you do need to associate the IAP change with a binary submission, even if that binary is unchanged in other respects. In practice this means:
- If you have a version currently in review, attach the IAPs to it
- If you don't, your cleanest path is to queue up your next planned release and attach the IAP changes to it
- If you need the localization live sooner and have no planned release, a minor version bump (e.g. 1.4.1 → 1.4.2) with no code changes is acceptable and common
Apple's review team is used to this pattern. A "metadata-only" version bump specifically to ship IAP changes is not an abuse of the review queue.
Preventing It Next Time
The practical rule for any team that manages IAPs:
Never submit IAP metadata changes without attaching them to a binary submission. Treat IAP edits as something you batch with your next app version, not as a standalone task.
If you're running a release train — for example, monthly releases — collect IAP localization updates during the sprint and apply them attached to the next binary. This avoids the rejection entirely and keeps your IAP and binary review timelines aligned.
For teams with long gaps between releases, consider scheduling metadata-only version bumps specifically to flush accumulated IAP changes. It adds a line to your release notes but saves the back-and-forth of diagnosing this rejection.
When the Rejection Is Actually About Your Binary
On rare occasions, the "required binary was not submitted" message is literal — for example, if your version was removed from review, rejected, or never submitted in the first place. To rule this out:
- Verify your version status is one of Waiting for Review, In Review, or Pending Developer Release
- Check that the IAPs are attached to that specific version, not an older one
- Confirm the version hasn't been withdrawn or rejected on the binary side
If all three are true and you still see the IAP rejection, it's the standalone-submission quirk described above.
Related Apple Review Issues
If you're dealing with IAP rejections, you may also run into:
- Common App Store rejection reasons — broader overview of what gets rejected and why
- How to appeal an App Store rejection — when you disagree with a reviewer decision
- App Store review queue delays in 2026 — why IAP and binary reviews are taking longer than usual
- How to contact Apple App Review — reaching a human when the automated flow fails
Monitor Your App Store Reviews Automatically
While you're dealing with the IAP review queue, don't miss what users are saying about your app. AppStoreReview monitors your app across 175+ countries, sends instant alerts for negative reviews, and lets you set keyword filters so a single IAP-related complaint doesn't get lost in the noise.
Frequently Asked Questions
Does the "required binary was not submitted" rejection affect my live IAPs?
No. Your live, approved IAPs — including their existing localizations — remain purchasable and untouched. The rejection only applies to the pending changes you submitted (such as new localizations). The product's approved state is preserved separately from any updates pending review.
Can my app binary still get approved if my new IAP localizations are rejected?
Yes. App binary review and IAP review are tracked independently. Your binary can go through review and be released even if the IAP metadata changes are stuck. The existing approved IAPs will continue to work in the released build.
Do I really need to attach IAPs to a binary submission just to change a translation?
Yes — this is the root cause of the rejection. Apple's review workflow requires IAP changes (including pure metadata and localization edits) to be tied to a binary submission so reviewers can test the IAP in the context of a running app. Standalone IAP submissions often get auto-rejected with the "required binary was not submitted" message even when the binary obviously exists.
Can I attach IAPs to a version that is already Waiting for Review?
Usually yes, as long as a reviewer hasn't picked up the build yet. Open the version in App Store Connect, scroll to the In-App Purchases and Subscriptions section, and add the affected IAPs. If review has already started, you'll typically need to wait for the binary decision and resubmit the IAP changes attached to a later version.