Hi all,
I want to put the raw numbers somewhere public, because after five days of looking at this I still cannot find an explanation that involves anything on my side.
On 2026-08-12, 59 builds across 10 apps on Team ID 8N867LSZDP were marked expired. Not gradually. Inside four seconds:
06:32:56 PDT 22 builds
06:32:57 PDT 9 builds
06:32:58 PDT 18 builds
06:32:59 PDT 10 builds
Those 59 builds were uploaded between 2026-05-09 and 2026-08-11, so their own upload dates have nothing to do with when they died.
The reason I am sure this is not normal expiry is that normal expiry is visible in the same account, in the same export. Twelve other builds expired between 2026-08-07 and 2026-08-11, each exactly 90 days after its own upload, one at a time, the way the documentation describes. Both groups sit in one table. One follows the rule. The other was written in a batch.
It was not only the date, either. buildBetaDetail for all 59 now reports internalBuildState EXPIRED and externalBuildState EXPIRED, so the beta state machine moved with it.
Then the second half, which is the part that actually blocks me. The next day, 2026-08-13, I uploaded two fresh builds to one of the affected apps. App Store Connect is perfectly happy with them:
processingState VALID
expired false
expirationDate 2026-11-11 (correct 90-day window)
internalBuildState IN_BETA_TESTING
internal group hasAccessToAllBuilds = true
tester 1, state ACCEPTED
Installing either one fails instantly, for the tester and for me on my own device:
"Could not install [app]. The requested app is not available or doesn't exist."
App Store Connect says the build is in beta testing. TestFlight says the app does not exist. Two Apple systems reading one record and disagreeing about it. Five days on, nothing has moved: those builds are still unexpired and still uninstallable.
One detail that might narrow this down for whoever ends up looking at it. I have seen the theory going around that this gets triggered by removing external testers. That is not what happened here. This account has never had external testing configured at all. All fifteen beta groups are internal, publicLinkEnabled is null on every one of them, and each group contains exactly one tester, me. There were no external testers to remove. So whatever runs this batch job does not need that trigger.
Checked before posting: membership active, distribution certificate valid through 2027-05-15, provisioning profiles ACTIVE, agreements reviewed, testers removed and re-added, device restarted, app deleted and reinstalled, TestFlight reinstalled, builds re-uploaded twice. Production uploads and App Store review are unaffected, which is what makes this look like the beta path specifically rather than the account as a whole.
Developer Support case 20000136966070. The reply I got linked me to Xcode build configuration documentation and suggested I try DTS. I have asked for escalation. The per-app identifiers and the full 74-build export are already attached to that case, so anyone at Apple who needs the specifics has them without me listing my apps here.
I also filed it in Feedback Assistant as FB24388441 (Developer Tools & Resources, area TestFlight, Incorrect/Unexpected Behavior), with the same export attached. That part I would ask other people to copy. Feedback Assistant groups duplicates and shows a Recent Similar Reports count, and a forum thread has nothing equivalent. If you are stuck on this, filing one takes ten minutes, and it is the only mechanism I have found that turns a pile of separate complaints into something countable.
Thread 813703 carries the same signature going back to January, so this is neither new nor one account.
If anyone has actually come out the other side of this: what changed, and how long did it take?
