Rejection decoder › Guideline 4.2
Guideline 4.2 rejection: Minimum Functionality
Guideline 4.2 is the rejection most often associated with wrapped web apps. Apple's view, paraphrased: the app is a website in a container and offers little that a browser does not. The fix is to make it useful as an iPhone app, then say exactly what changed.
Apple decides. This page is our own reading of the App Review Guidelines as of September 2026, not Apple's wording, and following it does not guarantee approval. The current text at developer.apple.com is the authority.
What Apple's message says
The typical 4.2 message says the app provides a limited user experience because it is not sufficiently different from a mobile browsing experience. Related sub-guidelines narrow it down:
- 4.2.2: the app is mainly marketing material, a list of links, or content collected from elsewhere.
- 4.2.3: the app does not work on its own; a new user must sign up on the website first, or sees nothing without content created elsewhere.
- 4.2.6: the app looks like it came from a template or app-generation service and is published by someone other than the business it represents.
Being built with an AI tool is not the problem in itself. Feeling like a website, being generic, or being published on someone else's behalf is.
Why AI-built apps hit it
A Lovable, Bolt, v0 or Replit app is a web app. Wrapping it with Capacitor gets it onto an iPhone, but by default it still behaves like a browser tab:
- The site's own header, hamburger menu and footer, with links that open other web pages inside the app.
- A blank white screen when there is no connection.
- Nothing uses the phone: no notifications, camera, share sheet, haptics or data kept on the device.
- Cookie banners, "download our app" banners and web-only login flows left in.
How to fix it, step by step
- Pick native features that fit the app's job. Two or three real ones beat a long list. Common options: push notifications for events the user cares about, camera or photo input, the share sheet for exporting, an offline screen with cached content, biometric unlock, home screen quick actions.
- Use native navigation. A tab bar for the main areas, and no web header or footer.
- Handle offline. Show a proper offline state with whatever can be shown from cache, not a blank page.
- Clean out web-only parts: cookie banners, app download banners, links to the marketing site, and external links that open inside the app.
- Make it work on its own (4.2.3): let users sign up in the app, and give the reviewer a demo account with realistic data.
- For 4.2.6, submit from the developer account of the business the app is for, and remove template leftovers such as default names and sample images.
- Test on iPhone and iPad, upload a new build, and update screenshots so they show the native features.
If the honest answer is that the app is a brochure, a website may be the better home for it. That is a legitimate outcome.
What to reply in the Resolution Center
Fill in the brackets and delete anything you did not do. List features specifically, with where to find them. A vague "we improved the app" usually gets the same result.
Hello, Thank you for the feedback. Build [version] adds features specific to iOS: - [Feature 1, e.g. "Push notifications when a booking is confirmed"] - [Feature 2, e.g. "Offline access to saved items"] - [Feature 3, e.g. "Export reports through the share sheet"] Navigation now uses a native tab bar, and [other change]. To see these, [short path, e.g. "sign in with the demo account and open Saved"]. Best regards, [Your name]
Related guidelines
- Guideline 4.3: Spam if Apple also thinks the app is a copy of others.
- Guideline 2.1: App completeness and Information Needed if the offline blank screen was reported as a bug.
- Guideline 3.1.1: In-app purchase if the wrapped site still shows web pricing.
- Guideline 5.1.2 / ITMS-91053: Privacy manifest for the privacy manifest that wrapped apps need.
Questions
Can a Capacitor or web-wrapped app pass Guideline 4.2?
Many do. Apple judges what the app offers, not the technology. Apps that add native features suited to their purpose, native navigation and a proper offline state have a better chance. Apple makes the final decision.
Which native features does Apple want to see for 4.2?
There is no fixed list. Pick features that fit what the app does, such as push notifications, camera input, share sheet, offline content or biometric unlock, and describe each one in your reply.
Should I appeal a 4.2 rejection?
Usually improve the app first and reply with the specific changes. An appeal to the App Review Board makes sense when you believe the reviewer misread what the app does, not when the app is still mostly a website.
Stuck on this rejection?
Paste the full message into the free rejection decoder to see every cited guideline explained, with a reply draft. It runs in your browser and nothing is uploaded.
Or order a rejection fix, $99: we read the full message, find the cause, fix it in your project, upload a new build and draft the reply for your approval. Target turnaround 72 hours from access. Apple still makes the final decision, and its review time is separate.