4.3(a): five apps flagged at once, and the rejection wording changed from "other developers" to "you or other developers"

Question

Created 20h

Replies 2

Boosts 0

Participants 3

I have received Guideline 4.3(a) rejections on five apps in the space of a week, and I would like help understanding what my account is being compared against, because I am now guessing.

The app I most recently resubmitted is Real Cost: Loan Calculator (Apple ID 6804081720).

WHAT I CHANGED BETWEEN SUBMISSIONS

After the first 4.3(a) I accepted that the reviewer was right about what they were shown: the one thing my app does that the category does not was behind the in-app purchase, so the app opened as yet another loan calculator. I made that feature free for everyone with no limit, rewrote the metadata, added an app preview, and lowered the price.

I received the same rejection.

WHAT I MEASURED BEFORE POSTING

The app is 5,054 lines of Swift across 39 files. Zero remote package dependencies, no third-party frameworks, no advertising SDK, no analytics, and no network calls of any kind. It ships with 118 unit tests written against its own loan math and document parser.
I compared every non-comment line of Swift across my own projects. Real Cost's highest overlap with any other app I have submitted is 6.9%, and that fraction is ordinary SwiftUI scaffolding.
I surveyed 181 loan and debt apps in the US store. None of them reads the lender's own paperwork, which is the feature this app is built around and which is free in the current build.

THE PART I CANNOT EXPLAIN

The rejection text changed between submissions. The earlier ones said the app shares a similar binary, metadata and/or concept as apps submitted "by other developers". The most recent one says "by you or other developers".

I do not know whether that wording is meaningful or simply a different template. If it means my own apps are the comparison, I would like to know which ones, because the measurement above says they do not share code.

WHAT I AM ASKING

Could someone tell me which specific app or apps my submissions are being compared to, or which part of the binary or metadata is triggering this? I replied in Resolution Center several days ago asking the same question and have not had an answer yet.

I would rather make one real change than keep guessing and resubmitting, which I understand is the behaviour the guideline exists to stop.

Thank you.

Answer 1

Etresoft OP

20h

Could someone tell me which specific app or apps my submissions are being compared to, or which part of the binary or metadata is triggering this?

No. We're just randos on the internet. We don't know anything about your app or other loan apps.

Apple isn't going to post any information here in a public forum.

Answer 2

GetResubmit OP

7h

The wording change from “other developers” to “you or other developers” may be meaningful, but I would not treat it as proof by itself. The practical next step is to make your appeal evidence separate three possible issues: binary similarity, metadata similarity, and concept/category similarity.

Your code-overlap numbers are useful, but for 4.3(a) I would also include evidence App Review can evaluate quickly:

a table of all five affected apps, their Bundle IDs, App IDs, categories, core user flows and monetization;
screenshots or a short video showing the document-parser feature immediately visible in Real Cost, not hidden behind purchase or onboarding;
a comparison against the closest loan/debt apps, focused on user outcome rather than implementation;
the exact build numbers and metadata versions that were rejected;
a statement that there are no shared templates, contractors, SDKs, backends, assets or metadata patterns beyond ordinary SwiftUI scaffolding.

In Resolution Center or a formal appeal, I would ask Apple to identify which of the three areas is driving the rejection: binary, metadata, or concept. If they believe the apps are similar to your own submissions, ask whether the concern is portfolio-level duplication rather than this specific app’s implementation.

I would avoid another resubmission until that evidence package is ready. Repeated binary changes without knowing which similarity signal Apple is using can make the review history harder to reason about.