Guideline 4.2 Minimum Functionality: App Rejected

Guideline 4.2, "Minimum Functionality," rejects an app that offers nothing more than a website, or too little to be worth keeping. The fix isn't piling on native features: it's putting one at the core of the experience, then telling the reviewer where to find it. The fix almost always requires a new build.

I publish my own iOS apps: Solys, TradaZen and Nolera are on the App Store. This guide is based on Apple's official text, read on October 15, 2026, and on 4.2 rejections posted by developers on Apple's forums. The rejected apps mentioned below are examples. For an overview of every rejection reason, read why Apple rejects an app instead.

What does guideline 4.2 say?

4.2 sits in section 4, "Design," of the App Review Guidelines. Its first sentence sets the bar: "Your app should include features, content, and UI that elevate it beyond a repackaged website." In other words, your app needs features, content and an interface that lift it above a website stuffed into a box.

The text adds two ideas. An app that isn't particularly useful, unique or "app-like" doesn't belong on the App Store. And an app that offers neither lasting entertainment value nor adequate utility may be rejected. So 4.2 judges two things: how different you are from the web, and how much value you offer.

The sub-rules the message can cite

Sub-rule	What Apple asks for	The typical rejection
4.2	Go beyond a website	Site shown in a WebView
4.2.1	A real augmented reality experience	A 3D model dropped into the AR view
4.2.2	Not just marketing or links	Showcase app, aggregator, links
4.2.3	A standalone app, clear downloads	App that requires another app
4.2.6	No app built from a commercial template	Template submitted by an agency

Three clarifications. 4.2.2 makes an exception for catalogs: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." So a product catalog can get through. An advertising brochure can't.

4.2.3 has two clauses. (i) requires the app to work on its own, without installing another app. (ii) requires that, if the app has to download resources on first launch, it states the download size and asks for consent first.

4.2.6, about commercial templates and app generation services, is covered in the guideline 4.3 guide, because it goes hand in hand with the anti-spam rule.

The two most common 4.2 messages

Apple's message opens with the title "Guideline 4.2 - Design - Minimum Functionality." What follows tells you which of the two problems the reviewer saw. Here are two wordings posted by developers on Apple's forums. They're a few years old: the exact text may have changed, the two families haven't.

The app looks like a website. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." This message, posted on Apple's forums, contains a decisive sentence: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

The app is too thin. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." This second message asks you to rethink the concept, and admits there's no numeric rule defining what counts as useful or entertaining.

Adding notifications, location and a share button to a wrapped website isn't enough: Apple wrote so in its own rejections.

Four typical 4.2 rejection cases

The four cases below are examples built to illustrate the rule, not real apps.

The wrapped website

Example: a gym shows its mobile site in a WebView, with a native tab bar on top. The schedule, booking and account are web pages. The reviewer sees exactly what Safari would show. Apple says it on its App Review page: a website served in an iOS app, web content not tailored to iOS, or limited web interactions don't make a quality app.

What I'd do: rebuild the screens of the core action natively, here the schedule and booking. Then add what the site can't do: a reminder before the class, the schedule available offline, the next class in a widget.

The app that's too simple

Example: an app that shows one quote a day, and nothing else. You've seen it all in ten seconds. 4.2 talks about "lasting entertainment value or adequate utility": value that lasts, or enough usefulness. To fix it, add depth to the core action, not screens around it. Here: a history, favorites, a reminder at a time you choose, a Home Screen widget.

The AI-generated app with nothing native

Example: a text field, a button, an AI response shown as plain text. Apple doesn't judge the tool, it judges what lands on the reviewer's screen. If the experience fits in a web page, 4.2 is likely to hit.

I go into what AI does well and what it misses in building an app with AI. The format each generator produces, web app or mobile project, is compared in Lovable, Rork or FlutterFlow.

The empty shell waiting for content

Example: a marketplace with no listings, an empty directory, a feed showing "Coming soon." The reviewer opens an app with nothing to show. This case also touches 2.1, which rejects placeholder content: see the guideline 2.1 guide. Submit the app once it has real content, or provide a demo account that's already filled in.

The test I run: "What about Safari?"

Before submitting, I ask myself whether a website could offer the same core feature. If yes, the app is exposed to 4.2. Here's my grid for judging a native feature. A feature counts when it serves the core action, not when it's decoration.

Feature	It counts when...	It's not enough when...
Notifications	They deliver information people expect	They relay your blog posts
Offline	The main content stays usable	Only an error screen shows up
Widget	It shows data specific to the person	It shows your logo
Sharing	People send content into your app	It only shares a link
Camera, sensors	They're part of the core action	They open your website
Local data	The app calculates, organizes and remembers	Everything lives on a web page

Apple's recommendations point the same way. A widget shows timely content you can read at a glance. A notification delivers useful information in few words, and isn't there to push people toward a task in the app.

What my apps do that a website can't

I design each app around a core feature that doesn't exist in a browser, or around value that brings people back.

• Solys is an alarm clock. The alarm runs through AlarmKit, the iOS 26 alarm service: it cuts through silent mode, like Apple's own alarm. To stop it, you have to win a mini-game, and the apps you picked stay paused after you wake up. No web page can make an iPhone ring on silent.
• TradaZen is a trading simulator: a real chart on a real date, a decision, candles that reveal themselves, ranked duels and a rank that climbs. Here, it's not a native feature carrying the app. It's the lasting entertainment value 4.2 talks about.
• Nolera is a wardrobe app: you photograph your clothes, the app cuts them out and organizes them, then suggests an outfit every morning. The camera is part of the core action. It's not a bonus.

4.2 doesn't require a list of native features: it requires a reason to install the app instead of opening a website.

Fixing a 4.2 rejection, step by step

1. Identify the family. Web browsing: it's the wrapped website. Minimal content or features: it's the app that's too thin. 4.2.3: a dependency on another app or an undisclosed download.
2. Change the product, not the wording. A reply that argues without changing anything has no reason to convince anyone. Rebuild the core action screens natively, or add the missing depth.
3. Plan for a new build. The cause is in the app: an over-the-air update isn't enough. Every submission goes back through the queue, see App Store review time.
4. Write review notes that guide. On its page about information for a complete review, Apple asks you to describe the concept, the features and the audience. For an update: what changed, and where to find it.
5. Appeal only if the reviewer missed something. If your native feature already existed but wasn't seen, reply in App Store Connect with a short video. An appeal to the App Review Board makes sense when your app was misunderstood, not when it's thin.

The notes template I'd use, in English, to adapt:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Only write what exists in the build you submit. A feature you announce that can't be found would get you another rejection, under 2.1 this time.

The 4.2 checklist before submission

• You can say in one sentence what your app does that a website can't.
• The core action screens are native, not web pages.
• Every native feature serves the core action, and the reviewer runs into it in under two minutes.
• The app has real content from the first launch, or a filled-in demo account.
• The app works on its own, with no other app to install.
• A large download on first launch states its size and asks for consent.
• The review notes describe the concept, the audience and where each feature is.
• If your idea is close to the line, you tested it before coding, with a well-scoped iOS app MVP.

Passing 4.2 on your next submission

If your app was just rejected under 4.2, the Apple Review Kit helps you find the cited rule and what it asks for, with review note templates for the tester. If you're still building, the iOS Kit path starts from the core feature before the first line of code. For a human eye, book an hour with me. The full approach is on the app rejected by Apple page.

If you're preparing your first release, take your free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist. The home page shows how to build a mobile app designed for review from the start.

Nobody can guarantee Apple will accept your app. I can help you give it a reason to exist on the App Store.

Frequently asked questions

What does "Guideline 4.2 - Design - Minimum Functionality" mean?

It's the title of the minimum functionality rejection. Apple thinks your app looks too much like a website, or offers too little content or too few features. The same title can point to a sub-rule: "Guideline 4.2.2" for a showcase app or a list of links, 4.2.3 for an app that depends on another app.

Is a WebView app always rejected?

No. The rule targets a website repackaged as an app, not the technology. The reviewer judges the core experience: if its screens are web pages doing the same thing as Safari, the risk is high. A help page opened in the browser isn't the issue.

Is adding push notifications enough to pass 4.2?

No. In a rejection message posted on its forums, Apple writes that notifications, location and sharing aren't enough to make the experience rich enough. A notification counts when it serves the core feature, like an alarm or a reminder the person chose.

What's the difference between guideline 4.2 and 4.3?

4.2 judges your app on its own: does it offer enough compared to a website? 4.3 compares it to others: is it a copy, a variant, or one more app in a saturated category? The same app can get both, but they aren't fixed the same way.

Do you need a new build after a 4.2 rejection?

Almost always, since the cause is in the app itself. The only exception: the reviewer didn't find a feature that already existed. In that case, reply in App Store Connect with precise notes and a short video, without changing the build.