Mobile apps
Getting a wrapped app through store review
Store reviewers aren't looking for a web view. They are looking for an app that does something a website link wouldn't. Make the app worth installing, and the technology stops being the main question.
By itmarkerz Technologies. Updated 30 October 2026.
What the rules say
We have shipped a wrapped app to both stores: the owner app for a wearable QR platform. That experience doesn’t make us an authority on what reviewers will do next time, so here is the published wording. All of it was read on 30 October 2026.
| Rule | What it says | What it means for you |
|---|---|---|
| Apple 4.2 | “Your app should include features, content, and UI that elevate it beyond a repackaged website.” | A copy of your site, in a frame, is the case this describes |
| Apple 4.2.2 | Apart from catalogues, apps “shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” | A brochure site is the highest risk |
| Apple 4.2.6 | Apps from a commercialised template or app generation service are rejected, unless submitted directly by the provider of the app’s content | Submit under the content owner’s own account, and avoid shipping many near-identical apps |
| Apple 3.1.1 | To unlock features or functionality in the app, “you must use in-app purchase.” | A web checkout for digital features inside your wrapper can be a separate problem |
| Google Play spam policy | Lists “apps whose primary purpose is to provide a webview of a website without permission” as a violation | Wrap websites you own, or have permission for, and be able to show that |
What makes an app more than its website
Look at this from a reviewer’s side. They install your app, possibly with a demo login, and spend a short time trying to see what it does. Things that help:
- A purpose people return for. Our wearable app’s owners log in, upload media, write a message, preview and publish. That is a task, not a site to browse.
- Native navigation. A tab bar, correct back behaviour and no browser-style chrome. Remove site headers, footers and “download our app” banners from the wrapped view.
- Device features that matter. Camera upload, push notifications for something the user chose, sharing and biometrics, where each one has a use.
- A designed offline state. A friendly screen and any cached content. Never show a browser error page.
- Native-feeling details. Safe areas around the notch, the right keyboard for each field, and fast tap response.
The checklist before you submit
| Check | Why |
|---|---|
| Demo account with sample data in the review notes | Reviewers need to get past your login, and an empty account shows them nothing |
| A short note explaining what the app does and what it adds | It frames the review and answers the likely question |
| Every link inside the app stays in the app, or opens clearly | A link that drops people into a browser looks like a website |
| No payment flow for digital features that breaks 3.1.1 | Read the payment rules for your category and region |
| Privacy policy link, and matching store privacy details | Your declarations should describe what the app really collects |
| Account deletion available in the app, if accounts can be created | Apple’s guidelines require this; check the current wording |
| Tested on real, older devices and small screens | A broken layout counts against you, whatever the technology |
| Time in the plan for at least one rejection | It protects your launch date |
Be careful about remote changes
The appeal of a wrapped app is that much of it updates when you deploy your website. Reviewers approved what they saw, though, and store rules limit changing an app’s purpose afterwards. Fixes and content are ordinary. Turning on a whole new feature set after review is the sort of thing to avoid. If reviewers keep questioning your app, or you need much more than a web view can do, it may be time to compare wrapped web apps and React Native again.
The wrapped app we refer to here
Backend, scan pages and iOS/Android apps behind a t-shirt with a unique QR code its owner controls — text, photo or video, changeable any time, scannable with no app. Laravel. Delivered to both app stores in three months for a Belgian fashion brand.
- Sector
- Fashion & retail
- Region
- Belgium
- Stack
- Laravel, iOS, Android
- Engagement
- Product build, three months
Questions
Does Apple ban apps built with a web view?
The guideline doesn't say that. It asks for features, content and UI that elevate an app beyond a repackaged website. So reviewers judge what the app does for the user, and the technology itself isn't the test. A review outcome can't be guaranteed either way.
Can you guarantee our app will pass?
No, and be careful of anyone who says so. Decisions rest with Apple and Google. What we can do is build to their published guidelines, and fix what a reviewer raises.
What should we do if we are rejected?
Read which guideline is cited and reply through App Store Connect, or the Play Console, with specifics. Add what's missing rather than argue the general point. Leave room in your launch plan for at least one round of this.
More on mobile apps
- Wrapped web app or React Native? We've shipped bothA decision table from a three-month wrapped app and a year-long React Native SaaS.
- One Laravel API, web and mobile: how we structure itOne API for a Next.js site and React Native apps, without two sets of rules.
- Expo or bare React Native?What React Native's own docs recommend, and when you'd still manage native folders.
- Upgrading an older React Native appThe support window, the New Architecture and an order of work.
Planning to wrap your web app?
Send us the web address, and tell us what the app should add. We will tell you where we would expect questions from a reviewer.
We reply within one business day (IST).