Guideline 4.3 and 2.1 rejections: two different problems, two different playbooks

A 4.3 rejection and a 2.1 rejection look identical in your inbox: a guideline number, a short paragraph, and the build back in your hands. They are not the same problem, and treating one like the other costs weeks.

Guideline 4.3 (Design - Spam) questions whether your app is an independent product — Apple believes it duplicates an existing app or is a variant of something already submitted. Guideline 2.1 (Performance - App Completeness) means the build did not run properly: it crashed, the main flow dead-ends, or information is missing. 4.3 is answered with product evidence; 2.1 is fixed with engineering work. Diagnose the wrong one and every following action is wasted.

What actually triggers 4.3

1. Submitting the same product several times with a new skin: template-generated apps that differ only in name and artwork.
2. Similarity to your own account history. The reference set for 4.3 is the whole store plus every app connected to your developer account, including apps that are no longer live. A variant removed a year ago still counts.
3. Thin functionality: a single screen wrapping a website, with no independent feature set.
4. Near-identical metadata: screenshots, descriptions or keywords that mirror the referenced product.
5. Reusing the engineering and interface structure of an app that was repeatedly rejected or removed.

Triage order for 4.3

1. Audit the account first. List every app under your App Store Connect account, including removed ones, and identify which resemble this submission. This is the step teams skip, and it decides the outcome.
2. Write down the differentiation. Positioning, target audience, content structure, interface organisation — compared item by item against each similar app. The goal is one sentence a reviewer can verify: why this is an independent product.
3. Replace lookalike assets. Screenshots, description and keywords that echo the reference product go, even if you think they are defensible.
4. Separate the engineering. If you deliver similar apps to several clients, the bundle IDs, the account ownership and the brand assets must be fully independent — shared structures invite 4.3.
5. Appeal only with evidence. If you cannot produce verifiable differentiation, fix first and resubmit. Appealing without evidence just adds a round.

What actually triggers 2.1

• A crash at launch or on a key screen.
• Sign-in cannot complete: the test account expired, the SMS code never arrives, third-party sign-in is misconfigured.
• The main flow is blocked by a precondition: it needs hardware, merchant credentials, or a backend configuration the reviewer does not have.
• Review notes are missing, so the reviewer cannot find the working path.
• Empty content: the backend has no data, and the reviewer sees blank screens.
• The purchase path is not configured, so in-app products cannot be tested.

Triage order for 2.1

The principle: crashes first, then flows, then reviewer enablement.

1. Reproduce the crash along the path named in the rejection, and pull the logs from Xcode Organizer or App Store Connect.
2. Walk the main flow end to end yourself: sign-up, sign-in, every core feature, sign-out.
3. Provide a long-lived test account in the review notes — and re-verify it before every submission. Expired test accounts are the classic hidden cause of 2.1.
4. If the app needs hardware, give the reviewer a demo video or a built-in demo mode.
5. Write review notes that let the reviewer finish the flow unaided: the path, the account, the caveats.
6. Make sure what the reviewer can see in the backend matches reality — no empty screens.

Appeal or resubmit?

• An appeal goes to the App Review Board. It is for cases where you are confident the judgment is wrong and can present an evidence chain. An appeal does not change the binary — it changes the reviewer's judgment.
• A resubmission is for builds with something genuinely fixable. Fix it, and attach a short "what changed" note in the Resolution Center so the reviewer can verify quickly.
• They combine: fix what you agree with, and appeal in parallel with the evidence you have.

The test is a single question: can you produce evidence a reviewer can verify? If yes, appeal. If no, fix first.

Two habits that prevent both

Most 2.1 rejections are prevented by one habit: before every submission, run the main flow exactly as the reviewer will — fresh install, the review-note account, no debugger attached — and read the review notes as if you had never seen the app. Most 4.3 exposure is prevented by another: keep an inventory of everything under your developer account, including retired variants, and treat any new submission that resembles one of them as a 4.3 risk from day one. Both habits cost minutes; a review round costs days.

How we work these cases

We clear rejections under the client's own developer account. Both types above come from real submissions we have handled — in one release alone we cleared a UIWebView reference inside a source-less third-party SDK (ITMS-90809), a server-side MinimumOSVersion rejection (code 90068) and an icon alpha channel (ITMS-90717); that record is in our note Three App Store rejections in one release. For 4.3, the deliverable is differentiation evidence a reviewer can check. For 2.1, it is a build whose main flow runs, with reviewer enablement written down. If a build is stuck right now, see App Store rejection help.

Read the original Chinese note

All technical notes