App rejected for looking like a website: Guideline 4.2 fix

What App Store Guideline 4.2 says

Apple's Guideline 4.2 (Minimum Functionality) states that your app should include features, content, and UI that elevate it beyond a repackaged website. In Apple's words, 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 "looks like a website" rejection is a specific application of this rule. When the bulk of your app is a webview pointed at your existing site, reviewers see something that is not sufficiently different from opening that site in Safari, and they reject it.

The official text lives on the App Store Review Guidelines page.

Why apps get rejected under 4.2

Common triggers for the website-wrapper version of a 4.2 rejection:

• The app loads a single webview of your site on launch and offers no native navigation, no native tab bar, and no native screens.
• The interface is identical to your mobile website, so the reviewer cannot tell the app apart from the browser experience.
• There are no iOS capabilities a browser lacks, such as offline access, push notifications, widgets, Shortcuts, or device integration.
• The app is a generic template wrapper generated by a website-to-app tool, with nothing built specifically for iOS.

Apple frames 4.2 around App Store quality. The question a reviewer is asking is simple: does this need to be an app, or is it just your website in a frame.

How to fix it

1. Add native interface elements. Replace the bare webview with native navigation, native screens, and standard iOS controls so the app feels built for the platform, following the Human Interface Guidelines.
2. Add capabilities a browser cannot do. Offline support, push notifications, a home screen widget, Shortcuts and App Intents, or device features like the camera or location all push the app past the website line.
3. Move core content into native views. Where it is practical, render key flows natively rather than inside a webview, so the app is doing real work on device.
4. Cut placeholder and login walls. If the first screen is a webview behind a login the reviewer cannot pass, that compounds the problem. Make the value visible and provide a demo account if a login is required.
5. Explain the native value in App Review notes. Tell the reviewer which native features the app adds, so the difference from your website is easy to find.

Remember that submitted is not approved. A resubmission goes back through review, and Apple judges whether the app is genuinely app-like, not whether it has a new launch screen.

How AppFlight helps

AppFlight builds a native iOS app in Swift and SwiftUI from your plain-English prompt, with no webviews or wrappers, so the app is native from the start rather than a frame around your site. It can wire in native capabilities that 4.2 looks for, including Widgets, Live Activities, App Intents, Shortcuts, Siri, and Spotlight, plus integrations like push-capable analytics through PostHog and a Supabase backend. When Apple returns a 4.2 rejection, AppFlight reads the rejection reason, works on the issue, and resubmits the build. If your product really only makes sense as a website, the honest answer is that no rebuild changes that, and AppFlight does not guarantee approval. Apple reviews every app and every resubmission.