# Guideline 4.2 - Design: Web Wrapper or Repackaged Website

**Guideline:** 4.2 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** hard · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/apple/4/guideline-42-design-web-wrapper-or-repackaged-website

## Description

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.

## Common variations

- App is a repackaged version of a website
- Experience is not sufficiently different from a web browsing experience
- App primarily loads web content in a web view
- App does not include features that make it a unique native experience
- App could be replaced by a Safari bookmark or web app

## Example rejection email

```
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.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High — this rejection signals a fundamental architecture problem
- **Resolution path:** Add native functionality or rebuild with native/hybrid framework
- **Typical turnaround:** 1-3 days (if adding features) to weeks (if rebuilding)

## The Fix

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?'

## Appeal guidance

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.

## Before / after examples

**Before:** App loads entire e-commerce site in a full-screen WKWebView with no native navigation, no offline mode, and visible responsive web breakpoints
**After:** 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
**Why it works:** The app must offer native experiences that go beyond what Safari provides. Each major screen should use native UI components.

## Common questions

**Can you appeal a 4.2 rejection?**

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.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-42-design-web-wrapper-or-repackaged-website*