Apple Guideline 4.2: What Minimum Functionality Means

Apps get rejected for lacking minimum functionality

Your app loads. The UI renders. Users can interact with it. And then Apple rejects it with Guideline 4.2: Minimum Functionality. The feedback is polite but firm: "Your app should include features, content, and UI that elevate it beyond a repackaged website."

This rejection confuses developers because the app works. There are no crashes, no bugs, no policy violations. The problem isn't that something is broken. The problem is that Apple doesn't think your app does enough to justify being an app. It could have been a website, a bookmark, or a Safari shortcut, and the experience would have been the same.

Guideline 4.2 is Apple's quality floor. It's not about whether your app functions. It's about whether it functions like an app.

What does Guideline 4.2 actually say?

From Apple's App Store Review Guidelines, section 4.2:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store. If your App doesn't provide some sort of lasting entertainment value or adequate utility, it may not be accepted.

Sub-guideline 4.2.2 adds:

Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.

Apple expects apps to leverage the platform. If your app is a thin layer over web content, a single-purpose utility that iOS already handles, or a marketing brochure with an icon, it doesn't meet the threshold.

Which app types trigger a 4.2 rejection?

1. WebView wrapper apps

This is the most common 4.2 rejection. You have a responsive website, you wrap it in a WKWebView, add an app icon, and submit. The resulting app is technically functional, but it provides no value beyond what Safari already delivers.

Reviewers catch this fast. They look for telltale signs: web-style loading indicators, no native navigation patterns, non-persistent login sessions, standard browser error pages when offline, and web-style hamburger menus instead of native tab bars.

If a reviewer can reproduce your entire app experience by visiting a URL in Safari, you'll get rejected.

2. Single-feature utility apps

A flashlight app. A tip calculator. A unit converter. A QR code scanner. iOS provides all of these natively. An app that replicates a built-in feature without adding significant value doesn't pass the 4.2 threshold.

The bar isn't impossible here, but it's high. A QR code scanner that also manages inventory, tracks scan history across devices, and integrates with your POS system has a reason to exist. A QR code scanner that scans QR codes doesn't.

3. Marketing and brochure apps

An app that shows your company's address, phone number, a photo gallery, and a "contact us" form. Maybe it includes your menu, your service list, or your portfolio. If the entire content of your app could be a single web page, Apple will suggest you make it a single web page.

4. Content aggregator apps

An app that pulls RSS feeds, scrapes articles, or aggregates content from other sources without adding editorial value, curation, personalization, or functionality on top of that content. Apple considers these "collections of links" and rejects them under 4.2.2.

5. Apps that duplicate another app you already have

If you already have an app in the store and you submit a second app with overlapping functionality, 4.2 can apply even if the first app passes review. The reviewer asks: "Why isn't this a feature in your existing app?"

What do Apple reviewers look for in a 4.2 evaluation?

Apple's review process isn't entirely transparent, but developer reports from the Apple Developer Forums and resolution center conversations reveal consistent evaluation patterns.

The 60-second test

Reviewers form an initial impression quickly. They launch the app, navigate the primary flow, and assess whether the experience feels native to iOS. In the first minute, they're looking for:

• Native navigation. Tab bars, navigation controllers, swipe gestures. Not a WebView with a JavaScript navigation layer.
• Offline behavior. What happens when they toggle airplane mode? A real app degrades gracefully. A web wrapper shows a browser error.
• System integration. Does the app use push notifications, HealthKit, Siri, Shortcuts, widgets, or any iOS-specific capability? Or could this entire experience run in Chrome on a laptop?
• Content depth. Is there enough content and functionality to keep a user coming back? Or is this a one-and-done interaction?

The "why not a website?" question

This is the implicit question behind every 4.2 evaluation. If the reviewer can articulate a reason your app needs to exist as a native application, you pass. If they can't, you don't.

Features that answer this question: - Push notifications (Safari on iOS supports web push, but native push offers silent background delivery, notification service extensions, and rich grouped notifications that web push can't match) - Offline data caching and sync - Camera, microphone, or sensor access - Background processing - HealthKit, HomeKit, or Core Location integration - Widgets and Lock Screen presence - App Intents and Siri integration - Apple Pay and in-app purchases - Inter-app communication via share extensions or custom URL schemes

Content depth evaluation

For content-based apps, reviewers evaluate volume and quality. An app with three articles and a contact page isn't an app. An app with a structured content library, search, categories, bookmarking, reading progress, and personalization has crossed the threshold.

There's no published minimum, but developer reports suggest that apps with thin content libraries (under 10-15 distinct content items) face higher scrutiny.

Real use cases: what passed and what didn't

Rejected: restaurant app with menu and hours

A restaurant submitted an app showing their menu, opening hours, location on a map, and a phone number to call. Rejected under 4.2. The reviewer noted that this information was better suited to the restaurant's website.

What would have passed: Adding online ordering, table reservations, a loyalty program, push notifications for daily specials, and Apple Pay integration. These features require native capabilities and provide a reason to install an app instead of bookmarking a website.

Rejected: news reader with WebView articles

A tech news aggregator loaded articles in a WebView, had a list of sources, and offered basic bookmarking. Rejected under 4.2. The developer added thumbnails, parsed content rendering, and local bookmarks. Rejected again. The reviewer still saw it as a glorified RSS reader.

What eventually passed: Native content rendering (not WebView), offline reading with background sync, personalized feed algorithms based on reading behavior, topic-based push notifications, and a widget showing top stories. The app stopped being a content pipe and became a reading experience.

Rejected: company portfolio app

A design agency submitted an app showcasing their work. Photo gallery, team bios, contact form. Rejected under 4.2.2 as a marketing brochure.

What would have passed: If the app served as a client collaboration platform (project timelines, feedback on designs, file sharing, revision tracking), it has utility beyond marketing. The portfolio becomes one section of a functional app, not the entire purpose.

Passed: specialized calculator for construction

A basic calculator won't pass. But a construction calculator that handles material estimates for concrete, lumber, and drywall, converts between imperial and metric with trade-specific units, saves calculations to project files, and exports PDF quotes has clear differentiation. It passed because no website provides this workflow with the same convenience.

Passed: community app with native features

A local community app wrapped around a forum might get rejected. But one that integrates local event calendars with MapKit, sends geo-fenced push notifications for nearby events, supports Apple Pay for ticket purchases, and provides a home screen widget showing upcoming events provides genuine platform integration.

How to fix a 4.2 rejection

If you've been rejected, here's the practical playbook.

Step 1: Audit your native feature count

List every feature in your app that requires the iOS platform. Not features that happen to be in your app, but features that wouldn't work in a browser. If the list is short (zero to two items), that's your problem.

Step 2: Add platform integration, not screens

More screens don't fix a 4.2 rejection. More native integration does. Pick three to five integrations from this list based on what makes sense for your app:

Integration	What it signals to reviewers
Push notifications	Real-time engagement beyond browser capability
Offline mode with local storage	The app works without a connection
HealthKit / Core Location	Hardware and data integration
Widgets / Lock Screen	Persistent presence outside the app
App Intents / Siri Shortcuts	System-level integration
Apple Pay	Native transaction flow
Camera / Photo Library	Hardware access with a purpose
Background sync	Data freshness without user action
Share extensions	Inter-app communication
Core Data / SwiftData	Structured local persistence

Step 3: Replace WebView with native rendering

If your app uses WKWebView for primary content, replace it with native UI components. SwiftUI views, UIKit table views, native navigation. The content can still come from your API, but the rendering should feel like an iOS app, not a web page.

This is the single most impactful change for WebView wrapper rejections. Even if you keep some WebView for secondary content (like help articles or terms of service), the primary user experience needs to be native.

Step 4: Add offline value

When the reviewer toggles airplane mode, your app should still be useful. Cached content, saved data, recently viewed items, local features. An app that becomes a blank screen without a network connection doesn't pass the "why not a website?" test.

Step 5: Write a clear app description

Your App Store description should make it obvious why this is an app and not a website. Lead with the native features. Mention push notifications, offline mode, widget support, or hardware integration. Make it easy for the reviewer to find your differentiation.

The threshold is lower than you think (but real)

Here's the good news: Apple isn't asking for a masterpiece. They're asking for an app that justifies being an app. Three to five meaningful native integrations, a UI that feels like iOS instead of a web page, and content depth that gives users a reason to come back.

The threshold isn't "build something Apple has never seen." The threshold is "build something that a website can't replace." If your app leverages the device, works offline, sends relevant notifications, and provides a native experience, you'll clear 4.2.

But if your app is a URL in a frame with a custom icon, no amount of appealing will change the outcome. The fix is building a real app.

Like 4.3(a) spam rejections, Guideline 4.2 evaluates product decisions, not binary-level technical compliance. AppCompliance handles the technical layer: privacy manifests, SDK risks, permission audits, ATS configuration, and other issues detectable from the compiled binary. But no tool can evaluate whether your app provides enough native functionality to satisfy Apple's minimum bar. That's an architecture and product decision that starts before the first line of code.

Store review combines objective technical checks with subjective quality evaluation. Automate the technical side with a pre-submission checklist. Design the product side with intention.