Xcode Organizer shows “Upload successful” with a checkmark. Transporter’s status bar reaches 100% and says “Delivered.” You refresh App Store Connect → TestFlight → Builds, and the build isn’t there. Thirty minutes pass and still nothing. You re-archive, re-upload, same result. The Apple ID inbox is silent. You start wondering whether the upload actually went through, or whether some validation step you can’t see rejected it.
Fastest fix (do this first): wait a full 30 minutes, hard-refresh the TestFlight Builds page, then check the uploading Apple ID’s email (including spam) for a message titled “Your app build is invalid” or any ITMS-9xxxx code. As of June 2026, the single most common silent rejection is a missing or invalid privacy manifest (ITMS-91053 / ITMS-91056), which kills the build before it ever shows in the UI but always sends an email. Do not re-upload until you’ve ruled email out, because re-uploading the same build number consumes a slot and changes nothing.
Most of the time the build is in one of three quiet states:
- still in the post-upload Processing phase (it will appear once Apple finishes),
- silently rejected at validation, with the rejection email queued but not yet read, or
- routed to the wrong app record or team, so it’s sitting somewhere you aren’t looking.
Each state has a different fix, and running the wrong fix (usually re-uploading) just adds friction.
Which bucket are you in?
| Symptom | Most likely cause | Go to |
|---|---|---|
| Build shows with status Processing | Normal pipeline delay | Cause 1 |
| Build totally absent + an Apple email arrived | Validation rejection | Cause 2 |
| Build totally absent, no email, multiple teams/App IDs | Wrong app/team | Cause 3 |
| Upload “succeeded” but version/build number already existed | Build-number collision | Cause 4 |
| Account shows agreement/tax/banking warnings | Account hold | Cause 5 |
| Upload over flaky network or corporate proxy | Incomplete transfer | Cause 6 |
Common causes
Ordered by hit rate.
1. Apple is still in the “Processing” phase
After upload, Apple’s pipeline does asset extraction, validation, and dSYM/symbol processing. The build doesn’t appear in TestFlight or the App Store build picker until this completes, and Apple emails the uploading Apple ID when it does. Typical wait is 10-60 minutes. During high-traffic windows (just after WWDC, a new iOS GM, or a major Xcode release) 2-6 hours is normal.
Note that bitcode is gone: Xcode 14 removed it and the App Store no longer accepts bitcode submissions or recompiles binaries on the backend, so the old “waiting for bitcode recompilation” delay no longer exists. Processing is faster than it used to be, which is exactly why a build that’s been “missing” for hours is more likely a rejection than a slow queue.
How to spot it: App Store Connect → TestFlight → Builds. Sometimes you’ll see the build listed with status Processing rather than missing entirely. If it’s truly missing, wait 30 minutes and refresh before assuming worse.
2. Build was silently rejected at validation
After upload, Apple runs static analysis on the binary. Failures (missing Info.plist keys, unsupported architectures, banned APIs, an entitlement that doesn’t match the App ID, or a missing privacy manifest) send an email with a subject like “App Store Connect: Your app build is invalid”, but the build itself never enters App Store Connect’s UI. The email can take 5-30 minutes to arrive.
As of June 2026 the dominant rejection in this bucket is the privacy manifest requirement: since 1 May 2024, Apple rejects any build that calls a required-reason API (categories like NSPrivacyAccessedAPICategoryUserDefaults, FileTimestamp, SystemBootTime, DiskSpace) without declaring the reason in a PrivacyInfo.xcprivacy file. This often comes from a third-party SDK you don’t control, not your own code.
How to spot it: Check the uploading Apple ID’s email (including spam) for an “invalid” message. Common codes:
| Code | Meaning |
|---|---|
ITMS-91053 | Missing API declaration (required-reason API not declared in privacy manifest) |
ITMS-91056 | Invalid privacy manifest |
ITMS-90161 | Missing/invalid entitlements |
ITMS-90201 | Invalid binary |
ITMS-90685 | CFBundleIdentifier collision (duplicate bundle ID inside the app) |
The only path forward for a rejection is to fix the cited issue, bump CFBundleVersion, re-archive, and re-upload. The rejected build number is burned.
3. Uploaded to the wrong app record or team
You have two App IDs (production + dev) and Xcode picked the dev one because of scheme or signing config. Or your Apple ID is a member of two teams and the upload went to the secondary team. The build is in App Store Connect, just not where you’re looking.
How to spot it: In App Store Connect, open the team/account switcher (top-right account menu in the current UI) and switch to each team you belong to. For each team, check Apps and Activity → All Builds. Verify the Bundle ID in your archive matches what App Store Connect expects for the app you think you uploaded to.
4. Build number collides with an existing build
Within a single version string (CFBundleShortVersionString), each build number (CFBundleVersion) must be unique. If you upload 1.2.3 (42) and an earlier 1.2.3 (42) already existed (even if it was discarded), Apple may accept the transfer but discard the duplicate with no UI feedback.
How to spot it: Check Activity → All Builds for any prior (42) under 1.2.3. The fix is simple: always bump the build number before each upload.
5. Agreements, banking, or tax holding back processing
The whole account is held if the Paid Apps agreement is outdated, tax info has expired, or banking is invalid. The upload can succeed at the transfer layer while Apple silently parks the build.
How to spot it: App Store Connect → Business → Agreements, Tax, and Banking. Any status that isn’t Active can block processing.
6. Transporter or Xcode reported “success” but the transfer was incomplete
A network blip mid-upload, or a corporate proxy stripping headers, can let the client report success while Apple receives nothing usable. The binary was sent but never registered.
How to spot it: Re-upload with Transporter (the free Mac App Store app), which surfaces more transparent error messages than Xcode Organizer, and watch for any warning lines after “Delivered.”
Information to collect
- Exact upload timestamp and the tool used (Xcode Organizer / Transporter /
xcrun altool/ App Store Connect API). - The uploading Apple ID and which teams it belongs to.
- The archive’s Bundle ID, version (
CFBundleShortVersionString), and build number (CFBundleVersion). - Any Apple email mentioning your app since the upload, including
ITMS-codes. - App Store Connect → Activity → All Builds for the affected app.
Shortest path to fix
Step 1: Wait 30 minutes, then hard-refresh
App Store Connect’s UI doesn’t auto-update reliably. After 30 minutes, hard-refresh (Cmd+Shift+R in Safari/Chrome) the TestFlight → Builds page, and also refresh Activity → All Builds.
Step 2: Check the uploader’s email
Search the inbox of the Apple ID that uploaded, covering the past 24 hours. Look for:
- A subject containing “Your app build is invalid” or “App Store Connect”.
ITMS-9xxxxcodes in the body (see the table above).- Specific complaints, e.g. “missing UIApplicationSceneManifest” or a named privacy-manifest category.
Spam folders catch these more often than you’d expect. If an email exists, you have a rejection (Cause 2), not a slow queue, and re-uploading the same build will not help.
Step 3: Verify Bundle ID, version, and build number
Open the archive’s Info.plist (Xcode → Organizer → right-click archive → Show Package Contents → Products/Applications/MyApp.app/Info.plist), or read it from the command line:
plutil -p MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist \
| grep -E "BundleIdentifier|BundleVersion|BundleShortVersionString"Compare against App Store Connect → App Information → Bundle ID. Any mismatch (a typo, or a .dev suffix vs none) means the build went to a different app record.
Step 4: Check the right team and app
Open the account/team switcher (top-right in the current App Store Connect UI) and loop through every team your Apple ID belongs to. For each, check Apps and Activity → All Builds. The build may have landed in a sibling project under a different team.
Step 5: Bump the build number and re-upload via Transporter
If the build is truly missing and you’ve waited 60 minutes with no email:
- In Xcode, increment
CFBundleVersion(e.g.42→43). - Archive again.
- Open Transporter, drag the new
.ipain, and click Deliver. Transporter reports validation errors more clearly than Xcode Organizer.
Or from the command line. As of June 2026 xcrun altool is still supported for App Store uploads (note: altool is deprecated only for notarization, where notarytool replaces it, not for App Store delivery):
# Validate first so you don't burn a build number on a known-bad binary
xcrun altool --validate-app -f MyApp.ipa -t ios \
--apiKey "$ASC_KEY_ID" --apiIssuer "$ASC_ISSUER_ID"
xcrun altool --upload-app -f MyApp.ipa -t ios \
--apiKey "$ASC_KEY_ID" --apiIssuer "$ASC_ISSUER_ID"--validate-app runs Apple’s static checks and surfaces the same ITMS- errors before the upload consumes a build number. (App-specific-password auth via -u/-p still works, but App Store Connect API keys are the more durable option.)
Step 6: Confirm in App Store Connect
After upload, wait 10-30 minutes and check App Store Connect → TestFlight → Builds. The new build should appear with status Processing and then move to Ready to Submit (or Missing Compliance, which just needs the export-compliance answer).
How to confirm it’s fixed
- The new build appears in App Store Connect → TestFlight → Builds with the expected version and build number.
- Status transitions from Processing to Ready to Submit within an hour.
- The uploading Apple ID receives Apple’s “processing complete” email.
- The build is selectable in the App Store → Build picker for submission.
If it still fails
- Run
xcrun altool --validate-appbefore the next real upload to surface validation errors locally. - Check Apple’s System Status page for TestFlight or App Store Connect incidents; outages can park uploads.
- Inspect the IPA manually for missing entitlements:
unzip MyApp.ipa -d Inspect/
codesign -d --entitlements - "Inspect/Payload/MyApp.app"- Check whether a third-party SDK is the source of the privacy-manifest rejection. Apple documents the required-reason API rules in Describing use of required reason API.
- As a last resort, file App Store Connect support with the upload timestamp, the Apple ID used, and the Bundle ID. They can confirm whether the upload actually landed.
FAQ
How long should I wait before assuming the build is lost? Sixty minutes during normal traffic. The pipeline is faster since bitcode was removed, so anything still missing after an hour is much more likely a rejection (check email) than a slow queue. During WWDC week or a new iOS GM, allow 2-6 hours.
The upload said “Delivered” but I got no email at all. What now? “Delivered” only means the bytes reached Apple, not that the build was accepted. No email after an hour usually means Cause 3 (wrong team/app) or Cause 6 (incomplete transfer). Switch teams, check Activity → All Builds in each, and if still nothing, re-upload via Transporter and watch its log.
I got ITMS-91053. Why, when I didn’t change my privacy code?
Required-reason API enforcement (since 1 May 2024) inspects your whole binary, including third-party SDKs. A dependency bump can introduce a call to a required-reason API. Update the SDK to a version that ships its own PrivacyInfo.xcprivacy, or add the declaration yourself, then bump CFBundleVersion and re-upload.
Can I reuse the same build number after a rejected upload?
No. Once a build number is consumed (even by a rejected upload), Apple won’t accept it again under that version string. Always increment CFBundleVersion.
Do I still need to download dSYMs from App Store Connect? No. Since Xcode 14 removed bitcode, Apple no longer recompiles your binary, so the dSYMs in your local archive are the final ones. Download them from the archive, not from App Store Connect.
Prevention
- Always bump the build number before each upload; configure CI to auto-increment
CFBundleVersion. - Run
xcrun altool --validate-appas a pre-upload CI step so issues (including privacy-manifest gaps) fail loudly before the binary reaches Apple. - Audit third-party SDKs for
PrivacyInfo.xcprivacycoverage before adopting or upgrading them. - Keep Agreements, Banking, and Tax status green; check monthly.
- Use Transporter for production uploads; its error reporting is clearer than Xcode Organizer’s.
- Subscribe to Apple Developer email notifications for the account so processing rejections are seen quickly.