Apple rejected your app under Guideline 4.3 and the notice says "Design - Spam". If you built the app with Cursor, Claude Code, Rork or Bolt, that word is confusing, because you never sent anyone anything. In App Review, spam has a narrower meaning: your app looks like a copy of an app you already submitted, or like one more app in a category Apple considers full.

This guide shows how to work out which of those you have, what to change in the project, what to ask Apple, and what to write when you resubmit. It's long because this rejection has several causes, and each one has a different fix. Skip to the step you need.

Find out which half of 4.3 you got

The App Review Guidelines split 4.3 into two clauses, and they call for different fixes.

4.3(a) opens with "Don't create multiple Bundle IDs of the same app." Apple's example is a separate map app for every city instead of one map that can search any city. This clause is about your own catalog.

4.3(b) opens with "Don't submit apps that are indistinguishable from what's already widely available." It names dating, flashlight, sound effects, wallpaper, simple timers and fortune telling as established categories, and says Apple won't accept new submissions in them unless they offer "a meaningfully different or improved experience." This clause is about the App Store as a whole.

Check the exact wording in your rejection message. If it names a clause, as in "Guideline 4.3(a) - Design - Spam", you know where to start. If it only says 4.3, go through both sections below.

Why AI-built apps run into this

Apple doesn't publish how it decides two apps are similar, so this part is my own reading. AI tools tend to produce the same structure from the same kind of prompt: a tab bar, a list, a detail screen, a settings page, the default system look. Ask for a habit tracker and you get something close to what everyone else got. The speed causes a second problem. Once a new app takes a weekend, it's tempting to reuse the project for a new niche, change the name and icon, and submit it again.

Volume matters too. The Next Web reported in April 2026 that Apple received 557,000 new app submissions in 2025, the largest annual total since 2016, and that some developers saw waits of 7 to 30 days in March. Apple told The Information it isn't targeting vibe coding as a category. Treat that as good news: the same rules apply to you as to everyone else, and they can be met.

These are the situations to look for:

  • You shipped the same generated project twice under different names.
  • You made one app per city, sport, language or audience.
  • You started from a paid template that other people also submit.
  • Your idea sits in one of the categories 4.3(b) lists.

Other guidelines that get mixed up with 4.3

Before you change anything, read these neighbors. A 4.3 notice can sit alongside one of them, and fixing the wrong rule costs you another round in the queue.

Guideline 4.1 covers copycats. It tells you not to "simply copy the latest popular app on the App Store, or make some minor changes to another app's name or UI and pass it off as your own." If you prompted an AI tool with the name of a famous app, read that sentence twice.

Guideline 4.2 is minimum functionality. It asks for features, content and UI "that elevate it beyond a repackaged website."

Guideline 2.1(a) is app completeness. It says "placeholder text, empty websites, and other temporary content should be scrubbed before submission." Generated projects often ship with sample data that nobody looked at again.

Guideline 2.5.2 says apps may not "download, install, or execute code which introduces or changes features or functionality of the app." The Next Web reported that Apple cited it when blocking updates to some vibe coding apps. It matters if your app generates or runs code after review.

Step 1: audit your own account

Open the Apps list in App Store Connect and look at everything there, including apps that were rejected or taken off sale. For each one, ask whether a stranger would call it the same app as the rejected build. A simple comparison helps. Write the two apps side by side and answer these questions:

  • Do they do the same job for the same person?
  • Do the first three screens have the same layout?
  • Is the onboarding the same with different words?
  • Are the App Store description and screenshots close to each other?
  • Would a user need both?

If you answer yes to the first four and no to the last, you have a duplicate, however different the two feel to you after building them.

Then check the projects themselves. List the bundle IDs in each Xcode project:

grep "PRODUCT_BUNDLE_IDENTIFIER" MyApp.xcodeproj/project.pbxproj | sort -u

For Expo projects, the value is ios.bundleIdentifier in app.json.

If you have two similar projects on disk, see how much really differs:

diff -rq --exclude=.git --exclude=build --exclude=Pods --exclude=node_modules AppA AppB

A short list of changed files means you have one app with two names, and that's the 4.3(a) case. Search for template leftovers while you're there, since they make an app look mass produced:

grep -rIl -e "Lorem ipsum" -e "com.example" -e "Your App Name" . \
  --exclude-dir=Pods --exclude-dir=node_modules --exclude-dir=.git

Your metadata counts as well. Guideline 2.3.7 asks for a unique app name and keywords that describe the app accurately, and 2.3.3 says screenshots "should show the app in use, and not merely the title art, login page, or splash screen." If your store listing was generated in the same session as the code, rewrite it by hand so it describes this app and no other.

Step 2: ask App Review a specific question

The guidelines tell you to use App Store Connect to talk to the App Review team when you have questions about a rejection. Apple's contact page says to click Reply to App Review and to be specific about the feature, guideline or step you need clarified. Keep the message short. Something like this:

My app was rejected under Guideline 4.3. Is the concern that it is similar to another app on my account, or to apps in its category? If it is another app on my account, which one? I want to fix the right thing before I resubmit.

Apple says not to use this field to appeal a rejection or to ask for an expedited review, and not to ask about other developers' apps. You can also request a call there. Include your time zone, and confirm that your contact details in App Review Information are current. Apple says calls typically happen within three to five business days.

You may get a general answer, but it costs nothing and it can tell you which clause to work on.

Step 3: if it's 4.3(a), merge the apps

Keep one app and take the duplicates off sale. Apple's own suggestion is to submit a single app and provide the variations through in-app purchase. Technically, that means moving what used to be separate targets into data the app loads:

struct Edition: Decodable, Identifiable {
    let id: String
    let title: String
    let contentURL: URL
    let productID: String?   // nil means the edition is free
}

@MainActor
final class EditionStore: ObservableObject {
    @Published var editions: [Edition] = []
    @Published var selected: Edition?
}

That gives you one binary and one bundle ID, with the user picking a city or sport inside the app. Here's the order I'd work in:

  1. Choose the app to keep. Pick the one with the most users or the strongest listing.
  2. Write down every difference between the apps: content, colors, names, prices.
  3. Move those differences into a config file or a remote JSON document that holds content only.
  4. Add a picker on first launch so people can choose their edition.
  5. Delete the extra targets and test a clean install on a real device.
  6. Take the other apps off sale, then submit the merged app.

Keep step 3 to content. Remote data that fills in text and images is one thing, while remote code that adds features runs into Guideline 2.5.2. If your AI tool created a target per variant, ask it to collapse them into one target, then review the diff yourself. This kind of refactor is where generated code tends to leave dead references behind.

Step 4: if it's 4.3(b), change what the app does

A new icon and a new color scheme leave the app doing the same job as before, so I wouldn't expect them to help. Write one sentence on what your app does that the top five apps in its category don't. If you can't, that sentence is the work.

Take a made-up example. "A habit tracker with streaks" describes hundreds of apps. "A habit tracker for night shift nurses, where a day starts when your shift ends" describes a specific person with a problem the default calendar logic doesn't solve. The second version changes the data model, the reminders and the widgets, and a reviewer can see that in a minute.

Features that use the phone tend to be the easiest way to get there, and they're also the things AI tools skip unless you ask: a home screen widget, App Intents for Siri and Shortcuts, full offline use, HealthKit or camera input where they fit the idea. Pick one that serves the sentence you wrote and build it properly.

If you built the app with a web-first tool and wrapped it, read Guideline 4.2 again. A web view in a shell has a hard time with both rules at once. Rebuilding the main screens natively is more work than a resubmission, but it's the change that addresses the actual complaint.

If your idea really is one of the named categories and you can't find a different angle, consider a different app. Guideline 4.3(b) says Apple won't accept new submissions there without a meaningful difference, so a polished clone still has no route through.

Step 5: tell the reviewer what changed

Apple's Before You Submit list asks for detailed explanations of non-obvious features in the App Review notes, and for a demo account or a fully featured demo mode if the app has accounts. Write the notes for someone with very little time. A template:

This build addresses the Guideline 4.3 rejection from [date]. We removed [app name] from sale and merged its content into this app. To see the difference: 1. Open the app. 2. Choose [edition]. 3. Open [feature]. Demo account: [login]. Backend services are live.

For a 4.3(b) case, replace the second sentence with what the app now does that similar apps don't, and where to find it. A reviewer who can see the difference in the first minute has less reason to send the same rejection again.

Don't resubmit the same build and hope for a different reviewer. Guideline 4.3(b) warns that repeated submissions of low-value apps may lead to removal from the Apple Developer Program, and each round costs you days in the queue.

If you think Apple got it wrong

The guidelines give you an appeal route. Apple's App Review Board page says to reply to the rejection message first and to appeal only if that doesn't resolve the issue. A complete appeal should "point to the specific requirements involved and explain how your app satisfies them", and it should address every guideline the message cited.

Apple gives an example of an incomplete appeal: "This app is important to my business and shouldn't have been rejected. Please take another look." So leave out how long you worked on it. Point to evidence, such as a list of what your app does that similar apps don't, or proof that two flagged apps serve different purposes and different people.

Two more rules from that page are easy to miss. Don't appeal if you've already addressed the issues and resubmitted, and don't use an appeal to get a status update or an expedited review. Apple also notes that a complete appeal doesn't guarantee the decision will be overturned. If your audit in Step 1 found a real duplicate, fix that first.

Checklist before you resubmit

  • You know whether the problem is 4.3(a), 4.3(b) or both.
  • Every app on your account is one a stranger would call distinct.
  • Duplicates are merged or off sale.
  • No template text, sample bundle IDs or placeholder screens remain.
  • The name, description and screenshots were written for this app.
  • You can state in one sentence why the app is different.
  • Remote data changes content only, never features.
  • You tested a clean install on a real device.
  • The review notes explain the change and include a demo login.

If you're using Claude Code on your iOS project and keep re-explaining the codebase to it, I packaged my setup as Claude Code + Xcode: The Production iOS Workflow Kit. It's a paid product of mine on Gumroad.

Sources