TestFlight install fails with "Error Downloading Install Data" on every build, across two app records

Question

Created 10h

Replies 1

Boosts 0

Participants 2

Since 27 August 2026, no TestFlight build of ours installs. The build appears in TestFlight with the correct version and size, marked compatible with the device, and tapping Install produces "The requested app is not available or doesn't exist." — then a second dialog, "Try again later", whose View button does nothing.

The device log says what the dialog does not. Captured over usbmuxd while tapping Install:

TestFlight: [io.sharefold.app;<appId> <buildId> 1.0.1 (15)] installing: Install Request Created: Starting install for bundleID (io.sharefold.app) FAILED: TFBundleInstallation for io.sharefold.app Claiming Next PostInstallStatusJob ... terminalReason: 1, failureReason: Error Downloading Install Data

It never reaches the bundle. It fails while fetching install data.

WHAT MAKES THIS DIFFERENT FROM THE USUAL CHECKLIST

The same log contains its own control. While our install was failing, that same iPad, on that same network and that same Apple Account, was downloading other apps from the App Store normally. Another developer's TestFlight beta installs on it too. So the device, the account, the network and TestFlight itself all work; only our team's builds fail.

We also rebuilt every input we control, and it changed nothing:

New certificate signing request and new Apple Distribution certificate; the previous one revoked.
New App Store provisioning profile, decoded and checked before use: no provisioned devices, get-task-allow false, correct team and app id.
New App Store Connect API key. New Sign in with Apple key.
Upload succeeded ("UPLOAD SUCCEEDED with no errors"), build processed, marked Ready to Submit, assigned to the internal group. Still will not install.

And then the test that we think settles it: we created a second app record with a new bundle identifier, no capabilities on its App ID and no entitlements in the binary, no pricing or availability configured at all, signed it with a profile of its own, and uploaded it. It fails identically, same two dialogs, same log line.

Two app records. Two bundle identifiers. Two Apple Accounts. Two devices. One failure.

ACCOUNT STATE, ALL VERIFIED THE SAME DAY

Free Apps Agreement active. DSA trader status declared and active. Pricing and Availability set, 175 territories, base country set, not removed from sale, distribution Public. ITSAppUsesNonExemptEncryption false, so nothing is held for export compliance. Membership paid and current. Both testers are members of the account under Users and Access, not only TestFlight invitees. Apple's System Status reports every service operating normally.

One more symptom, possibly the same cause: adding any build to an external testing group fails at both steps of the dialog with "There was an error processing your request. Please try again later."

WHAT I AM ASKING

Has anyone seen "Error Downloading Install Data" specifically, and did anything on the developer's side ever resolve it? Every thread I can find on the visible symptom ends with the developer being directed to Developer Technical Support, and no fix recorded.

We have correlation keys from four failed attempts across both app records and can supply them to anyone from Apple who can look the requests up. A support case is open.

For anyone arriving here with the same symptom: an Ad Hoc profile plus ideviceinstaller over USB bypasses this entirely and let us keep developing. It does not diagnose anything, but it unblocks the day.

Answer 1

notbetting OP

6h

adding any build to an external testing group fails at both steps of the dialog with "There was an error processing your request. Please try again later."

That line is the diagnosis, and I think it is more useful than the install failure.

Those two symptoms together — internal installs dying at Error Downloading Install Data, and external groups refusing builds with a generic error — are the known signature of the TestFlight beta contract getting detached from the account on Apple's backend. It is not your signing chain, and your own evidence already rules that out better than any checklist: two app records, two bundle IDs, two accounts, fresh certificates and profiles, and another developer's beta installing on the same device.

There is a long-running thread on it: https://developer.apple.com/forums/thread/814565 — going since February, around 30 developers, all of them with agreements showing Active and nothing pending. The contract is read-only from outside; you cannot repair it yourself.

Confirm it in one request. The web UI hides the real error behind "try again later". The API does not. Try adding the build to the external group, or creating the beta review submission, through the App Store Connect API instead:

POST /v1/betaAppReviewSubmissions with the build id, or POST /v1/betaGroups/{id}/relationships/builds

If it comes back 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING, that is it, and you now have a concrete error string to put in front of support instead of a screenshot of a generic dialog.

Every thread I can find on the visible symptom ends with the developer being directed to Developer Technical Support, and no fix recorded.

One route has a recorded fix, and it is not the support email: Feedback Assistant, with a HAR capture of the failing request including response headers, plus every affected App ID. Reported resolution in a couple of days. The email path is where these go to die — DTS cannot re-provision a contract either, which is why those threads all end the same way.

Ask for it in those words: re-provision / re-attach the TestFlight beta contract on the backend. A DTS engineer confirmed in that thread that this is how it gets fixed, and that you should upload a fresh build about 48 hours after — expired builds do not come back.

Worth knowing before you celebrate: it has recurred for several people days or weeks later, so keep the case number.

And thanks for posting the Ad Hoc plus ideviceinstaller workaround. That is the part most of these threads are missing.