macOS approved, iOS rejected under 4.3(a) - guidance on difference review outcomes

An approval on macOS does not automatically carry over to iOS. Each platform build and its user experience are reviewed separately, so I would focus your reply on the iOS app and the specific 4.3(a) concern rather than relying only on the macOS approval.

In the Resolution Center, give concrete examples of what makes the iOS version distinct, such as its features, content, and intended users. If you believe the rejection does not fit, ask which similarities App Review identified and explain why they do not apply. If the discussion does not resolve it, you can use the App Review Board appeal process. Keep the submission ID in the conversation so the case is easy to trace.

Thank you @Pokpong . I didn’t open this thread just to say, "macOS was approved, so please approve iOS as well." Rather, given that the macOS version was approved—which suggests there are no critical issues with the build—I wanted to request a re-evaluation of this rejection. I am even prepared to share our GitHub commits and source code with the review team if necessary. I also reached out directly via the iOS submission reply channel to discuss the specifics, but although the standard response time is 24–48 hours, four days have passed without a reply. Consequently, I have opened a support ticket (Case ID: 102998410984) and am also posting here in the hope of connecting with an official representative.

Adding one angle to the good advice above. 4.3(a) is mostly about the app looking like many others in a crowded category, and media players are one of the most crowded on iOS. The macOS store is far less saturated, which can explain the different outcome even for the same codebase.

What tends to move a 4.3(a) review is showing, not telling:

A short screen recording in the App Review notes (30 to 60 seconds) that goes straight to the two or three things no other player does, not the basic playback.

Screenshots and description that lead with those features. Reviewers see the store listing too, and a listing that reads like a generic player reinforces the 4.3 decision.

No template traces. Placeholder text, sample content or UI that matches common player templates is often what triggers the similarity flag.

Then reply in the same submission thread asking which apps or elements were considered similar, and if that does not resolve it, the App Review Board appeal is the next step.

Thank you @stackpine . I am willing to make any necessary changes or provide any evidence required; I just need a response from the review team and some guidance on how to proceed. We conducted an active and reasonably medium-scale TestFlight phase and following requests from our users, we submitted the app for distribution. After waiting a week for the review, it was rejected; then we reached out via the reply channel to seek a resolution, but it has been nearly another week with no response. Unfortunately, the process is extremely slowly..