A subscription stuck in Waiting for Review is usually an item-state or submission-assembly problem before it is a StoreKit bug. Check the product, its group, the app version, and the draft submission separately.
Do not recreate products or upload builds blindly. Identify which object has the blocking status, complete it, and make sure every required item is in the same review submission.
The workflow below was checked against Submit an In-App Purchase and Submit an app on 4 August 2026. The first source controls the rule or workflow; the second supports the article-specific implementation boundary.
The short version
- Open the subscription product and complete all required information.
- Open the subscription group and complete its own information.
- Verify the intended app version and build are in the draft.
- Verify each subscription product was added individually.
- Include a new group when Apple’s current workflow requires it.
The iOS subscription and in-app purchase review guide covers the release from configuration through entitlement. This page stays inside App Store Connect and names which object is waiting, because a product status, a group status, and an app-version status demand different actions.
Name the object that is waiting
App Store Connect tracks the app version, the subscription product, and the subscription group as three separate objects, each with its own status. Open all three and write down what each one actually says. “The subscription is waiting” is not a diagnosis: the group can sit incomplete while the product looks ready, or the product can be fully configured and still never have joined the app version’s submission.
Complete product and group information
Open the product first. Review its localization, duration, pricing, and review information, and clear every red or incomplete field on that object. Then open the group on its own page: a subscription group carries separate localized information that saving the product never fills in. Fix each object where the incomplete field is flagged rather than removing and re-adding the item to a draft and hoping the status resets on its own.
Inspect the draft as a manifest
Treat the draft submission as a manifest, not a formality. It should list the exact app version you intend to ship and every purchase item meant to go out with it. Apple’s current instructions require a new subscription group to include at least one subscription before it can be added to a version; skipping that step is a common reason a group never leaves Waiting for Review. Recount the item list after every edit, since removing one plan to fix a typo can silently drop it from the manifest.
Escalate with a clean record
If the product, the group, and the draft all read as complete and correctly included, and the status still has not moved, contact App Review with the app version, build number, product identifiers, group name, submission date, and a screenshot of the item list. That record is stronger evidence than deleting a product or rotating an identifier without proof that either one was actually the problem.
Run the first checks in order
These are App Store Connect item checks, not code changes. Running them in this order keeps you from editing three layers at once and losing track of which one mattered:
- Open the subscription product and complete all required information.
- Open the subscription group and complete its own information.
- Verify the intended app version and build are in the draft.
- Verify each subscription product was added individually.
- Include a new group when Apple’s current workflow requires it.
- Keep a record of every item and status before contacting App Review.
If the item statuses above are already clean and the paywall still behaves differently for a reviewer than it does for you, the block has probably moved from item state to environment: see sandbox vs production purchases before touching a build.
Choose the next action
Match what the item statuses actually show, not what feels likely, to the smallest correct action:
| What the item statuses show | Where the block sits | Action | New build? |
|---|---|---|---|
| Product complete, group still flags red or incomplete fields | Subscription group | Finish the group’s own localized information | No |
| Group complete, but the product never appears in the version’s item list | Draft submission manifest | Add the product to the draft individually, then recount the list | No |
| One plan in a multi-plan paywall is missing from the manifest | Draft submission manifest | Add the missing plan and resubmit the same build | Usually no |
| Every item is complete and included, status unchanged after 24+ hours | Apple’s review queue | Escalate with app version, build, product IDs, group name, and screenshots | No |
Do not delete a product or rotate its identifier before this table tells you which object is actually incomplete. That single check often replaces a full afternoon of guessing.
Failure patterns to look for
- The product is complete but the group is not.
- The app version is in review while the product remains outside the submission.
- One plan in a multi-plan paywall was omitted.
- A cancelled submission left the team looking at the wrong draft.
Use those four status patterns to decide which App Store Connect object to open next; they are not frequency data. Apple’s current submission help remains the source of truth for how products, groups, and app versions move into review.
Write App Review Notes as a test script
Once every item status is confirmed, put that state into words the reviewer does not have to reconstruct on their own. Name the app version, build number, product identifiers, group name, and the exact taps from launch to the paywall, plus the result you expect after purchase or restore.
Keep the note factual. State what you tested and where the control appears in the app. Do not promise that Apple’s queue will clear on a particular schedule, and do not describe an item state you have not personally re-verified since your last edit.
A useful structure is:
- App version, build number, and product or group identifiers.
- Entry path from launch to the paywall.
- Account or state required to see it.
- Purchase or restore action to test.
- Visible result expected after the transaction.
What not to change blindly
Do not recreate a product or a subscription group on the assumption that a fresh copy will clear a stuck status. Recreating either one changes its identifier and adds configuration work the original object never needed. Do not rotate a shared secret or purchase-service key because a status looks stale, either: neither action fixes an incomplete field or a missing manifest entry, and both leave you with new state to track.
Also avoid following an App Store Connect walkthrough that does not carry a recent date. Apple relabels fields and changes submission steps between releases. Use the sources linked below, then match the labels you actually see in your own account.
Verification note: the App Store Connect workflow above was checked against Apple’s current help pages on 4 August 2026. Recheck the linked pages before you rely on this article for a later resubmission, since Apple can rename fields or change the submission steps.
FAQ about subscription stuck waiting for review App Store
Why does the group show incomplete when every product looks ready?
The subscription group carries its own localized information, separate from any product inside it. Saving a product never fills in the group’s fields. Open the group directly and clear whatever it flags before assuming the whole submission is stuck.
Does adding a missing product to an existing draft require a new build?
No, as long as the app version already in the draft is the one you intend to ship. Adding or completing a purchase item changes the submission manifest, not the binary, so no new build is required unless the code itself also needs a fix.
Can I remove one subscription from a submission without cancelling the whole thing?
You can edit the draft’s item list while it is still editable, which is why treating the draft as a manifest and recounting items after every change matters. Once App Review has actually started, changes are more limited, so check the current status before editing.
How long is normal for Waiting for Review before I contact Apple?
Apple does not publish a fixed duration, and the corpus behind this article tracks failure patterns, not timing. If every item status is confirmed complete and correctly included, and the status has not moved for more than a day, escalate with the record described above instead of continuing to guess.
Conclusion
Do not recreate products or upload builds blindly. Identify which object has the blocking status, complete it, and make sure every required item is in the same review submission.
Match the item statuses to the smallest action in the table above before you touch a build or a shared key. Keep the evidence with your reply so the next review starts from a confirmed state, not another guess.
Sources and references
- Submit an In-App Purchase: accessed 4 August 2026.
- Submit an app: accessed 4 August 2026.
- Offer auto-renewable subscriptions: accessed 4 August 2026.