Guideline 4.3 rejection without specific reasons: how can new apps compete fairly?

App Store Distribution & Marketing App Review
Nootfly OP
Created
Replies 2
Boosts 0
Views 554
Participants 2

Hi everyone,

I'd like to raise a concern about the transparency and fairness of Guideline 4.3 reviews.

A rejection that says an app duplicates existing functionality or is indistinguishable from widely available apps should explain what specifically led to that conclusion. General categories, followed by an instruction to make substantial improvements, do not give developers an actionable path forward. Which functionality is the problem? Which aspects need to change? What standard would satisfy the reviewer?

Without concrete examples or a clear threshold, the assessment feels highly subjective. Developers can spend significant time building a product and still be left guessing what would make it acceptable.

In my view, independently developed apps should be able to compete in existing categories. Products naturally share basic functionality when they solve the same problem. Competition can come from a better workflow, a clearer interface, privacy, pricing, accessibility or serving a different audience. It should not require every developer to invent an entirely new category.

If similar functionality alone is enough to reject a new entrant, that risks protecting established apps from competition. That feels unfair to independent developers and limits users' choice. The first app to enter a category should not effectively own that category.

I support preventing copied apps, repetitive submissions and low-quality template spam. But there needs to be a clear, consistently applied distinction between spam and legitimate alternatives. A developer should be able to understand the reasoning behind a rejection and respond to specific concerns.

Could Apple clarify:

  1. What specific evidence should reviewers provide when rejecting an app under 4.3?
  2. How is ordinary competition within a category distinguished from unacceptable duplication?
  3. What concrete criteria establish sufficient differentiation, and how are they applied consistently?
  4. When 4.2.6 is mentioned alongside 4.3, can the reviewer explain whether there is an actual template-related finding and what supports it?
  5. What is the best process for obtaining an actionable explanation when the rejection only lists general possibilities?

Asking developers to make substantial changes is reasonable when the issue is clearly identified. Asking them to guess at an unstated standard is not. Clear reasons and consistent criteria would help developers improve their products while giving new entrants a fair opportunity to compete.

Has anyone successfully obtained specific, useful clarification in this situation?

Replies  2
Boosts 0
Views  554
Participants  2
Nootfly OP

I want to add a concrete example from my own experience with a game I developed, which was rejected under Guidelines 4.3 and 4.2.6.

The idea for this game came from my son. We worked on it together and playtested it together, with his feedback helping shape the UX and game design. It is a standalone family project, with no significant code or assets reused from my other apps or a third-party game or template.

The rejection lists possible types of spam, but does not identify which specific content or functionality was duplicated, which existing app it considers indistinguishable, or what evidence supports the reference to an app generation service. It then warns against resubmitting without substantial improvements and asks nine detailed questions about the product, audience, testing, code sharing and ownership.

I am willing to explain all of those things. What frustrates me is the imbalance: developers are asked for detailed, specific answers, while the rejection itself gives us broad possibilities instead of a specific finding. How can we make meaningful improvements when we are left guessing what the reviewer believes is wrong?

I am angry and disappointed. Having something my son and I worked on together labelled spam without a concrete explanation feels dismissive and disrespectful of our effort. The uncertainty also makes it difficult to decide where to spend more development time.

A fair review process should identify the issue, explain how the cited guideline applies to the submitted app, and give the developer an actionable way to respond. Shared genre conventions should be assessed alongside the actual implementation and experience. Independent developers need clear reasons and consistent criteria to understand the decisions affecting their work.

Has anyone managed to get a specific explanation of a 4.3 rejection, particularly when 4.2.6 is also cited despite the app being independently developed? What helped move the discussion beyond a generic rejection?
Tomato OP

I'd like to raise a concern about the transparency and fairness of Guideline 4.3 reviews.

There are 4.3 (a) and 4.3 (b). Which 4.3 guideline violation are you referring to?

Could Apple clarify: What specific evidence should reviewers provide when rejecting an app under 4.3?

They never do that.