App Store Rejections Decoded: Guidelines 4.3, 2.5.2, 3.1.1, 4.2 and 5.1.1

Most App Store rejections cluster into a handful of guidelines, and five of them come up again and again: 4.3 (spam), 2.5.2 (downloading executable code), 3.1.1 (in-app purchase), 4.2 (minimum functionality), and 5.1.1 (data and privacy). Each is a different kind of 'no.' 4.3 says your app is too similar to others; 4.2 says it's too thin to be an app at all; 3.1.1 is about how you take money; 2.5.2 is about code that changes your app after review; 5.1.1 is about what you do with a user's data. Get the wrong mental model and you'll fix the wrong thing and get rejected again.

Apple sends a short, near-generic message in Resolution Center with a guideline number and not much else, so the first job is always to translate that number into 'what does this reviewer actually want me to change?' This guide does that for the five you're most likely to hit: what each really says, the patterns that trigger it, how to fix it before you resubmit, and, at the end, how to appeal when the reviewer got it wrong.

A 4.3 rejection means App Review considers your app a duplicate, a reskinned template, or a me-too entry in a category that's already crowded. It splits into two halves. 4.3(a) covers duplicate and copycat apps: multiple Bundle IDs for the same thing, or an app built from a boilerplate that thousands of others also shipped. 4.3(b) covers a technically original app that lands in a saturated category (yet another flashlight, soundboard, or wallpaper pack) without a distinctly better experience.

The reframe that saves you: 4.3 is a *concept* verdict, not a code bug. Nothing in your build is broken, so patching a crash and resubmitting the same idea gets rejected again. What has to change is how distinct the app reads versus the crowd the reviewer is comparing you against — a real native differentiator, consolidated duplicates, honest metadata. It's a deep enough topic that we gave it its own walkthrough, with a full appeal template, in [Guideline 4.3 rejections, explained](/blog/app-store-review-guideline-4-3-rejections).

2.5.2 lives in the Software Requirements section, and the short version is: an app must be self-contained in its bundle and may not download, install, or execute code that introduces or changes features or functionality after review. Apple can't vet what it can't see, so a build that pulls down a payload and rewrites its own behavior defeats the entire review process. This is the guideline that ended the era of 'hot-code-push' frameworks that let apps ship native changes without a new App Store submission.

What trips it in practice:

The fix is almost always the same: ship functional changes through a normal App Store update, not a runtime download. Keep remote config to genuine content and configuration, the stuff you'd change without shipping a binary anyway, not a switch for features the reviewer couldn't evaluate. If you use a cross-platform framework, confirm its update mechanism ships pre-reviewed bundles rather than pushing new native code.

3.1.1 governs payments for digital goods and services. The core rule: if you unlock features, content, subscriptions, or currency that are consumed *inside* the app, you must use Apple's In-App Purchase, not Stripe, not PayPal, not your own checkout. Physical goods and real-world services are the opposite: those must NOT use IAP and should take payment another way. Mixing them up is a classic rejection in both directions: a food-delivery app forced through IAP, or a premium subscription sold with an outside processor.

The part that changes by country is *steering*: Apple historically barred apps from linking to or even mentioning cheaper purchase options outside the app. As of 2026 that's no longer uniform. A US court injunction and the EU's Digital Markets Act have forced Apple to permit external purchase links in some regions, often under a specific entitlement, and the details are still being litigated. Don't assume the old anti-steering rule, and don't assume the new freedom either; check the current entitlement for the countries you ship to.

The fix is matching the payment method to what's being sold: IAP for in-app digital value, standard payment (Apple Pay or a card processor) for physical goods, and if you want to link out for a digital purchase, only through the entitlement Apple currently offers for your market.

4.2 says your app should include features, content, and UI that elevate it beyond a repackaged website. If it isn't useful, unique, or meaningfully 'app-like,' it doesn't belong on the store. This is the rejection for thin wrappers: a WebView that just loads your mobile site, an app that's really a marketing brochure, a demo or beta, or something that does so little it feels like a placeholder.

Here's the distinction that saves people a wasted resubmission, because 4.2 and 4.3 both love to flag a WebView wrapper: 4.2 is 'too thin to be an app,' 4.3 is 'too similar to other apps.' A WebView shell can trip both — it's thin *and* it's a shape App Review has seen a thousand times. The fix is the same starting point regardless: add real native functionality. Offline capability, push done well, native device features a browser can't fake, content or data that's genuinely yours. If you can't name in one sentence what your app does that its own website can't, you haven't cleared 4.2 yet.

That's not a review from App Review, of course. It's the kind a real user leaves the week after a thin app squeaks through. Notice the fix is identical for both: give the thing a reason to be an app. The reviewer and the one-star are asking the same question.

5.1.1 is the privacy rejection, and it has more sub-parts than any other on this list. You need a working privacy policy link, you must request permission with a *specific* purpose string (not a generic one), you can only ask for data that's relevant to what the app does, and you can't force a user to hand over personal information or create an account to use features that don't require it. A flashlight app that demands your location and a login will get 5.1.1'd fast.

The one that catches established apps is account deletion: if your app lets users create an account, it must let them initiate deleting that account from inside the app, not just deactivate, and not 'email us to delete.' It's been enforced since 2022 and still rejects apps that only built a sign-up flow. Purpose strings are the other trap. A prompt that says '[App] needs access' with no reason reads as a placeholder. Say what you'll do with it:

Sometimes the reviewer pattern-matched too fast and the rejection is genuinely wrong. You have two escalation paths, and the order matters.

Be honest about which situation you're in. A reskinned template or a WebView with nothing native behind it won't clear through persistence, and grinding the same rejected concept against the queue can escalate. When you do have a real case, the [full 4.3 appeal template](/blog/app-store-review-guideline-4-3-rejections) adapts cleanly to any guideline — swap the differentiator section for whatever the reviewer cited. If your resubmission is just sitting untouched, that's a different problem, covered in [why your app is stuck in review](/blog/app-store-stuck-in-review) and [how long App Store review takes](/blog/how-long-does-app-store-review-take).

Getting past these five guidelines earns you a place on the shelf, not a rating. That's the next fight, and it begins the day your first users arrive. The cheapest lever on your rating after launch isn't another submission; it's answering the reviews you get. When Google shipped recency-weighted ratings at I/O 2019, it reported that developers who respond to reviews see an average lift of 0.7 stars. Apple publishes no equivalent figure, but the mechanism holds on both stores: a calm, specific reply to an early one-star reassures the next hundred people deciding whether to tap Get.

Doing that once is a pleasant afternoon. Doing it for every review across the App Store and Google Play, in each reviewer's own language, without the queue lapsing during launch week, is the part that quietly eats a founder's time. That's the moment [ReplyArgus](/features) is built for: it watches both stores in one inbox and drafts an on-brand reply for each review, grounded in your past approved replies and your store listing, already sized for each store's limits. You approve in a click, or opt in to auto-publish clean 5-star replies so nothing stalls while you're heads-down on the next build. It won't get you past App Review; that's your app's job. But the day after you're approved, it's the review desk you don't have to staff. For a playbook on the hard ones, start with [how to respond to negative app reviews](/blog/how-to-respond-to-negative-app-reviews).

So a guideline number in Resolution Center isn't a verdict on your effort — it's a coordinate. Find which of the five walls you hit, fix that specific axis, and resubmit with a two-sentence note pointing at exactly what changed. Appeal when you have new information, fix and move on when you don't. Clear it, and the shelf is yours — and the reviews that follow are a fight you can win one reply at a time. [Start free with ReplyArgus](/signup), no card required, and the day after you're approved, Argus drafts your first reply in minutes, in the reviewer's own language.