Apple Guideline 4.2: Will Apple Reject a Website App? How to Pass Review

Apple can reject a website-based app, and "minimum functionality" is the most common reason. Guideline 4.2 is the rule behind it. A website app is not automatically refused, but an app that adds nothing beyond a website in a frame is at real risk.

This guide explains what the guideline says, what reviewers tend to look for, and how to prepare a submission. Nobody outside Apple can promise approval, and this article does not. What you can do is remove the avoidable reasons for rejection.

What Guideline 4.2 actually says

The App Review Guidelines state under 4.2, Minimum Functionality:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store.

The words that matter are "repackaged website." The rule does not ban apps built around web content. It bans apps that offer nothing a website does not already offer.

Related guidelines also come up in website-app reviews:

• 4.2.2: Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.
• 4.2.3: The app should work on its own without requiring installation of another app, and it should disclose and prompt for any large download needed on first launch.
• 2.1 (App Completeness): Submissions should be final versions with working URLs, no placeholder content, and demo account details if the app has a login.
• 4.2.6: Apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content.

Always read the current text yourself, since Apple updates the guidelines. The official source is the App Store Review Guidelines.

Will Apple reject a website app?

It depends on what the submitted app does. In practice, reviewers react to a few patterns:

• The app opens a single URL and looks identical to the mobile website, including web-style navigation.
• It shows only a login wall with no browsable content, so the reviewer cannot see what the app does.
• It breaks or shows errors without a connection.
• Its links jump out to the browser constantly.
• It looks like a marketing brochure for a business with no function of its own.

An app that wraps a real service, such as a store, a booking system, a member area, or a content library, and presents it with app-like navigation is in a different position. You can still be rejected, since review is a judgment, but you have something to point to.

Why a service-generated app needs your own account

Guideline 4.2.6 says apps made with an app generation service are rejected unless they are submitted directly by the provider of the app's content. For a website owner, the practical reading is this: publish under your own Apple Developer account, in your own name or your company's, and make sure the app represents your own content.

This is also how SiteTo.App works. Builds are signed with the Apple Developer account you connect, and the build is delivered to TestFlight in your App Store Connect account. You own the listing and you submit it. See the Apple Developer account guide for the setup. Do not hand your content to a vendor who submits the same shell for many clients under its own account.

What makes a website app feel like an app

The goal is not to add features for the sake of it. It is to make mobile use better. Strong, honest additions include:

• Native navigation. A tab bar or menu that matches how people move through your site on a phone, rather than a desktop header squeezed into a small screen.
• Push notifications. Messages users opt into, such as order updates, booking reminders, or new content. In SiteTo.App these are set up through Firebase; see the Firebase guide.
• Deep links. Links from notifications or email that open the right screen in the app.
• A designed launch experience. An icon, a splash screen, and a clear loading and error state.
• Native handoffs. Sharing, file uploads, camera access, or downloads that work properly on the device.

Do not add a gimmick such as a flashlight toggle. It does not address guideline 4.2, and reviewers see through it.

A pre-submission checklist

Work through this before you upload:

1. Test the whole journey on a real iPhone. Install through TestFlight, not only a simulator. Open the app cold, go through sign-in, navigate several levels deep, and use the back gesture.
2. Test with no connection. Turn on airplane mode and open the app. You should see a clear message, not a blank page.
3. Check every external link. Decide on purpose which links stay inside the app and which open the browser.
4. Fix website layout issues. Responsive problems, tiny tap targets, and desktop-only popups are obvious in an app.
5. Remove placeholder content. Guideline 2.1 expects a finished product with working support and privacy URLs.
6. Provide demo credentials. If a login is required, include an account that keeps working throughout review.
7. Make privacy answers accurate. They should describe the whole experience, including web analytics and payment tools loaded in the app.
8. Write honest screenshots and a description. Show the real app, and do not claim features it lacks.
9. Use review notes. Explain what the app does, where the native features are, and any region or account requirements.

You can check your site against many of these with the readiness checklist, and our publishing guide covers the surrounding store steps.

How to write review notes that help

Reviewers see many submissions. A short, specific note helps them find the value fast. Cover:

• What the app is for, in one or two sentences.
• How to sign in, with working demo credentials.
• Where to find the native features, for example "Notifications can be enabled from the account tab."
• Anything unusual, such as a feature that needs a particular region or hardware.

Keep it factual. Avoid arguments about the guidelines in the first submission. Save that for a reply if you are rejected.

If Apple rejects the app

A rejection is a conversation, not a final verdict. Apple explains the guideline it applied in the Resolution Center.

1. Read the message carefully. Note the guideline number and any specific screens or behavior mentioned.
2. Fix the actual issue. If the reason is minimum functionality, improve what the app does instead of rewording the description.
3. Reply precisely. Describe what changed and where the reviewer can see it.
4. Resubmit a new build if needed. A change to the binary requires a new upload.
5. Appeal only with a case. If you believe the rejection is a mistake, use the App Review appeal process and cite the facts.

Because a website-based app loads your site, many fixes happen on the website itself and appear in the app without a new store release. Native configuration changes still need a new build.

Common questions

Does a website app have to work offline?

Not as a rule, but it should fail gracefully. A blank screen with no connection looks unfinished, and that affects how reviewers see the app.

Is a PWA treated differently from any other website?

A PWA in an iOS app is still web content inside a native shell, so the same guideline applies. See how to publish a PWA to the App Store and Google Play.

Can I submit the same app for several brands?

Guideline 4.2.6 restricts apps created from a template or generation service and submitted on behalf of clients. Each business should publish under its own account.

Do I need to pay for a converter to get approved?

No tool decides the outcome. Apple evaluates the submitted app. Paying for a build does not change that, so pricing is separate from approval. See pricing.

Next steps

Start by testing your site as an app. Preview your website in SiteTo.App, try it on your phone, and note what feels like a website instead of an app. Fix those points, then follow the create and publish guide.