Guideline4.3illustrative

4.3 similar binary on a rewritten client project

Illustrative scenario — not a claimed client win.

§ 01Problem

A team submitted what they believed was a from-scratch rewrite. App Review returned Guideline 4.3 with the similar-binary sentence.

§ 02Apple rejection message

§ 03App background

A single productivity app, one listing, original branding. The current repo had been started by copying an older client folder “to save time on signing.”

§ 04What we initially suspected

The team assumed a false positive because they only had one app and had redesigned the UI.

§ 05Diagnosis

The UI was new. The bundle still contained the previous client’s GoogleService-Info.plist, a leftover URL scheme, and an unused notification extension with the old bundle ID prefix. Those artifacts are enough for a similar-binary match even when screenshots look original.

§ 06What was changed

• Removed the old Firebase file and generated a new one for this bundle ID
• Deleted the unused extension target
• Renamed the leftover URL scheme and searched the repo for the old product name
• Replied with a six-line audit rather than a new bundle ID

§ 07What was not changed

• Bundle ID of the main app
• Developer account
• Core product scope

§ 08Reply to Apple

We identified leftover configuration from an earlier prototype (Firebase plist, unused extension, old URL scheme), removed them, and confirmed this account has a single app. Happy to walk through any remaining overlap you are seeing.

§ 09Result

Illustrative outcome: the following review asked one clarifying question about the old scheme, then approved. Treat this as a pattern, not a guarantee.

§ 10Lessons learned

• A visual rewrite is not a new binary if entitlements and config still belong to someone else.
• Reply plus a precise delta beats a new bundle ID.
• Grep for the old name before you write “original source.”