Home / App rejections: fix guides for App Store and Google Play / Guideline 4.2: minimum functionality rejection

Guideline 4.2: minimum functionality rejection

Quick answer: A Guideline 4.2 rejection means Apple thinks your app doesn't do enough to be an app: often a website in a web view, a single-screen utility, or marketing content. Fix it by adding features that use the device and work better than the website, such as offline access, notifications, camera or widgets.

How to fix a 4.2 rejection, step by step

Follow these steps in order. Each one is something we do on client work.

  1. Read the reviewer's reason. 4.2 says your app should go beyond a repackaged website and be useful, unique or app-like.
  2. List native features. Offline access, notifications, widgets, device features, or a better UI than the website.
  3. Build one meaningful native feature. Pick the one your users need most and ship it.
  4. Remove web-only chrome. Browser-style navigation and hamburger menus copied from the site feel like a wrapper.
  5. Update screenshots. Show the new native features.
  6. Explain the value in the reply. Name the features and where to find them.

Guideline 4.2 rejection: key rules and context

What the rejection means. Guideline 4.2 says apps should include features, content and UI beyond a repackaged website (Review Guidelines).

Why it usually happens

  • A WKWebView loading your site with no native features.
  • A catalog or brochure app.
  • An app that only links out to other apps or sites.

How to fix it

  1. Identify what users would do daily in the app.
  2. Add native features: push notifications, offline mode, device integrations, widgets, native navigation.
  3. Make the core flows native, not web pages.
  4. Show those features in screenshots and review notes.

What to tell the reviewer. List the native features with where to find them. Don't just say "the app is useful".

How to avoid it next time. If you're starting from a website, plan native value before submitting.

Common mistakes

  • Adding a splash screen and calling it native. Cosmetic changes don't count.
  • Only one screen of content. Apps need enough features to be useful.
  • Screenshots of the website. Show the app.
  • Arguing it works fine. Show value instead.

If you want this handled for you, our pricing page lists every fixed package.

Worked example (hypothetical)

This example is illustrative. The app is made up, and so are any numbers in it.

Suppose CityBites, a restaurant guide, is a WebView of its site. We'd add a native saved-places list that works offline and a nearby view using location, rebuild the home screen in native UI, and reply: "The app now includes offline saved places and a native map of nearby restaurants."

The guidelines behind most rejections

The table maps each point to the guideline 4.2 rejection context. Rows are quoted or summarised from Apple's current App Review Guidelines. Use the row that matches your message to decide whether to fix the build, the metadata or both.

GuidelineWhat it coversUsual fix
2.1 App CompletenessFinal builds, working URLs, no placeholder contentFix crashes, add a demo account, test every link
2.3 Accurate MetadataDescription, screenshots and previews reflect the appRe-shoot screenshots from the real app; remove claims you can't show
2.3.7Unique name, accurate keywords, no trademarked or irrelevant termsRemove competitor names and pricing from metadata
3.1.1 In-App PurchaseDigital features and content unlocked via IAPMove digital unlocks to StoreKit IAP
4.2 Minimum FunctionalityMore than a repackaged websiteAdd native, useful features
4.3 SpamNo duplicate bundle IDs or saturated copycat appsConsolidate apps; show what is unique
5.1.1 Data Collection and StoragePrivacy policy, permissions, account deletion (5.1.1(v))Add policy links, clear purpose strings, in-app deletion

Checklist

Copy this list into your release notes or ticket and tick each item off before you ship.

  • Reason read and quoted
  • At least one meaningful native feature
  • Native navigation
  • Screenshots updated
  • Reply names the features

Sources

FAQ

Questions

Are web view apps banned?

No, but they need meaningful native features.

Are push notifications enough?

Usually not alone.

Are hybrid frameworks OK?

Yes, Flutter and React Native apps are fine if functional.

Does 4.2 overlap 4.3?

Sometimes; template apps can trigger both.

Can you advise what to add?

Yes, in the rejection fix package.

Is a WebView app always rejected under 4.2?

Not automatically, but an app that's only a repackaged website often is available by email. Native features that add value change the picture.

Ready when you are

Fix your listing this week.

One fixed price, delivered as copy and files you paste yourself. No calls, no account access.

$99 one-timeDelivered in 2–3 business days2 revisionsNo login needed
Questions? Email us
Rank higher. More installs.Want your app ranked and more installs?
Get HireASO