Three App Store rejections in one release, and how we cleared them

Many clients assume that "shipping to the App Store" means uploading a build and waiting for review. Anyone who has run the full release pipeline knows that finishing development is only the beginning. Account verification, certificates and provisioning profiles, server-side upload rejections, agreement updates, privacy manifests — any one of these can leave a build stuck in the "Waiting for Review" state indefinitely.

What follows is not theory. It is a record of three rejections we hit in a single real delivery.

Three rejections in one submission

The project was a pair of apps for a manufacturing client. The build archived cleanly on our machines, but the actual submission produced three failures in a row:

1. ITMS-90809 — UIWebView deprecation. This is an automated check. If the binary still contains any reference to UIWebView, the build is rejected.
2. Code 90068 — the deployment target (MinimumOSVersion) was not accepted. Apple's servers rejected the upload outright; the build never even entered the review queue.
3. ITMS-90717 — the icon contained an alpha channel. The 1024-pixel App Store icon must be exported without transparency.

Of the three, the second is the easiest to misdiagnose as a local build problem, the third is trivial to fix, and the first was the genuinely hard one.

Rejection 1: a binary SDK with no source code

Fixing a UIWebView rejection usually has two layers. The first is your own code and any open-source bridge layers, where references can be replaced one by one. The second layer is third-party binaries — and in our case, one third-party SDK shipped as a source-less .framework that referenced _OBJC_CLASS_$_UIWebView directly.

The conventional options were limited: wait for the vendor to ship an updated SDK, or replace the SDK entirely. The vendor had stopped updating the library, so waiting was not realistic; replacing it meant rebuilding the features it provided.

We took a third path: equal-length binary patching. Before describing it, two premises must be clear. We did this with the client's agreement, and only because the SDK vendor is no longer updating the library. It was a temporary workaround; upgrading or migrating away from the SDK remains the recommended long-term fix, and we documented exactly that in the delivery notes.

The idea itself is not mysterious. A class-name reference like _OBJC_CLASS_$_UIWebView inside a Mach-O binary is a fixed-length string. If you substitute a self-built class name with exactly the same byte length, the file size and the symbol table structure stay unchanged, so the code signature is not broken. In practice that meant:

• Replace _OBJC_CLASS_$_UIWebView with an equal-length self-built class name — the replacement string had to match the original byte for byte.
• Patch both supported CPU architectures; patching only one leaves the rejection in place.
• Back up the original file and record its SHA256 before modifying anything, then re-check with nm -u after the patch to confirm zero remaining UIWebView symbols.

The value of this exercise was not technical showmanship. It converted an uncontrollable external dependency into something we could handle ourselves. It does demand a solid understanding of the Mach-O symbol table, and it carries a maintenance cost: every time that SDK is upgraded, the patch has to be re-examined. Both points were stated explicitly in the handover documentation.

Rejection 2: an error only a real upload reveals

The message for code 90068 was blunt: MinimumOSVersion '12.0' is not acceptable.

The trouble was that this came from Apple's servers. Local archive, export, and validation all passed; Xcode gave no warning at any earlier step. Only the actual upload was refused. Teams that have never pushed a real build often discover this only when the client starts asking about progress.

Rejection 3: the icon that passed everywhere else

ITMS-90717 — an alpha channel in the marketing icon — is a one-flag export fix. It is worth mentioning only because it tends to surface last, after the bigger problems are solved, and each resubmission cycle costs another wait in the queue.

What we check before submitting now

After that delivery we folded the lessons into a pre-submission checklist that runs before anything reaches Apple's servers:

• Symbol check on every linked binary: nm -u must show no UIWebView references, including third-party frameworks with no source available.
• Deployment target cross-checked against Apple's current minimum — not just what Xcode accepts locally.
• Marketing icon exported without an alpha channel, verified before archiving.
• Agreements, privacy manifests and account status confirmed while the build is still being prepared, not after upload fails.

Most of these checks are cheap. Skipping any of them is expensive.

This is part of the App Store release service we offer — see App publishing for the full scope.

Read the original Chinese note

All technical notes