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.