App Store Reject

Guideline 4.2

Guideline 4.2 - Design: Web Wrapper or Repackaged Website

High SeverityHard FixTypical Fix: 1-3 days0 Reports
Also known as:App is a repackaged version of a websiteExperience is not sufficiently different from a web browsing experienceApp primarily loads web content in a web viewApp does not include features that make it a unique native experienceApp could be replaced by a Safari bookmark or web app

Our Take

Apple is rejecting your app because it is essentially a repackaged website — a thin native shell around a WKWebView that loads your existing web content. This is the most common 4.2 rejection by a wide margin. Apple's position is that if your app's core experience is identical to visiting your website in Safari, it doesn't provide enough value to justify being a standalone app. The reviewer likely opened your app, saw it was loading web pages (possibly with visible URL bars, web-style navigation, or responsive web layouts), and flagged it. This rejection is frequently triggered by: apps built with website-to-app converters (WebViewGold, Median, GoNative), businesses that wrapped their existing website for mobile, or PWA-style apps that just load a remote URL. Even if you've added a native navigation bar or tab bar, if the content screens are all web views, you'll get this rejection. The fastest compliant path depends on your situation. If your website is already responsive and works well in Safari, you may be better off submitting a Safari Web App (Home Screen bookmark) instead. If you need a native app, you need to add meaningful native functionality — push notifications alone are not enough. Think native UI components, offline capability, device API integrations (camera, HealthKit, ARKit), or features that genuinely cannot be replicated in a browser.

Resolution Guide

01

Audit your web view usage

Count how many screens in your app are WKWebViews loading remote content vs. native SwiftUI/UIKit views. If more than 50% are web views, you have a problem.

02

Add native UI for core screens

Rebuild your most-used screens (home, profile, settings, main content view) using native SwiftUI or UIKit components. These don't need to be complex — native table views, native navigation, and native forms go a long way.

03

Implement offline capability

Cache content for offline access. Even basic offline reading or viewing of previously loaded content demonstrates native value.

04

Integrate device APIs

Add at least two meaningful device integrations: push notifications with rich content, camera/photo library for profile pictures or content creation, biometric authentication, Widgets, Shortcuts, or HealthKit/MapKit integration where relevant.

05

Replace web navigation with native navigation

If you must keep some web views, wrap them in native navigation controllers with native back buttons, native tab bars, and native pull-to-refresh.

06

Remove visible web artifacts

Ensure no web loading indicators, URL bars, or responsive web breakpoints are visible. The app should feel native even when displaying web content.

Prevention

  • Don't use website-to-app converters for your primary App Store submission
  • Plan native features from the start — at minimum: native navigation, native auth, push notifications, and one device API integration
  • Use a hybrid framework (React Native, Flutter) instead of pure web views if you need code sharing
  • Test your app's value proposition: 'What can users do here that they can't do on our website in Safari?'

    • Example Rejection Email

    From:Apple App Review Team
    Subject:Guideline 4.2 - Design: Web Wrapper or Repackaged Websit
    Guideline 4.2 - Design - Minimum Functionality We found that the experience your app provides is not sufficiently different from a web browsing experience. Specifically, your app is a repackaged version of your website that does not include features or content that make it a unique experience as a native app. It would be appropriate to provide a native iOS app experience that goes beyond what a website provides. For example, consider implementing native iOS features such as: - Push notifications - Native UI elements - Offline functionality - Camera or photo library integration - Device hardware features Alternatively, if your primary purpose is to provide a web-based experience, you may want to consider creating a Safari Web App instead. Next Steps: Please revise your app to include meaningful native functionality or consider distributing your content as a web app.

    Consider Appealing

    Appealing a web wrapper rejection rarely works unless the reviewer missed native functionality that exists but wasn't obvious. If you have genuine native features, reply in Resolution Center explaining exactly where they are and provide steps to access them. If the app truly is a web wrapper, fix and resubmit — Apple won't budge on this.

    Generate Appeal

    Before & After

    Before — Rejected

    App loads entire e-commerce site in a full-screen WKWebView with no native navigation, no offline mode, and visible responsive web breakpoints

    After — Approved

    Home feed rebuilt in native SwiftUI with LazyVGrid, product detail uses native image gallery with pinch-to-zoom, checkout uses native form with Apple Pay, push notifications for order updates, and recently viewed items cached for offline browsing

    What changed: The app must offer native experiences that go beyond what Safari provides. Each major screen should use native UI components.

    Community Solutions · 0

    Sign in to share your solution.

    More Guideline 4 (Design) rejections

    View all Guideline 4 rejections