Before you reply to a 4.3 spam rejection

A Guideline 4.3 spam rejection usually names no app, no screenshot and no line of code. Your first reply shapes the rest of the thread, so it is worth an hour of checking before you write it.

On the night of August 22, 2026, every iOS update I had waiting in App Review came back at once: twelve versions of twelve separate apps, with the same letter copied twelve times, "Guideline 4.3(a) - Design - Spam". This guide is what I checked before replying. It describes the method, not an outcome, and following it does not guarantee approval.

#1. Find out what is actually blocked

Check the store before anything else. In my case every live app stayed on sale; only the pending updates were held. That changes what you are dealing with. A hold on new builds across a portfolio is a different problem from a takedown, and it calls for a calmer reply.

#2. Read what the letter names, and what it does not

Paste the rejection into the App Review Rejection Decoder. It maps each guideline number in the message to Apple's own section title and what that section asks for, in your browser. It does not predict approval. It stops you fixing the wrong thing.

Then list what is missing. Mine named no app, no competitor, no screenshot and no code. When the same body arrives for twelve products in the same minute, you cannot tell which concern applies to which app, or whether Apple thinks you are copying yourself or someone else. Those need different fixes, so they become questions for your reply.

#3. Compare the letter with the published guideline

Open the current App Review Guidelines and read 4.3 in full. Its parts are narrower than the letter's template paragraph. 4.3(a) is about multiple bundle IDs of the same app, with a separate map app for every city as Apple's example. 4.3(b) is about apps that are indistinguishable from what is already widely available. My letter cited 4.3(a), but its wording read closer to 4.3(b).

Do not treat a mismatch as a point to win. Treat it as a reason to be precise about what each app does and what you submitted with it.

#4. Measure the accusation you can measure

"Similar binary" is checkable. Hash every source file in every app and count the hashes that appear in more than one app:

for app in ~/apps/*/; do
  find "$app" -name '*.swift' -not -path '*/.build/*' -exec sha256sum {} + \
    | awk -v app="$(basename "$app")" '{print $1, app}'
done | sort -u | awk '{print $1}' | uniq -d | wc -l

Across my twelve apps there were 1,030 Swift files and zero shared between any two apps. That does not prove Apple wrong about presentation. It does mean the problem, if it is real, is more likely in what reviewers see from outside than in shared code.

#5. Audit what reviewers see from outside

Look at the portfolio the way a reviewer meets it: release notes, screenshots, metadata and how the builds arrived.

• Release notes. Eight of my twelve opened with the same sentence, ten listed the same eight languages in the same order. I rewrote each one to describe what changed in that app, in that app's vocabulary, without inventing features: the underlying change really was the same localization push.
• Submission cadence. All twelve went up inside ninety minutes from the same API key. That reads as one template fired twelve times, even when the code is not shared.
• Screenshots. I found two live screenshots that were wrong for different reasons. One showed an error message the app does not contain in any language, because an image model had drawn the UI and invented it. Another showed notifications turned off under a headline about never forgetting a date. Both needed real captures before any resubmission.

Fix these because they are real quality problems, not because they are arguments to send Apple.

#6. Reply once

Twelve identical replies to a spam finding would look like spam. Answer on one thread. State what you measured, describe what you fixed, and ask the questions the letter left open: which apps Apple means, and whether the concern is between your own apps or against another developer's.

#7. Do not resubmit blindly

Resubmitting while a spam finding is open, without new information, risks turning a metadata question into an account question. Wait for the thread to move, keep the live apps healthy, and resubmit with the fixes once you know what the concern is.

If you want someone to trace a rejection across the app, the store record and the resubmission with you, that is what the App Review Rescue service below is for. It starts with a fit check and comes with no promise of approval.