Convert a website to a mobile app, and Apple will ask what it does that the site does not.

The guideline is 4.2, and it is shorter than you think

The rejection cites guideline 4.2, Minimum Functionality, and the opening line does the work: your app should include features, content, and UI that elevate it beyond a repackaged website. It adds that an app without lasting entertainment value or adequate utility may not be accepted. No threshold is given. It is judgement, applied to your build by someone using it.

Clause 4.2.2 names the thing directly. Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. A converter output is a web clipping with an icon. A home screen of buttons that each load a page of your site is a collection of links.

Clause 4.2.6 catches the converter services themselves. Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The service cannot submit on your behalf. The app goes up from your own Apple Developer account, and the same clause tells template providers to offer tools that let clients build customized apps instead.

None of this bans web views, and plenty of pages on this topic get that backwards. Apps embed them constantly for help centres, legal pages and checkouts that already exist. The word in 4.2.2 is primarily. The rule is about what the app mostly is.

App Store Review Guidelines, 4.2 Minimum Functionality

What actually clears the bar

Elevate beyond a repackaged website stays vague until you list what a page in a frame cannot do. Data that is still there in airplane mode, because it lives on the device. The camera and photo library, including barcode and document scanning. Face ID or Touch ID instead of a typed password. A notification that arrives while the person is somewhere else. Background location, a widget, a share extension, a Siri shortcut. Navigation that matches the phone: a tab bar that keeps its state, a swipe back, a keyboard that behaves.

The common mistake is to treat that as a shopping list and buy one item. Teams pick push notifications, bolt them onto the wrapper and resubmit. It is the most common second attempt, and the most common second rejection. Guideline 4.2 asks what the app primarily is, and one feature attached to a site in a frame does not change the answer.

One capability is worth singling out, because users notice it within a day. Your website already has URLs and people already share them. Once the app exists, a pasted link should open the screen it points at rather than a home page. That is mobile app deep linking, and on iOS it is a file served from your own domain plus an entitlement on the app, so the site you are converting is already half the setup.

Google Play has a different rule and it catches different apps

Play does not ask Apple's question. Its spam policy asks who owns the site: it does not allow apps whose primary purpose is to drive affiliate traffic to a website, or that provide a webview of a website without permission from the website owner or administrator. The example given is an app wrapping someone else's shopping site. If you own the domain, it is not aimed at you.

A second Play policy sits closer to Apple's and is much shorter. Under functionality and user experience, Play does not allow apps that only have limited functionality and content. Broader net, lower bar, less appetite for judgement.

The result is an asymmetry that confuses people. The same build sails onto Play, gets bounced from the App Store, and the team decides the iOS reviewer was arbitrary. Play is asking whose website this is. Apple is asking whether this needed to be an app. Design for the stricter one and you clear both.

Google Play Spam policy, Webviews and Affiliate Spam

What carries over from the website and what does not

A web to mobile app project reuses less than people expect. If your site talks to a backend, the app talks to the same backend. That API is the asset. The HTML, the CSS and the page routing are not coming with you, and a converter that keeps them keeps the wrong half.

Layout is where the honest work starts. Hover has no equivalent on a touch screen. Nor does a wide table, a four column form, or a nav bar with eleven items. Rather than port the site map, pick the three things people open their phone to do and lay those out first as a mobile app wireframe. Most converted apps fail here before a reviewer ever sees them: every page renders, and nothing is usable one handed at a bus stop.

Two quieter breakages. A browser cookie is not how an app stays signed in, so you need tokens in the platform keychain, a refresh path and a way to sign out a lost device. And money changes shape: digital goods and services sold inside an app fall under Apple's guideline 3.1 payment rules, and putting your existing web checkout inside a web view does not move it outside them.