Thank you for the clarification — but with respect, this answer raises a much bigger problem than it solves. If "internal only" builds cannot be attached to app versions, why are they shown as selectable options in the build picker in the first place? Your own UI presented build 2 as a valid candidate, let us select it, and then failed silently with a generic 409 error in the network layer. No inline error message. No badge or label on the build indicating it was ineligible. No tooltip. Nothing in the visible UI explaining why the attach was failing. We — and apparently other developers, given that you said "thank you all for the reports" — spent hours debugging this. We checked export compliance, re-verified processing status, hard-refreshed, cleared caches, re-archived builds, opened DevTools to inspect network traffic, and combed through documentation. All of that time and effort was wasted because App Store Connect surfaced an ineligible build as if it were eligible and then refused to attach it without explanation. For a small team, that's real money lost on engineering time, plus a delayed release that affects revenue. This is a trivially fixable UX problem. App Store Connect already knows a build is internal-only at upload time. It should either: Filter internal-only builds out of the version attach picker entirely, or Disable them in the picker with a clear label like "Internal distribution only — not eligible for App Store submission," or At minimum, return a human-readable error in the UI when the attach attempt fails, instead of a silent 409 that only surfaces in DevTools. Please escalate this to the App Store Connect team as a UX bug. Silent failures on a critical submission workflow are not acceptable on a platform that thousands of businesses depend on for their livelihood. We expect better from Apple.

yes, I have the same error. Anyone knows how to fix this?

Despite implementing this precise strategy, the app was still rejected by Apple.

My app has faced repeated rejections due to Apple's insistence on using their in-app purchase and subscription service. This requirement has posed significant challenges in management, especially considering that I utilize Stripe on the website, which offers seamless integrations perfectly suited to our needs. However, on the iOS app, we are mandated to adopt an entirely different system, which complicates matters unnecessarily.