Guideline4.3
Apple Guideline 4.3 Similar Binary Rejection
§ 01What this rejection usually means
Similar binary is the strongest of the three 4.3 phrasings. Apple’s systems, or a reviewer, believe the package looks like another submission — a template, a white-label, a sibling app, or leftover targets from an older project.
§ 02What Apple’s wording tells you
We noticed your app shares a similar binary, metadata, and/or concept with apps submitted to the App Store.
Your app shares a similar binary with other apps already submitted.
Prioritize the project, not the store page. Icon and description can wait. Bundle IDs, extensions, entitlements, shared frameworks, and vendor SDKs come first.
§ 03Common causes
- Purchased or GitHub template used by other developers with light rebranding.
- A second target in the same Xcode project, or a copy-pasted project folder.
- Old Firebase GoogleService-Info.plist, reversed client IDs, or Facebook App IDs.
- Shared App Groups, Keychain access groups, or URL schemes from a previous product.
- An earlier app on the same account that you deleted but whose binary fingerprint still sits in review history.
§ 04How to diagnose your case
- Confirm whether Apple wrote “binary” specifically, or the generic binary/metadata/concept sentence.
- Ask if this codebase ever shipped under another name, team, or bundle ID.
- Search the repo for old names before you write the reply.
- If you truly wrote it from scratch and the account is clean, treat it as a possible false positive and prepare evidence.
§ 05What to inspect in your project
- Target → General → Bundle Identifier
- Extension bundle IDs and App Clip IDs
- Signing & Capabilities: App Groups, Keychain, Associated Domains, Push
- Info.plist URL Types and schemes
- GoogleService-Info.plist, REVERSED_CLIENT_ID, FacebookAppID
- grep for old bundle IDs and product names
- Shared SPM / CocoaPods packages that still contain vendor sample code
§ 06What not to do
- Do not create a new bundle ID as the first response.
- Do not resubmit the same archive.
- Do not move the project to a friend’s developer account.
- Do not only change the display name.
§ 07How to fix it
- Remove leftover identifiers and unused targets.
- Replace vendor sample assets, storyboards, and helper classes you never rewrote.
- If two of your apps share a core, document the difference or merge the listings.
- Write a reply that states: original source, one product, what you inspected, what is unique.
§ 08How to verify the fix
- Archive a clean build and confirm no old scheme or plist is copied into the bundle.
- Install on a device and check the URL schemes that actually register.
- Have a second person search the repo for the old product name.
§ 09What evidence to prepare
- Product website and design history with dates
- Repo creation date or commit history you are willing to describe (not dump)
- List of identifiers you audited
- Screenshot of the account showing a single related app
- Feature list that is not the template’s default
§ 10Suggested reply to App Review
Resolution Center · Reply
Hello App Review, This submission is an original app developed by our team. We have not submitted other apps with this binary, and we did not start from a commercial template. We audited bundle identifiers, extension IDs, App Groups, Keychain groups, URL schemes, Associated Domains, and third-party config files. We also searched the project for leftover names from earlier prototypes. The app is a single product: [one-sentence purpose]. It is distinct from other apps in [two concrete differences]. If you are matching us to a specific prior submission, please tell us which one so we can address it directly. Thank you.
§ 11Should you appeal?
Appeal only after a reply that explained uniqueness was ignored or rejected with the same boilerplate, and you have evidence the match is wrong. Do not appeal as the first action.
§ 12Questions people ask next
- Does similar binary always mean I used a template?
- No. It can also be leftover identifiers, a sibling target, or a classifier miss. Template is just the most common explanation.