Your Rork App Is Stuck on "Processing" in App Store Connect — A Field Guide to Getting It Unstuck

The upload bar hits 100%, you see "successfully delivered," and then... nothing. You open the TestFlight tab in App Store Connect and the build simply isn't there. The status reads "Processing," and thirty minutes later it still reads "Processing." An hour later, still nothing. Running several apps in parallel, I have been stuck at exactly this screen more than once.

What makes it frustrating is the silence. The upload succeeded, so there is no error message pointing you anywhere. The build just quietly stays in Processing, and the submit-for-review button stays out of reach.

This guide walks through what I actually do when an app exported from Rork (the React Native / Expo flavor) or Rork Max (the native Swift one) gets stuck processing in App Store Connect — the order I diagnose it in, and how I fix each cause. These are only the routes I have personally gotten unstuck on, not generic theory.

First, separate the two kinds of "Processing"

The thing to internalize up front is that "Processing" actually covers two very different internal states.

The first is the normal one: Apple's servers are unpacking and validating the binary you sent. That usually finishes in 5–15 minutes, or up to 30 when things are busy. Right after a new Xcode or SDK release, uploads from all over the world pile up, so the queue genuinely gets longer.

The second is the one that hurts: validation found a problem, and Apple treats it not as an outright rejection but as a silent stall. The status sits on Processing indefinitely, or the build quietly disappears a few hours later. With Rork-exported apps, the cases that bit me were almost always this second kind.

So the first move is a judgment call: if it hasn't changed after 30 minutes, it is not a normal queue. Waiting longer won't fix it, so switch to finding the cause.

Check your registered email and the build's "Activity"

Even when nothing shows on screen, Apple often emails the person on the account when it finds a problem. More than once, my TestFlight tab showed nothing while my inbox already held a message from "App Store Connect" spelling out the exact rejection reason.

Here is the order I check.

First, look at the inbox — and the spam folder — of the email registered to your Apple Developer account. Then in App Store Connect, open the app → TestFlight → the build's Activity, and the notification bell in the left menu. If an email arrived, it will name either an ITMS error code or an Invalid Binary reason.

If you find your cause here, you can skip the rest. Only move on if nothing arrived.

Cause 1: Missing encryption export compliance

This is the one I have hit most often with Rork-exported apps. An app counts as "using encryption" merely by talking over HTTPS, which triggers an export compliance declaration. When that declaration is missing, the build tends to stall in Processing.

The permanent fix is to bake the declaration into app.json (Expo) or Info.plist (Swift). If your app only uses standard encryption (HTTPS), this one line frees you from being asked at every single upload.

For Expo (app.json):

{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}

For Swift, add the key directly to Info.plist:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

You may set this to false only if you have not implemented your own custom encryption and rely solely on the OS's standard HTTPS and standard crypto APIs. If your app ships proprietary encryption, do not casually set false — check Apple's export compliance requirements first. With this line in place, future uploads are far less likely to stall, and you skip the manual declaration each time.

Cause 2: A missing, transparent, or wrong-sized icon

Stuck on Processing, then the build silently vanishes a few hours later — one cause I tracked down for this pattern was the icon. If your 1024×1024 App Store icon contains an alpha channel (transparency), validation rejects it. No on-screen error appears; the build just never shows up.

You can check this with one command. To see whether the icon has transparency, run:

# Check whether the icon contains an alpha channel
sips -g hasAlpha AppIcon-1024.png
# If the output says "hasAlpha: yes", transparency is still present

If transparency remains, re-export the icon flattened onto an opaque background such as white:

# Flatten transparency onto a white background and produce an opaque PNG (ImageMagick)
magick AppIcon-1024.png -background white -alpha remove -alpha off AppIcon-1024-fixed.png

If you're on Expo's managed workflow, make the source image referenced by ios.icon in app.json opaque, and the build will generate a correct icon set. Rork's auto-generated placeholder icons sometimes keep their transparency, so I always swap them out before publishing.

Cause 3: A duplicate build number

You cannot upload the same version × build number combination twice. Yet the upload itself can still succeed and appear to hang in Processing — when in reality the build collided with an existing one and was discarded.

To avoid this, I keep the build number strictly increasing. With Expo's EAS Build, remote auto-numbering is the reliable setup:

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

If you manage numbers by hand, check the latest build number in App Store Connect before uploading and always go higher. When you bump the version, resetting the build number to 1 is fine — but never duplicate a build number within the same version.

Cause 4: A "silent rejection" from missing dSYMs or an invalid binary

The last pattern, where processing drags on and the build then disappears, is the binary failing validation itself. A missing dSYM for crash collection, or an unsupported architecture slipping in, leads Apple to mark it invalid. Often you get an email; sometimes you don't.

What helps here is validating locally before you upload. Once the .ipa exists, running it through altool gives you the same kind of validation result without waiting on App Store Connect:

# Validate the binary locally before uploading
xcrun altool --validate-app \
  -f build/MyApp.ipa \
  -t ios \
  --apiKey "YOUR_KEY_ID" \
  --apiIssuer "YOUR_ISSUER_ID"

If this returns an error, you learn the cause before spending hours watching Processing. Since I started adding this one validation step to my release flow, the "I uploaded it but it vanished" incidents have nearly disappeared. Even when export-to-submit is fully automated — as with Rork Max's two-click publishing — it's reassuring to leave room to validate the generated .ipa once on your own machine.

When it still won't budge

If none of the causes above apply, no email arrives, and it has still been processing for over an hour, suspect a genuine delay on Apple's side. Right after a new iOS or Xcode release, builds from around the world stack up and processing really can take hours.

My approach here is simple. First, check Apple's System Status page to confirm "App Store Connect" and "TestFlight" are operating normally. If there's a reported issue, waiting is the only option. If everything is green and it hasn't moved in over three hours, do not re-upload the exact same build — it'll be rejected as a duplicate. Bump the build number by one, rebuild cleanly, and upload that. That clears most cases.

What to do next

If you're stuck on Processing right now, start by checking your registered email, then confirm the encryption export compliance declaration (usesNonExemptEncryption: false) is present in your app.json or Info.plist. In my experience, more than half of the Processing stalls with Rork-exported apps come down to that single line.

I hope this gives you the shortest way out if you're stuck at the same place.