TestFlight build stuck processing: what to check

If your TestFlight build is stuck processing, first check the exact upload status in App Store Connect. Apple says a build that stays in Processing for more than 24 hours may have an issue and recommends contacting support or submitting a Feedback Assistant ticket. That is an escalation point, not a promised processing time. Apple's build upload statuses explain the distinction.

Before rebuilding, find out which step is holding things up. A successful upload, a processed build, and a build available to testers are three different milestones. The next action depends on which one you have reached.

The steps below follow Apple’s documentation. We did not test them against a live stuck upload.

Start with the status, not another upload

Open App Store Connect → Apps → your app → TestFlight. Select the right platform, then expand Build Uploads. Check the version and build number against your upload log. Select the status to inspect its details. Apple documents this view in View builds and metadata.

Use the table below to choose the next check. The first three rows describe upload progress; the remaining rows describe the build's testing state.

What you see	What to check next
Processing	Wait and monitor this upload; escalate to Apple if it remains here for more than 24 hours.
Failed	Open the upload details, fix the reported errors, then re-upload.
Complete	Check the build's testing status and any warnings.
Missing Compliance	Provide the required encryption information.
Waiting for Review or In Beta Review	Follow the TestFlight review process.
Ready to Submit	Check internal distribution or submit for external testing.
Ready to Test	Check the tester group and distribution action.
Expired	Select a newer build; the testing window has ended.

Apple's app build status reference defines the testing states. Avoid treating every unavailable build as a processing delay.

Confirm that the upload reached the right app

A green CI job is useful, but read what that job actually completed. Was it building the archive, delivering it to Apple, or waiting for processing afterward? Keep the upload tool's final response with the job log.

Apple uses the bundle ID and version number to associate an upload with an app and version record. The build string identifies the build. Processing happens after delivery, before the build appears for use. See Apple's upload guide.

Compare these values before changing anything:

• The Apple team selected by your upload tool.
• The bundle ID of the archive you delivered.
• The version and build number in the upload log.
• The platform and app record open in App Store Connect.

For example, suppose your pipeline uploaded version 2.4.0, build 108, but you are looking at build 107. That older build cannot tell you whether the new upload finished. This is an illustrative example, but keeping the identifiers together prevents a surprisingly unhelpful investigation.

If you cannot find the upload, keep its delivery result. “Build missing after upload” gives support a different starting point from a visible row that has remained in Processing.

How long does TestFlight processing take?

The Apple status guidance linked above does not promise that every upload finishes within a few minutes. It identifies more than 24 hours in Processing as a reason to escalate. A forum report about a ten-minute upload is not a deadline for your next build.

While you wait, check Apple Developer System Status for incidents affecting App Store Connect or TestFlight. A reported incident is relevant context. A green status page, by itself, does not explain or rule out a problem with one upload.

Set a specific time to check again and give one person ownership of the follow-up. Save the upload time with its time zone. “Still processing since 09:10 UTC” is more useful to the next person than “it has been a while.”

If the upload changes to Failed, stop investigating queue time. Open its error details. Apple says to resolve the errors before uploading again and permits reuse of the build number when the upload fails. That exception does not mean you should repeatedly send an unchanged build that is still processing. Build upload statuses covers the failure case.

Fix Missing Compliance separately

Missing Compliance needs information from your team. Waiting longer will not supply it.

Open the affected build in TestFlight, choose Manage beside the compliance notice or Provide Export Compliance Information, and answer the questions for your app. Apple's flow can also use previously approved documentation. The required role is Account Holder, Admin, or App Manager. Follow Apple's beta-build compliance instructions.

Do not copy an encryption declaration from another app to make the warning disappear. Ask the person responsible for the app's encryption use to verify the answers. If documentation is required, follow the linked Apple process.

Apple also describes how the correct encryption settings in Info.plist can prevent repeated questions on later submissions. Set them from the app's actual encryption use; a blanket setting is not a troubleshooting fix.

If processing finished but testers cannot install

Once the upload has completed, check distribution rather than starting the processing investigation again.

For internal testing, open the intended group and confirm that this build was added. Automatic distribution depends on the group's settings; otherwise builds need to be added manually. Apple also notes that Xcode Cloud builds must be added to groups manually. See Add internal testers.

For external testing, check both review and distribution. Apple's external-testing instructions say the first submitted build requires a full review; later builds for the same version might not. If automatic notification was left off, the approved build still needs manual distribution. A build uploaded as TestFlight Internal Only cannot be added to an external tester group. These are separate checks in Invite external testers.

Then verify the tester's actual experience. Ask them to confirm the version and build number they can install. “The build is approved” and “the intended testers have this build” answer different questions.

What to send Apple when processing stays stuck

For an upload beyond Apple's escalation point, use Feedback Assistant or Apple Developer Support. Apple's build-metadata guide identifies Developer Tools & Resources → TestFlight for the Feedback Assistant report and asks for version/build numbers, upload date and time, and relevant logs.

Prepare a short timeline before opening the ticket:

• Build identity: app, platform, version, and build number.
• Delivery: upload tool, completion time, time zone, and its final result.
• Current observation: exact visible status and when you last checked it.
• Evidence: relevant delivery logs and a screenshot of the affected row.
• Scope: whether you have observed the same issue on other uploads.

Separate observations from guesses. “Upload accepted at 09:10 UTC; the same row still shows Processing the following day” is actionable. “Apple rejected our build” is a different claim and needs a rejection message.

Remove credentials, tokens, private keys, and unrelated personal data from attachments. Keep the original logs in your team's controlled storage so the evidence remains available if support needs another detail.

Keep the build connected to the release

During a delay, leave your team a useful release note: the source commit, version/build number, upload result, current Apple status, owner, and next check time. A teammate should be able to continue from that note without rebuilding the timeline from chat.

Specita brings source changes, reported deliveries, and available quality signals into one workspace. Its current App Store Connect integration supports app discovery and mapping; it does not synchronize TestFlight processing or review status or speed up Apple's queue. Check those states directly in App Store Connect.

For connection setup, use the App Store Connect guide. If you are choosing a credential, read individual vs team API keys. Once testers can install the build, use the post-deployment checklist to review what actually works.

Apple guidance checked on October 20, 2026.