A TestFlight build that has sat on Processing for 24 hours has crossed the line Apple's own documentation calls out. In 2026, with the AI-app submission surge stretching App Store Connect capacity, that line is being hit more often, and the right response at 24 hours is different from the one at 12 hours.
Short answer
At 24 hours, Apple's build upload statuses page is the cleanest written source: a build in Processing past that mark warrants a Feedback Assistant ticket or a direct support contact. The cheapest action that often clears it first is still incrementing CFBundleVersion in Xcode and re-uploading on the unchanged short version, but at 24 hours the support path runs in parallel rather than as a follow-on. The 2026 incidents on the Apple Developer Forums (January 13 to 14 for iOS, March 5 for macOS) followed the same shape: a clean upload, no Failed badge, and no system-status alert until traffic forced Apple's hand.
What you should know
- 24 hours is the escalation line Apple documents. Past that mark, the official path is Feedback Assistant or a Developer Support contact, not silent waiting.
- The normal Processing window in 2026 is 10 to 30 minutes. A 24-hour wait is roughly 50 times the median.
- AI-app submission volume has changed the base rate. January 2026 and March 2026 forum threads show batches of stuck builds without Apple system-status alerts.
- Incrementing the build number still clears the largest share of stalls. It does not waste a version slot, because CFBundleShortVersionString stays the same.
- A Feedback Assistant ID is what gets the case acknowledged. Reports without an FB number tend not to surface in Apple replies on the same thread.
- Cancel-and-Increment and Feedback Assistant are not exclusive. At 24 hours, both can run together: the increment buys a fresh artifact pass while support holds the original.
Why does the 24-hour mark matter for TestFlight Processing?
Apple's build upload statuses page lists three states: Processing, Failed, and Complete. The page sets 24 hours as the threshold past which a build in Processing is treated as an anomaly. Apple's written guidance at that point is to file with Feedback Assistant or contact Apple Developer Support. There is no second documented threshold, so 24 hours functions as the boundary between "wait and try a reset" and "log it formally with Apple."
The internal phases inside Processing are not all public, but the documented and observable steps include binary validation, asset extraction, entitlement checks, Privacy Manifest scanning against Apple's published list of SDKs that require required-reason API declarations, export compliance interpretation, and the index into App Store Connect. Past 24 hours, any of these can have failed silently rather than emitting a Failed badge with an error list, which is why the documented response shifts from "increment and re-upload" to "escalate."
What is happening with TestFlight Processing in 2026?
The January 2026 stuck Processing thread on the Apple Developer Forums recorded a batch of iOS builds uploaded on January 13 and 14 sitting in Processing for 10 to 24 hours, with multiple developers reporting the same pattern across different teams. The originating post described a normal Processing window of 10 to 30 minutes, with the affected uploads sitting 50 to 100 times that. Apple's system-status page reported no incident during that period, which mirrors the typical opening days of a capacity incident inside App Store Connect.
The March 2026 macOS Processing thread recorded 8 consecutive macOS builds stuck for more than 80 hours starting March 5, 2026, all under the same app and short version (1.0.0), with the only documented change being CFBundleVersion across builds 431 to 444. The thread carries Feedback ID FB22156358 as the formal report identifier. The pattern is the same: a clean upload, no Failed badge, and a normal 4 to 6 hour Processing window for the platform replaced by an open-ended stall.
These two threads do not prove a single root cause, and Apple has not commented on either thread's mechanism in public. What they do show is that the 2026 base rate for 24-hour Processing stalls is higher than developer guides written before late 2024 assume, and the documented escalation path remains the right one.
Should you file a Feedback Assistant ticket or increment the build number first?
At 24 hours, both. The increment costs minutes; the Feedback Assistant ticket buys a paper trail that is the only thing Apple is documented to act on past the 24-hour mark.
The increment sequence is the same one that clears most 12-hour Processing stalls. App Store Connect indexes builds by the (CFBundleShortVersionString, CFBundleVersion) tuple. A second upload at the same tuple is either rejected as a duplicate or quietly dropped, depending on how far the first upload progressed. Bumping CFBundleVersion in Xcode (and in every extension, app clip, and widget target) and re-uploading creates a new tuple, which gets a fresh Processing pass. Keeping CFBundleShortVersionString unchanged means Beta App Review state on the version is preserved, so external testers do not see a new first-build review on the same release. The codestudy.net writeup on build number conflicts in TestFlight describes the same conflict mechanism developers hit when they try to re-upload at the same tuple.
The Feedback Assistant ticket is what gets visibility from Apple. The minimum useful payload is: the app's Apple ID and bundle identifier, the version and build number stuck in Processing, the upload timestamp from the App Store Connect activity page, the upload method (Xcode, Xcode Cloud, Transporter, or a third-party CI), and a screenshot of the build row in the Builds tab. Without those, replies on forum threads are slow, because Apple staff have no clean way to find the build.
How do you write a Feedback Assistant report Apple can act on?
A Feedback Assistant report that names the build and the upload path moves faster than a generic "TestFlight is broken" report. The structure that has worked on the 2026 forum threads, including the FB22156358 macOS case, is short and factual.
- Title. "TestFlight build [version] ([build]) stuck in Processing for [hours]" with concrete numbers.
- Body opening. State the Apple ID, bundle identifier, app name, and the exact (CFBundleShortVersionString, CFBundleVersion) tuple.
- Timeline. Upload timestamp in App Store Connect time, the time the upload-received email arrived, and the current local time.
- Last known good build. The most recent version and build that cleared Processing, with the same upload path and the same Xcode version.
- What changed. Either "no changes to entitlements, Info.plist, Privacy Manifest, or signing configuration" or a short list of what did change.
- Attachments. A screenshot of the Builds tab showing the stuck row, and the upload log from Xcode if available.
The report becomes the reference number both Apple Developer Support and any forum reply can pivot from. Without one, the case has no handle.
What other states get mistaken for a 24-hour Processing stall?
The Processing stall is one of several states that look similar in App Store Connect at a glance, and treating one as another wastes uploads and time.
| State | What App Store Connect shows | Normal duration | 24-hour interpretation | First action |
|---|---|---|---|---|
| Processing (silent stall) | "Processing" with no Failed badge | 10 to 30 minutes | Past Apple's documented threshold | Increment build number and file Feedback Assistant in parallel |
| Failed | "Failed" with an error list | Minutes after upload | Already documented, not a stall | Read errors, fix in Xcode, re-upload (same build number allowed) |
| Invalid Binary email | ITMS-9000 or ITMS-90562 series email | Within an hour | Build rejected pre-Processing | Resolve cited entitlement or framework issue, re-upload |
| Waiting for Beta Review | "Waiting for Beta Review" | Hours to days in 2026 | Queue wait, not a Processing problem | No action unless expedited is justified |
| Missing Compliance | "Missing Compliance" badge | Until answered | Build sitting on the export compliance form | Answer the export compliance question |
The most common confusion in 2026 is treating a 24-hour Processing wait as a queue delay. Processing happens before review. The flip from Processing to Ready to Test (internal) or Waiting for Beta Review (external) is the signal that the binary cleared inspection. Until then, no reviewer has been involved, and queue remedies like an expedited request do nothing.
What to watch out for
A few 2026-specific traps make 24-hour Processing stalls harder to clear than they need to be.
- Re-uploading at the same build number does not rescue the stuck build. The first stuck upload already owns the tuple.
- Disabling Bitcode is outdated. Apple removed Bitcode from iOS App Store submissions in Xcode 14, and the toggle is gone in current Xcode versions. Guides that recommend the Bitcode fix predate that change.
- A version bump fixes Processing but at a cost. Moving 1.4.0 to 1.4.1 forces a fresh first-build Beta App Review on the new short version and restarts the external testing clock.
- Xcode Cloud with a static build number reproduces the stall. A workflow pinned to a fixed CFBundleVersion will re-upload the same artifact identity. The workflow has to derive the build number from the run count or commit count for the increment trick to take effect.
- System-status silence is not a system-health signal. The January 2026 and March 2026 threads both ran for days before any acknowledgment surfaced.
For builders shipping from FlutterFlow, Bubble, Lovable, or Replit Agent, the upload faults that present as silent 24-hour Processing stalls often originate in the generated entitlements file, the Privacy Manifest the export emits, or a mismatched build number across the main app and an embedded extension. Catching those before upload avoids the cycle of resets at 24 hours. For teams that want an external automated read of their build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS for no-code and AI-coded apps.
Key takeaways
- A 24-hour TestFlight Processing wait in 2026 sits on Apple's documented escalation line, and the response at that mark is the increment-and-re-upload reset together with a Feedback Assistant ticket, not one or the other.
- Feedback Assistant only acts on reports that name the build by Apple ID, bundle identifier, version, and CFBundleVersion, with a precise upload timestamp and the last known good build for comparison.
- App Store Connect indexes builds by the (CFBundleShortVersionString, CFBundleVersion) tuple, so incrementing CFBundleVersion creates a new tuple without resetting Beta App Review or the external testing clock on the version.
- The 2026 AI-app submission surge has raised the base rate of silent Processing stalls, and the system-status page lags real incidents like the January 13 to 14 iOS and March 5 macOS clusters by days.
- Some teams outsource the pre-submission read of their build to platforms like PTKD.com (https://ptkd.com) so the kinds of upload faults that present as 24-hour silent Processing stalls get caught before the binary reaches App Store Connect.
