How can a watchOS-only app submit its first IAP when App Store Connect blocks it?

Question

Sean_Fu OP

Created 2d

Replies 0

Boosts 0

Participants 1

I’m trying to determine the supported submission path for the first non-consumable IAP in a watchOS-only app.

Configuration

The app uses a standard watch-only container:

Container: com.seanfu.safe
Watch app: com.seanfu.safe.watchkitapp
ITSWatchOnlyContainer = true
WKWatchOnly = true
WKApplication = true

It offers one non-consumable “Full Version” unlock and uses StoreKit 2:

Product.products(for:)
Product.purchase(options:)
Transaction.currentEntitlements
Transaction.updates

The product ID in the Release binary exactly matches App Store Connect. Paid Apps agreements, banking, tax, pricing, and territory availability are active. The Release archive contains no local .storekit configuration or test bundle.

TestFlight works, but App Review receives no product

In TestFlight, using the real App Store sandbox and App Store Connect product configuration, Product.products(for:) returns the correct product, localized price, and title. The purchase sheet can be presented.

During App Review, the same request repeatedly returns an empty array without throwing an error.

The reviewer sees this application-defined diagnostic:

IAP-L-01(empty x5)

This is not an Apple or StoreKit error code. It means:

Five separate Product.products(for:) calls completed without throwing.
Every call returned an empty product array.
The diagnostic appears only after the initial request and limited retries are exhausted.
Thrown StoreKit errors use different diagnostics.
The app does not locally filter a successfully returned product.

Therefore, the screenshot means StoreKit returned no matching product in five consecutive requests. This has happened in multiple review attempts, while the same Release code path works in TestFlight.

An App Review representative contacted us and explicitly stated that a watchOS-only app can be reviewed and tested with IAP. They suggested investigating our StoreKit integration, but our audit found no code path that could transform a non-empty response into this diagnostic.

Submission behavior changed

Earlier watchOS-only builds could be submitted with both:

The app version
The “Full Version” IAP

Those submissions reached App Review, where the product was empty:

Submission accepted → Review starts → Product array is empty

For build 23, we explicitly added the In-App Purchase capability to the Watch target in Xcode. The project now records the IAP capability and explicitly links StoreKit.framework.

This did not add an IAP entitlement to the signed app. The bundle IDs, watch-only packaging, product ID, StoreKit code, pricing, availability, agreements, banking, and tax status remained unchanged.

After uploading build 23, App Store Connect no longer allows the app version and IAP to be submitted together. The draft contains:

iOS App 1.0, build 23
The “Full Version” non-consumable IAP

App Store Connect blocks the submission and says IAPs and subscriptions are not supported on Apple Watch and must be removed from the submission.

The behavior is now:

App version + IAP selected → Submission blocked before review

This timing does not prove that adding the Xcode capability caused the change. App Store Connect may have changed its validation, or the new build may have caused its watch-only classification to be reevaluated. However, the transition is notable: earlier submissions were accepted but the product was unavailable during review; the current submission is blocked entirely.

Contradictory documentation

StoreKit documentation says the Swift IAP API is available on watchOS 8+:

https://developer.apple.com/documentation/storekit/choosing-a-storekit-api-for-in-app-purchases

The documentation for purchase(options:) specifically says to use it for apps running on watchOS:

https://developer.apple.com/documentation/storekit/product/purchase(options:)

However, App Store Connect documentation says IAPs are not supported on Apple Watch and must be removed before submitting an Apple Watch app version:

https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/

The same page says the first non-consumable IAP must be submitted with a new app version.

This creates a circular requirement:

The first non-consumable IAP must accompany an app version.
An Apple Watch app version cannot include an IAP.
A watchOS-only app therefore appears unable to submit its first IAP.

Questions

What is the supported path for submitting the first non-consumable IAP of a watchOS-only app?
Can Apple review the first IAP separately, or apply a backend override, despite the requirement to include it with an app version?
Is an iPhone companion app required, with watchOS IAP support intended only for Watch apps associated with a regular iOS app?
Could the unsupported submission association explain why TestFlight sandbox returns the product while App Review receives an empty array?
Why were earlier watchOS-only submissions accepted with the IAP attached, while build 23 is blocked despite unchanged bundle IDs and watch-only packaging?
Does App Store Connect use the Xcode IAP capability or explicit StoreKit linkage when validating the submission?

Clarification from a StoreKit or App Store Connect engineer would be greatly appreciated. The StoreKit documentation, App Store Connect validation, and guidance from App Review currently describe different behaviors.