When a Fastlane upload leaves your IPA stuck in Processing, the binary almost always reached App Store Connect and is now waiting on Apple's side, not Fastlane's. Processing normally finishes in minutes to about an hour, so a wait under an hour is routine. If it sits far longer, the usual causes are an Apple-side backlog, a missing export-compliance key, or an App Store Connect incident. Do not blindly resubmit the same build, because you cannot reuse a version and build number; to upload again you must bump the build number.
Short answer
A stuck Processing status means Apple is validating your uploaded build and has not finished. Per Fastlane's upload_to_testflight action, the tool waits for this processing by default, which is why a CI job appears to hang. Give it up to about an hour, since most builds clear well before that. If it stalls for hours, check Apple's system status, confirm the build appears in App Store Connect, and set the export-compliance key to avoid a silent hold. Resubmitting means uploading a new build with a bumped build number, not resetting a review. Contact support only after several hours with system status green.
What "stuck in Processing" actually means
Processing is App Store Connect's own step after the upload completes, when Apple validates the binary, generates missing dSYMs, and prepares the build for TestFlight or submission. When Fastlane reports the IPA as stuck in Processing, the file has already left your machine or CI runner and reached Apple, so the delay is on Apple's side, not in Fastlane itself.
This distinction matters because it changes what you can do. You cannot make Apple process faster from your pipeline, and re-running the upload step will not help if the build already arrived. The useful actions are confirming the build is visible in App Store Connect and ruling out the specific holds that keep a build in Processing longer than normal.
How long Processing should take
Processing normally takes from a few minutes to about an hour. Most builds clear within ten to fifteen minutes, and anything under an hour is well within the routine range, so a pipeline that waits that long is not stuck in any meaningful sense.
Beyond an hour, you move into territory worth investigating, and beyond several hours something is usually holding the build. Apple does not publish a guaranteed processing time, so treat these figures as typical behavior rather than a promise. A build that has sat in Processing for many hours or overnight is the real signal to act.
Why Fastlane hangs on Processing
Fastlane appears to hang because its upload_to_testflight and pilot actions wait for Apple to finish processing by default, so the step stays open until the build is ready. In a CI pipeline this looks like a frozen job, even though Fastlane is simply polling App Store Connect and waiting for a status it has not received yet.
The fix for the pipeline is different from the fix for the build. If your only problem is that CI hangs, you can tell Fastlane not to wait, which returns control to the pipeline immediately. If the build itself is genuinely stuck in Processing, skipping the wait hides the symptom but does not release the build, so you still need to address the underlying hold.
The upload and processing flow
Knowing exactly where a build sits tells you whether to wait or act. The table below maps each stage from the Fastlane upload to a ready build, with the right action for each.
| Stage | What it means | What to do |
|---|---|---|
| Uploading (Fastlane) | Binary transferring to Apple | Wait; check network and API key |
| Processing (App Store Connect) | Apple is validating the build | Wait up to about an hour |
| Stuck several hours | Apple-side hold or incident | Check system status and compliance |
| Missing Compliance | Export compliance not declared | Set ITSAppUsesNonExemptEncryption |
| Ready to Submit or Test | Processing finished | Proceed with the build |
Read your situation against this flow before doing anything. If the build is visible in App Store Connect and simply Processing under an hour, the correct action is to wait, and any resubmission at that point only creates extra builds you do not need.
Should you wait or resubmit?
Under about an hour, wait. There is no review happening during Processing, so there is nothing to reset and nothing to gain from a new upload; you would only add a second build behind the first. Patience is genuinely the fastest path in the common case.
If the build has been stuck for many hours and you have ruled out a system incident, a fresh upload is reasonable, but it must use a new build number. Apple rejects a re-upload that reuses the same version and build number, so bump the build number first. This is what resubmit means here: a new build that processes from scratch, not a reset of an existing one.
Exact steps to unblock it
Work through a short, ordered checklist rather than guessing. The steps below move from the fastest checks to a full re-upload, so you stop as soon as one resolves the hold.
| Check | Action | Done? |
|---|---|---|
| System status | Check developer.apple.com/system-status | [ ] |
| Build visible in ASC | Confirm the build reached App Store Connect | [ ] |
| Export compliance | Set ITSAppUsesNonExemptEncryption in Info.plist | [ ] |
| Build number | Bump the build number, then re-upload if needed | [ ] |
| CI wait flag | Use skip_waiting_for_build_processing in the job | [ ] |
The single most common real cause is a missing export-compliance declaration, which can leave a build waiting for input instead of finishing. Setting ITSAppUsesNonExemptEncryption in your Info.plist to the correct value for your app removes that prompt and lets processing complete without a manual step.
Cancelling and re-running the job
In continuous integration the answer leans toward waiting, but not by blocking the whole job. There is still no review during Processing, so a second upload gains nothing and only queues another build. What you usually want is for the pipeline to finish while Apple keeps processing in the background.
If a hung job is blocking other work, do not kill and re-run the upload repeatedly, since each run that actually transfers a build adds another item Apple must process. Instead, change how the job waits, which is a configuration fix rather than a new upload. That keeps the pipeline moving without multiplying builds on Apple's side.
Keep CI pipelines from hanging
To stop a pipeline from freezing on Apple's processing, pass skip_waiting_for_build_processing to upload_to_testflight so Fastlane uploads the build and returns immediately. Your job finishes quickly, and Apple continues processing in the background, which is usually what you want in continuous integration.
The trade-off is that later steps which need a finished build, such as automatically distributing to testers, cannot run in the same job. A common pattern is to upload with the wait skipped, then handle distribution in a separate step or a later run once the build is ready. This keeps pipelines fast without pretending a stuck build is done.
When to contact support
Contact Apple after a build has been stuck in Processing for several hours to a day while Apple's system status shows all services operational and you have set export compliance and confirmed the build reached App Store Connect. At that point the hold is on Apple's side and only they can clear it.
When you reach out, include the app name, the version and build number, the upload time, and the steps you already tried. Keep expectations realistic: contacting support is the right move after hours of a genuine stall, but it does not produce an instant release, especially during a broader incident.
Scan the build before you upload
Processing is not where most rejections happen, but a build that clears Processing can still fail review on security or privacy grounds, which sends you back through another upload and processing cycle. Common causes are permissions the app cannot justify, cleartext traffic, or a secret embedded in the binary, and these are cheaper to catch before the pipeline runs.
A scanner like PTKD.com analyzes your .ipa and returns findings ordered by severity and mapped to OWASP MASVS, so you fix them before you upload. To be clear about the boundary: PTKD does not speed up Apple's processing, unstick a hung build, or change your Fastlane configuration. It removes the preventable findings that would otherwise cost you another full upload and processing round after a rejection.
What to take away
- Stuck in Processing means Apple is validating the uploaded build; the delay is on Apple's side, not Fastlane's.
- Processing normally takes minutes to about an hour, so act only after several hours have passed.
- Do not reuse a version and build number; a real resubmit needs a bumped build number and processes from scratch.
- Set ITSAppUsesNonExemptEncryption and use skip_waiting_for_build_processing to unblock builds and keep CI from hanging.
- Scan each build with PTKD.com before uploading so a later rejection does not cost another processing cycle.
