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.

A few things worth checking, in this order. Attach the build first. Before a build is selected, the media section can show tabs for every device family. What is enforced at submission depends on the build you attach. Check what the build includes. In TestFlight, open the build. If a watchOS app or extension is listed (an old watch target, or a dependency that adds one), the Apple Watch tab is expected. Remove the target and upload a new build number. Check UIDeviceFamily in the uploaded binary, not just the project setting. A plugin, framework or generated config can add iPad (2) even when TARGETED_DEVICE_FAMILY is iPhone only. Unzipping the .ipa and reading its Info.plist settles it. On impact: if the attached build really is iPhone only with no watch app, you can leave the iPad and Watch tabs empty and still submit. If submission asks for those screenshots, the binary itself declares support for those devices, and the checks above will show why.