In September 2026, three iOS apps I had in review were rejected under Guideline 4.3(a) Design - Spam at the exact same time.

Two of them, a recipe cost calculator and a blood glucose log, weren't supposed to resemble anything. For those two, without changing a line of code or uploading a new build, I got the 4.3(a) withdrawn by appeal alone. Then, a week later, the same two apps were rejected under 4.3(a) again. This time the rejection came with a warning that mentioned removal from the Apple Developer Program.

This post is the full record of how both apps made it to the App Store from there: the appeal structure that worked, how to tell the cases an appeal won't fix, and why an appeal that wins can still be followed by the same rejection.

What you'll learn

  • A real case of 4.3(a) sweeping up apps that aren't similar in a single batch
  • The structure of an appeal that got 4.3(a) withdrawn without a new build (with the actual English text)
  • How to tell an app an appeal can save from one it can't
  • Why the rejection comes back on the same account after an appeal wins, and what actually fixes it

The short version

If your app got swept up, appeal before you rebuild anything. If both its concept and its code are independent, describing its unique features concretely in the Resolution Center may be enough. For me, it worked for both apps, both times.

But an appeal only wins that one review. As long as you have a series of similar apps lined up in review at the same time, the next time you submit any of them, they will all go down together again. And the ported app that really was similar didn't pass even after I rebuilt its presentation and resubmitted it on its own. If you ship a series of apps on the same engine, the safe assumption is that only the first one gets through.

What happened

For background: I develop with Claude Code, and I'd gotten to the point where I could build an app in one or two days. That led to a pace of four submissions in five days.

Date What happened
Sep 5–8 Submitted four in a row: the recipe cost calculator, the blood glucose log, an exam prep app (a port of my published certification exam app to a different certification), and an update to the original exam app
Sep 9 The three apps in review were rejected under 4.3(a) at the same time. The original exam app, already on the store, was unaffected
Sep 9 Appealed for the cost calculator and the glucose log without a new build. Chose to rebuild the ported exam app
Sep 11 4.3(a) was withdrawn for both. Instead, Apple flagged only an unrelated issue (prices shown in the screenshots, 2.3.7). Fixed the metadata only and resubmitted
Sep 17 The cost calculator, the glucose log and another exam prep app were rejected under 4.3(a) at the same time again, this time with an Extended Review warning
Sep 17 Sent follow-up appeals for the two. Withdrew the other exam prep app from review
Sep 23 and 24 The cost calculator and the glucose log passed review and went live
Sep 25 Resubmitted the ported exam app on its own, rebuilt from the screen skeleton up
Oct 6 The ported exam app was rejected with a "nine-question questionnaire" under 4.3 and 4.2.6. Answered it in a reply
Oct 29 The reply didn't get it through. On Nov 2, I decided not to ship this app in its current form

The rejection was boilerplate. It didn't say which apps it considered similar.

We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by you or other developers, with only minor differences.

Why apps that weren't similar went down too (my guess)

There's no official explanation, so what follows is one developer's guess.

  • All three rejection notices arrived at exactly the same time. If a person had reviewed them one by one, the times would vary. It's more natural to assume they were judged together at the account level
  • The trigger was almost certainly the ported exam app. Its theme definitions and screen code were nearly unchanged from the original app, and the screenshot layouts and the structure of the description were the same too. It deserved to be called similar
  • When that one app got flagged, two apps with different concepts that were in review on the same account got swept up with it. That's my read

In other words, the same 4.3(a) covered two different situations: apps that really were similar and apps that were just caught in the sweep. You handle them in completely different ways.

Round 1: the two bystanders were cleared by appeal alone

The cost calculator and the glucose log are independent in both concept and domain logic. There was nothing real to fix, so I didn't upload a new build and appealed only by replying in the Resolution Center.

Four elements, I think, made it work:

  1. Open by pointing out that the app may have been judged by comparison with the other apps on your account
  2. List the features only this app has, in the domain's own vocabulary (not "useful features" but concrete logic; for a cost calculator, something like "nested sub-recipes with circular-reference detection")
  3. State honestly, and narrowly, how much code you share with your other apps ("only generic numeric entry and CSV export; no domain logic, data model or screen is shared")
  4. Ask them to name the specific app they found it similar to

Here's an excerpt of what I actually sent for the cost calculator:

We would like to appeal this decision. We believe the app may have been flagged
by comparison with other titles published under our developer account, rather
than assessed on its own functionality, so we would like to describe what this
app actually does.

- Ingredient master: each ingredient is registered as "package quantity +
  purchase price", from which the app derives a unit price and corrects it with
  a configurable loss (yield) rate.
- Sub-recipes: a recipe such as a sauce or a dough can itself be used as an
  ingredient inside another recipe, with circular-reference detection.
- Two-way pricing: enter a selling price to see the cost ratio and gross
  margin, or enter a target cost ratio to obtain a recommended selling price.
(...)

Code shared with our other submissions is limited to small generic helpers of
a kind common to any SwiftUI app, such as a numeric-entry modal and a CSV
writer; no domain logic, no data model, and no screen is shared.

If you still consider this app similar to a specific app, could you please tell
us which app it was compared with?

For the glucose log, I built the appeal around reading and writing Apple Health (HealthKit) data and the PDF report for doctor visits. Neither of those technologies exists in any other app on my account, so they were the strongest evidence of originality I had.

Two days later, Apple's reply withdrew the 4.3(a). It opened with "Upon further review, we've identified additional issues," and the only thing flagged instead was an unrelated issue: prices visible in the screenshots (2.3.7). I fixed the metadata and resubmitted.

Round 2: the same two apps were rejected under 4.3(a) again

A week later, the two resubmitted apps were rejected under 4.3(a) again. Going down at the same moment was another exam prep app, whose UI and features I had differentiated before submitting it. This time the rejection carried a warning:

Repeated submissions of apps with these issues will result in extended review times. Accounts that repeatedly submit apps that do not follow the App Review Guidelines ... face removal from the Apple Developer Program.

That's a warning that raises the possibility of losing the account. I did three things.

1. I stated in the appeal that the same build had already cleared 4.3 once

My first reply centered on a question: last time you only flagged 2.3.7, so why 4.3 now? But the reviewer is a different person every time, and on its own, that question could be read as if only 2.3.7 had ever come up. So I sent a follow-up that stated two facts plainly:

  • The app was rejected under 4.3(a) on Sep 9, and Apple withdrew that rejection on Sep 11 after my appeal
  • This build is identical to the one under review when the rejection was withdrawn. The only changes were the metadata I'd been asked to fix

I also wrote out the app's unique features again, as in the first appeal. Assume that whatever the previous reviewer understood is invisible to the current one.

2. I withdrew the similar series app from review

Differentiated or not, the exam prep app was the third app in the same series. Across the whole account, it looks like mass production. I withdrew it so that only the two conceptually independent apps remained among the disputed submissions.

3. I didn't submit anything new

The warning targets repeated submissions of apps with the same issues. A reply in the Resolution Center isn't a resubmission. I made every argument by reply and stopped submitting builds.

In the end, the cost calculator passed review on Sep 23 and the glucose log on Sep 24, and both went live. Both times, with zero code changes.

Which apps an appeal can save, and which it can't

Looking back, the difference is clear.

Overturned (swept up) Not overturned (actually similar)
Concept Solves a different problem from the other apps on the account The same app with the subject swapped
Code Nothing shared beyond generic components Screens, theme and data model all shared
Presentation Screenshots and description structured differently Same screenshot layouts, even the same description phrasing
What to do No new build; appeal by describing the unique features concretely An appeal won't overturn it. A rebuild didn't get it through either

For the ported exam app, I chose to rebuild. At first I changed the UI colors and typeface per certification, but when I measured it, most of the screen code still matched the original app. If the skeleton of the screens is the same (how the cards are arranged, the shape of the answer choices), new colors and fonts won't make it look like a different app. So I rebuilt every screen, working the look of that certification's study materials into the screen structure itself (how the table of contents is set, how answer choices are numbered, the ruled lines). I added features that only make sense for that certification, and rewrote the screenshots and description from the structure up.

After the second mass rejection, I also considered consolidating: one app where you pick a certification and unlock each one with an in-app purchase. That's the very solution Apple's description of 4.3 points to. I didn't consolidate anyway, and decided to ship them one at a time, spaced apart, because I believe submitting a series of similar apps in quick succession was itself what triggered the mass rejection. I resubmitted the rebuilt port on its own on Sep 25, but in October it was rejected with the "nine-question questionnaire," and my reply didn't overturn it. So as long as it shared the engine, rebuilding the presentation wasn't enough. That story is in part 2. I've stopped submitting the other exam prep app as well.

Don'ts

  • Resubmitting without changing anything. 4.3 asks you to rethink the concept, so an unchanged resubmission only moves you further along the warning stages. Always appeal in the Resolution Center
  • Writing "you didn't look properly." It gives them nothing to reverse on and only hurts the impression you make
  • Claiming you share no code at all with your other apps. When your account really does contain a ported app, overclaiming undermines every appeal you make. State the scope of what's shared honestly and narrowly
  • Reusing the same text across apps. A template appeal reinforces the impression of mass production. I varied both the structure and the wording

Takeaways for indie developers

  • Your submission pace is a signal too. Four apps in five days stands out on its own. The faster AI makes development, the more deliberately you need to space out submissions
  • Make sure a "shared engine" hasn't turned into a "shared app." I didn't realize the ported app was nearly identical, down to the screens, until I diffed its code against the original. Check that everything visible from outside, from the theme and screens to the screenshots and the structure of the description, really is different
  • If you were swept up, appeal before you rework. Rebuilding an app that has nothing real to fix can be a waste of time
  • Keep a record of your appeals. Because I'd kept the text I sent and the dates of Apple's replies, I could write in round 2 that the same build had already cleared 4.3 once

Summary

  • Three apps were rejected under 4.3(a) at the same moment. The trigger was probably the ported app, and apps that weren't similar got swept up with it
  • The two bystanders got 4.3(a) withdrawn with no new build, by appeal alone. When it came back a week later, an appeal that restated the history, plus withdrawing the similar series app, got them through to release
  • An appeal only wins that review. As long as you line up a similar series in review at the same time, it will come back
  • The ported app that really was similar didn't pass even after I rebuilt its presentation and resubmitted it on its own. With a series on the same engine, assume only the first one gets through

The nine-question questionnaire that came next, and the record of which reply passed and which didn't, is in part 2.

Part of a series on indie iOS development from Japan. Japanese original: App Store 4.3(a)スパム判定を反論だけで2回覆した記録. Related in English: Automating App Store Connect Metadata With the API. More: Village Gazette in English.