App rejected under Guideline 4.0 Design for looking like a website
What App Store Guideline 4.0 says
Guideline 4.0 opens Apple's Design section. In Apple's words, customers place a high value on products that are simple, refined, innovative, and easy to use, and that is what Apple wants to see on the App Store. The section sets the minimum design standards for approval, and Apple notes that even after an app is approved it should be kept functional and engaging, since apps that stop working or offer a degraded experience can be removed.
A looks-like-a-website rejection is the design side of the webview-wrapper problem. The reviewer is judging whether the app presents a native, app-like experience. A bare webview of your existing site does not, so it can be cited under 4.0 Design, often alongside Guideline 4.2 Minimum Functionality. The official text lives on the App Store Review Guidelines page.
Why apps get rejected under 4.0
Common triggers for the website-wrapper version of a 4.0 rejection:
- The app opens a single webview of your mobile site and has no native navigation, no native tab bar, and no native screens.
- The interface is identical to the website, so the reviewer cannot tell the app apart from Safari.
- There are no iOS capabilities a browser lacks, such as offline access, push notifications, widgets, Shortcuts, or device integration.
- The app was produced by a website-to-app tool from a generic template, with nothing built for iOS.
- Browser-style elements such as a loading bar or non-persistent login make the web origin obvious.
The thread is the same in each case. The app does not feel designed for the platform, so under 4.0 it does not meet the bar.
How to fix it
- Add native interface elements. Replace the bare webview with native navigation, native screens, and standard iOS controls, following the Human Interface Guidelines.
- 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.
- Render core flows natively. Where it is practical, build key screens in native views rather than inside a webview, so the app does real work on device.
- Remove blockers in front of the value. If the first screen is a webview behind a login the reviewer cannot pass, fix that and provide a demo account if a login is required.
- Note 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 the native capabilities that 4.0 and 4.2 look for, including Widgets, Live Activities, App Intents, Shortcuts, Siri, and Spotlight, plus integrations like analytics through PostHog and a Supabase backend. When Apple returns a 4.0 rejection, AppFlight reads the rejection reason, works on the issue, and resubmits the build. If your product really only makes sense as a website, no rebuild changes that, and AppFlight does not guarantee approval. Apple reviews every app and every resubmission.
FAQ
Is Guideline 4.0 the same as Guideline 4.2?
They are related but not identical. 4.0 is the Design section that asks apps to be simple, refined, and easy to use. 4.2 is Minimum Functionality. A looks-like-a-website rejection often cites 4.0, 4.2, or both, because a webview wrapper fails the design bar and the functionality bar at the same time.
Why does Apple say my app looks like a website?
A reviewer sees an app that loads your mobile site in a webview with no native navigation, no native screens, and no iOS capabilities a browser lacks. Under 4.0 that reads as a non-native experience, so it is rejected. The fix is genuine native structure, not a launch screen.
Can a webview app ever pass Guideline 4.0?
Webviews are allowed in support of a native app. What fails is an app that is only a webview of your site. Adding native navigation, native screens, and capabilities like push notifications, widgets, or offline support is what moves it past the line.