The first In-App Purchase of each product type must still be submitted with a new app version, while later products may usually be submitted independently once that type has an approved product and the app has an approved version. In 2026, start from the product’s In-App Purchases or Subscriptions area and use Add for Review to create or update the review submission, rather than assuming a successful Sandbox purchase is enough.
This guide is for independent developers submitting a consumable, non-consumable, or subscription product for the first time. It also covers teams adding new price tiers or subscription offers, and teams building releases on a remote Mac that need a reliable handoff from Build upload to review.
Key takeaway: Product configuration, Sandbox testing, build processing, App Review submission, and live sales are separate checkpoints. Passing one does not prove that the others are complete.
First, decide whether the product can be submitted alone
The first decision is not about the button in App Store Connect. It is about the product type and the approval history attached to that type.
Apple’s current submission guidance confirms that the first product of a given type must be submitted with a new app version. Once that type has an approved product and the app has an approved version, a later product of the same type can generally be submitted without attaching another app version. The rule applies by product type, so an approved subscription does not automatically satisfy the first-product requirement for a consumable or non-consumable product. See Apple’s official In-App Purchase submission requirements.
Use this distinction before creating a draft:
| Product situation | Can it normally be submitted without a new app version? | What must be checked first |
|---|---|---|
| First consumable product | No | A new app version, the product, metadata, and a working purchase path |
| Later consumable product | Usually yes | An approved consumable product and an approved app version |
| First non-consumable product | No | A new app version and complete review information |
| Later non-consumable product | Usually yes | Approval history for the same product type |
| First auto-renewable subscription | No | The subscription group, at least one subscription, and a new app version |
| Later auto-renewable subscription | Usually yes | An approved subscription in the relevant group and an approved app version |
| First non-renewing subscription | No | A new app version and complete product information |
| Later non-renewing subscription | Usually yes | An approved product of that same type |
The word “usually” matters. App Store Connect can still require additional review context, and a product that depends on a feature unavailable in the submitted build can be rejected even when the product is technically eligible for an independent submission.
A developer adding a second monthly plan should therefore not treat a previously approved one-time purchase as proof that the new subscription can be submitted alone. The approval record must match the relevant In-App Purchase type or subscription context.
Prepare the product before opening the review draft
A product can be available for testing and still be incomplete for App Review. Testing confirms that a transaction can be initiated or completed in a test environment. It does not confirm that the reviewer has enough metadata, screenshots, notes, and access instructions to evaluate the product.
Open the product record and review these areas:
- Product status and availability.
- Display name, description, and localization.
- Price schedule and territories where the product will be sold.
- Review screenshot showing the purchase or entitlement flow.
- Review Notes explaining how the reviewer reaches the product.
- Any account credentials or setup steps required to unlock the purchase.
- The exact Product ID used by the app.
- For subscriptions, the correct Subscription Group and its associated products.
For subscriptions, confirm that the group itself is configured before treating the product as ready. A subscription product sitting in the wrong group can create a review problem that is unrelated to the build or the payment code.
The Apple documentation for editing In-App Purchase information explains the metadata and review-information areas that must be maintained. The product record should also be checked against the build’s entitlement and Product ID values. A spelling difference can leave the review team unable to reach the purchase even when Sandbox testing worked.
| Review area | What the developer should verify | Failure caused by skipping it |
|---|---|---|
| Product identity | Product ID matches the value requested by the app | The reviewer cannot load the intended product |
| Localized information | Name and description are complete for the intended storefronts | The item appears incomplete or unclear |
| Price and availability | The product is available in the required territories | A reviewer cannot reproduce the commercial flow |
| Screenshot | The image shows the purchase path or entitlement context | Review lacks visual evidence for the item |
| Review Notes | Steps explain where to find and test the product | The product may be treated as inaccessible |
| Subscription Group | The subscription belongs to the intended group | Subscription behavior and upgrade paths may be misread |
| App access | The submitted build exposes a reachable purchase entry point | Metadata exists, but the feature cannot be reviewed |
Second step: find Add for Review in the right area
The Add for Review action is reached from the relevant In-App Purchases or Subscriptions management area. It is not a replacement for product setup, and it is not the same as making an item available for sale.
From there, the developer generally chooses one of two paths:
- Add the product to an existing submission draft.
- Create a new submission draft for the product when App Store Connect presents that option.
The important result is the object relationship shown in the draft. The reviewer should be able to see whether the submission contains an app version, a build, a subscription group, an individual subscription, or another In-App Purchase object.
This is also where the answer to “where is Add for Review?” becomes practical: the action belongs to the product-management and submission workflow, not to Xcode and not to the Sandbox test screen. Apple’s submission overview describes the broader draft-and-submit model.
For a first product, the draft should normally contain the new app version and the product being introduced. For a later product that meets the approval conditions, the draft may contain only the product or related product objects. The interface can vary as Apple changes App Store Connect, so the draft’s object list is more reliable than memorizing the exact position of a button.
Put the app version and product in one draft when required
A first subscription cannot normally be separated from the app version merely because the purchase has already been tested. The same applies to the first consumable, non-consumable, and non-renewing subscription product of their respective types.
For the first product, use this sequence:
- Confirm that the app version exists in App Store Connect.
- Upload a build that contains the purchase entry point.
- Wait until the build is processed and selectable.
- Select the correct build in the app version.
- Add the product through Add for Review.
- For a first auto-renewable subscription, include the Subscription Group and the subscription product in the same review draft when App Store Connect requires that relationship.
- Open the submission summary and verify every required object before submitting.
The following view is a useful acceptance test before the final click:
| Submission case | Objects expected in the draft | What is not enough by itself |
|---|---|---|
| First product of a type | App version, processed build, and first product | A product marked ready to submit |
| First auto-renewable subscription | App version, processed build, subscription group, and subscription product | A successful subscription Sandbox transaction |
| Later product of an approved type | Product and any related submission objects shown by App Store Connect | A previously approved product of another type |
| Product update with a changed app experience | The relevant app version and product context | Reusing an old build without checking the purchase path |
Review note: The app name, Product ID, Bundle ID, Team ID, account details, screenshots, and logs should be anonymized before they are shared in internal tickets or public debugging threads.
Validate the build before formal submission
When a new app version is required, the build is part of the review evidence. Uploading a file is only one checkpoint. The developer must confirm that App Store Connect has processed it and that the selected build is the one containing the intended purchase flow.
The release path should use the Xcode version approved for formal distribution. Xcode 26 should be treated as the production distribution path in this workflow. As of August 29, 2026, Xcode 27 beta 6 is approved for TestFlight internal and external testing, but that testing status must not be presented as approval for formal App Store customer distribution. Apple’s App Store Connect release notes should be checked again before a release date because support boundaries can change.
A remote Mac adds several operational checks:
- Confirm the intended Xcode version is installed and selected.
- Confirm the signing team, certificate, and provisioning profile match the target.
- Verify that the archive uses the expected Bundle ID and entitlements.
- Upload the archive and record the build number.
- Monitor processing until the build becomes available in App Store Connect.
- Select that exact build in the app version.
- Open the app’s purchase screen and verify that the intended product can be reached.
- Save the upload result, processing status, and signing logs in the release record.
- If the remote session disconnects, reconnect and check the archive and upload state before starting again.
Apple defines separate build upload statuses. A processed build is not automatically an approved app version, and an approved build does not mean the attached In-App Purchase has passed review.
Teams using a remote Mac should separate upload credentials from everyday development access. Apple’s account roles guidance should be used to confirm who can edit products, upload builds, submit for review, and respond to review messages. This reduces the chance that a routine code change exposes a publishing credential or that the only person with submission access becomes unavailable.
For developers who need a persistent build host without buying another Mac, RUVCLOUD’s remote Mac access options can be evaluated against the required Xcode workflow, signing method, connection method, and expected release cadence. The decision should be based on whether the environment can be recovered and audited, not only whether Xcode opens successfully.
Track every object after submission
After pressing Submit for Review, do not rely on a single “processed” or “ready” label. App Store Connect can show different states for the app version, build, In-App Purchase, Subscription Group, and review submission.
Track these objects separately:
- The app version and its selected build.
- The In-App Purchase product.
- The Subscription Group, if applicable.
- The review submission.
- Messages or action requests from App Review.
- The final availability or sale status after approval.
Apple’s app and submission status definitions provide the reference for interpreting those states. A build that has finished processing only proves that App Store Connect accepted and inspected the upload technically. It does not prove that the review submission is complete or that the product is available for sale.
If a product is rejected, first read the message and identify which object is named. Correct the product metadata, review notes, screenshot, subscription relationship, app behavior, or access instructions as requested. Then use Update Review and resubmit the affected submission.
A new binary is not automatically required. If the rejection concerns product metadata or the reviewer’s instructions, uploading an unchanged build adds another processing step without addressing the cause. A new build becomes relevant when the rejection identifies an app behavior, missing purchase entry point, entitlement issue, or other binary-level defect.
When multiple objects were submitted together, isolate the blocker:
- If the app version is rejected, inspect the build and the app’s purchase entry point.
- If the product is rejected, inspect product metadata and review evidence.
- If the subscription group is involved, inspect group membership and subscription behavior.
- If the submission remains incomplete, inspect whether one required object was never added through Add for Review.
Turn the next release into a repeatable control
The first successful submission should become a release record, not a one-time memory. A small team can maintain a product register with these fields:
- Product type.
- Product ID.
- Subscription Group, if applicable.
- Whether this is the first approved product of its type.
- Associated app version and build number.
- Localizations and storefront scope.
- Review screenshot and Review Notes location.
- Submission date and review outcome.
- Any rejection message and corrective action.
Before each release, separate three responsibilities: build creation, submission preparation, and publishing credentials. This makes it easier to determine whether a failure occurred in Xcode, signing, upload processing, product configuration, or App Review.
The team should also perform one controlled later-product submission after the first product is approved. That test confirms whether the team can:
- Submit a later product independently when eligible.
- Find the correct Add for Review entry point.
- Recover after a remote connection interruption.
- Identify whether a rejection affects the product or the binary.
- Resubmit without unnecessarily uploading an unchanged build.
Final pre-submission checklist
- [ ] The product type has been identified correctly.
- [ ] The team has confirmed whether this is the first product of that type.
- [ ] An approved app version exists when an independent product submission is being attempted.
- [ ] Product ID and app code match exactly.
- [ ] Localized product information is complete.
- [ ] Price and territory settings are correct.
- [ ] Review screenshot and Review Notes explain the purchase path.
- [ ] The Subscription Group is correct for an auto-renewable subscription.
- [ ] The build uses the production-supported Xcode distribution path.
- [ ] Signing, entitlements, and provisioning have been checked.
- [ ] The build has finished processing and is selected in the app version when required.
- [ ] The purchase entry point is reachable in the submitted build.
- [ ] Add for Review has added every required object to the draft.
- [ ] App version, product, group, and submission statuses have been recorded.
- [ ] Sensitive app and account identifiers have been removed from shared logs.
- [ ] The team knows whether a future rejection would require metadata changes or a new build.
For a developer who already has a stable Mac, local submission remains the simplest choice, especially when releases are infrequent and the machine is available whenever review work is needed. A shared Windows or Linux workflow still leaves Xcode, signing, archive generation, and App Store Connect upload dependent on an additional macOS environment. A cloud-only build can also introduce queueing, credential boundaries, limited recovery control, or uncertainty about the exact Xcode image.
When those limitations make a release easy to interrupt, renting a Mac from RUVCLOUD can provide a continuously available macOS workspace for the next real In-App Purchase submission. The sensible test is not a demo build: use the environment to verify signing, Build upload, Add for Review preparation, disconnection recovery, and the team’s ability to resubmit a rejected product. RUVCLOUD’s plan information can then be compared with the cost and operational burden of maintaining a dedicated Mac.
Last updated August 29, 2026. Workflow and version-status claims were checked against Apple’s In-App Purchase submission guidance, App Store submission requirements, and App Store Connect release documentation.