App Store rejection: Guideline 4.2 minimum functionality, and how to fix it

What App Store Guideline 4.2 says

Apple's Guideline 4.2 (Minimum Functionality) says 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 does not belong on the App Store, and if it does not provide some lasting entertainment value or adequate utility, it may not be accepted.

The subpoints add detail. 4.2.2 says that other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. 4.2.3(i) says your app should work on its own without requiring installation of another app to function, and 4.2.3(ii) says if it needs to download resources to function on first launch, it must disclose the size and prompt the user. 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless submitted directly by the provider of the app's content.

The full text is on the App Store Review Guidelines page.

Why apps get rejected under 4.2

Common triggers:

• A webview wrapper that loads a website inside the app with little or no native functionality.
• An app that is mostly a set of links, a feed pulled from elsewhere, or a marketing brochure.
• A thin app with one trivial screen and no lasting utility or entertainment value.
• An app that does not work without installing or signing into a separate app.
• Cookie-cutter apps from a template service submitted at scale rather than by the content provider, which overlaps with 4.2.6.

Apple frames 4.2 around whether the app is genuinely app-like and useful. If the experience is essentially a website in a frame, it fails.

How to fix it

1. Build native features. Add functionality that lives in the app: offline behavior, native navigation, notifications, device integrations, or interactive features a website cannot match.
2. Replace the webview with native screens. Where you were loading web content, build the experience in SwiftUI so it behaves like an app, following the Human Interface Guidelines.
3. Make it stand on its own. Ensure the app works without requiring a separate companion app, and if it needs an initial download, disclose the size and prompt the user.
4. Add lasting value. Give users a reason to return: saved state, personalization, content that updates, or a workflow they complete in the app.
5. Document the native functionality in review notes. Point the reviewer to the features that make it app-like.

Submitted is not approved. The reviewer judges whether the resubmission is genuinely app-like, so the fix is real functionality, not a reskinned wrapper.

How AppFlight helps

AppFlight builds a native iOS app in Swift and SwiftUI, with no webviews or wrappers, so the output is the kind of native, app-like experience 4.2 asks for rather than a repackaged website. It can also wire in native capabilities such as Widgets, Live Activities, App Intents, and Shortcuts, which add the lasting utility reviewers look for. When Apple returns a 4.2 rejection, AppFlight reads the rejection reason, works on the fix, and resubmits, for example by deepening the native functionality of a thin app. AppFlight does not guarantee approval. Apple reviews every app and every resubmission, and a thin concept needs genuine features to pass, not just a rebuild.