What guidelines 4.0 and 4.2 actually say

Apple's App Store Review Guidelines section 4 covers Design. Two parts trip up new apps most often:

The phrase reviewers lean on is lasting value. Apple explicitly says apps that are "simply a song or movie should be a media file" and apps that are "a book or game guide should be an ebook" — the app format has to earn its place. If your app could just as easily be a webpage or a PDF, that's the problem 4.2 is describing.

The core test: does your app do something a mobile browser tab couldn't do just as well? If the honest answer is no, that's what a 4.2 rejection is telling you — and it's a product problem, not a paperwork one.

The most common triggers

Website in a wrapper

The classic 4.2 rejection. If your app is essentially a WKWebView pointed at your existing site with no native capabilities, Apple will reject it. This is the single most-cited minimum-functionality case. It doesn't mean web content is banned — it means web content alone isn't enough.

Too few features / thin utility

A single-purpose app that does one trivial thing (a flashlight, a static tip calculator, a countdown) with no depth can be judged too limited. Apple isn't against simple apps — but simple has to still be genuinely useful and well-made.

Template / clone apps

Apps built from a commercial template with only cosmetic changes, or one of many near-identical apps from the same account, get caught under 4.0 (and often 4.3, the "spam" guideline). If your app looks like a hundred others, that's a design-quality flag.

Placeholder or unfinished content

Lorem ipsum, empty states with no data, "coming soon" screens, or features that don't work yet read as an incomplete app — which reviewers treat as failing the design bar.

Concrete ways to add functionality

The fix for a 4.2 rejection is almost always to make the app meaningfully native. Practical additions that reviewers recognize as real functionality:

You don't need all of these. You need enough that the app clearly belongs on the device rather than in a browser tab. Pick the one or two that fit your product and implement them well.

How to respond to the rejection

  1. Read the Resolution Center note carefully. Apple usually names the exact guideline (4.0 vs 4.2) and often gives a sentence on what was missing. That tells you whether it's a polish issue or a fundamental "add native features" issue.
  2. Decide: polish or product. A 4.0 design citation can sometimes be addressed with UI cleanup. A 4.2 minimum-functionality citation usually needs actual features — don't try to argue your way past it without changing the app.
  3. Reply factually if you disagree. If you believe the reviewer missed existing functionality, point to it specifically in Resolution Center. But if the app really is thin, building rather than arguing is the faster path.
  4. Resubmit with the new build. Since 4.x fixes change the app itself, you'll upload a new binary and go back through review. For what to expect there, see the App Store review status guide.

Guideline 4.3 (design spam / duplicate apps) is a close cousin of these rejections and often shows up alongside them. If your rejection mentions 4.3, our deep dive on the 4.3 design spam rejection covers that specific case. For the broader list of what gets apps bounced, see the most common App Store rejection reasons.

Where your listing fits in

A 4.2 rejection is fundamentally about the app, not the listing — no screenshot will convince a reviewer that a thin app is substantial. But once you have added real functionality, your product page is how you prove it. Reviewers (and users) form a first impression from your screenshots, and screenshots that show genuine, native features working reinforce that the app clears the bar.

That's where showing real screens matters. With ezscreenshots you drop your actual app captures — the notification, the offline view, the camera integration you just built — pick the right preset for each device size, add captions that name the feature, and export the full set in minutes, no account or export limit, all in the browser. Screenshots that demonstrate real functionality both satisfy guideline 2.3.3 and make the "lasting value" case at a glance. If you're rebuilding the listing after adding features, the screenshot template guide covers what a strong first screenshot should show.

Added real features? Show them off.

Once your app clears the minimum-functionality bar, screenshots of genuine native features make the case to reviewers and users alike. ezscreenshots turns your real captures into a polished, correctly-sized set in minutes. Free, browser-based, no account.

Try ezscreenshots →

Summary