Did you declare IAP capability in Xcode?

Same here.

I have new evidence from BABANE 1.0.3 build 15 and a confirmed recovery procedure. Before cleanup, the TestFlight build successfully fetched and installed the Apple-hosted asset-pack manifest. macOS reported that pack-hy-mt2-ane-lut4mixed was scheduled or currently downloading, but the app received no Background Assets status callback. After 60 seconds, the app reported BA_NO_STATUS_TIMEOUT. Reset Download then used the public cancellation and per-pack removal APIs. Removal failed with “No record of the asset pack with the global ID was found.” A new availability request was subsequently accepted and scheduled, but again produced no status callback and timed out after 60 seconds. An ordinary restart had not resolved the problem previously. The issue was finally cleared by this exact sequence: Quit BABANE. Uninstall BABANE. Restart the Mac before reinstalling or launching another copy. Reinstall the same TestFlight build. Start one normal download. After this sequence, the same build and asset pack succeeded on the first attempt. The new debug log confirms: All six runtime configuration checks passed. Asset-pack lookup returned version 3. A new system download was created. The app received waiting, progress, and finished status updates. The approximately 1.6 GB pack downloaded and extracted in about 67 seconds. Model compilation completed in approximately 895 ms. Installation completed successfully with no BABANE lifecycle error. This new A/B result strengthens the hypothesis that the failure was caused by persistent, inconsistent Managed Background Assets state associated with the previous app installation. The upper managed database reported no removable record, while the lower system layer still treated the pack as downloading or scheduled. Please investigate whether per-pack removal or app uninstall can leave an orphaned underlying download. A supported per-app API for inspecting and clearing this state would also be helpful. I have uploaded relavent logs to FB24301118

It still fails on macOS 26.6.2

The App is BABANE https://apps.apple.com/us/app/babane/id6795485067

Seeing the same thing here. macOS app, build uploads and processes fine in App Store Connect, tester group/compliance are all correct, but tapping Install in TestFlight fails with a generic "Unavailable, please retry." Older builds of the same app still install without issue — it's specifically new builds that hit this. Spent a while ruling out app-side causes (signing, entitlements, provisioning profile) before finding this thread — sounds like this is server-side (HTTP 500 from Apple's TestFlight backend per the OP's console logs), not something we can fix from our end. Filed FB24046190 for this; adding it here in case it helps Apple correlate reports. If others haven't filed yet, worth doing so and posting the number — more linked tickets tend to get more attention. Anyone found a workaround, or has Apple acknowledged this on FB24059381 or FB24046190?

Same failure signature here, independent app, adding a data point since this thread seems to be the closest match I could find. App: Safe Cracker, Bundle ID com.seanfu.safe.watchkitapp (watchOS-only), Team 574P9Q3HG7. IAP: com.seanfu.safe.fullversion (non-consumable, $1.99), currently Rejected in ASC after two review rejections that both cite the IAP failing to load ("failed to load even after we tapped Retry"). TN3186 checklist: fully verified — explicit App ID with IAP capability, valid signing, active membership, Paid Apps Agreement active, banking and tax active, price/localization set, no StoreKit Configuration file attached to the build under test. Symptom: Product.products(for:) returns an empty array with no error (storefront resolves correctly, e.g. USA). This reproduces both for App Review (per the rejection notes) and for my own sandbox testing under certain conditions. New data point I can add: I built a minimal 3-call repro project (same bundle ID/team, only Product.products, currentEntitlements, and AppStore.sync() — no third-party SDK). On that repro, AppStore.sync() returns userCancelled after the sandbox password prompt is completed successfully — i.e. authentication finishes, but sync still reports userCancelled. That doesn't match the literal meaning of "user cancelled" and looks like an internal failure being mis-surfaced. Also tracked, closer to what @toyoyo found: in my case, the empty-products result correlates with the IAP's ASC status. With the IAP in "Rejected," Product.products(for:) returns 0 for my own sandbox device; within minutes of resubmitting for review (moving it out of Rejected), the same query on the same device returns 1 product correctly. But that alone doesn't explain the App Review failures, since the rejection emails show the IAP had its own review section (i.e. it was not Rejected) at the time review tested it and still failed — so ASC status isn't the whole story on Apple's side either. Given how many independent reports are stacking up in this thread with TN3186 fully exhausted, is this something the App Store Commerce Engineer team can escalate as a known backend issue rather than case-by-case Feedback Assistant reports? Happy to file FB + sysdiagnose if that's still the preferred channel — just noting the pattern in case it saves round-trips.

I encountered the same issue when submitting a watchOS app. Although I later realized I needed to include IAP with the app in the submission. Yet, they still rejected me with 2.1(b), claiming that IAP cannot be purchased. However, purchasing via a sandbox account in TestFlight works fine, and I also submitted the recording.

I am developing a watchOS app with IAP functionality. While it works fine in the sandbox, the reviewer consistently says it cannot be purchased.