4 min read
Turning your web app into an App Store app: why wrappers get rejected and what to do instead
Built your product in Lovable, Bolt or as a web app and want it on iOS and Android? Here is what Apple and Google check, the three common rejection reasons, and the realistic paths to a store-ready app.
"How do I turn my Lovable project into an app?" is one of the most common questions on r/lovable right now. The web app works, users like it, and the next step feels obvious: put it in the App Store and Google Play.
The quickest route is to wrap the website in a thin app shell and submit it. It is also the route most likely to get rejected by Apple. Here is why, and the options that actually get through review.
Why Apple rejects most website wrappers#
Apple's App Store Review Guidelines include a rule on minimum functionality, guideline 4.2. In plain terms: an app should offer something beyond a repackaged website. If reviewers open your app and it behaves exactly like your site in Safari, with a browser-style experience and no use of the device, it is likely to be rejected under 4.2.
Google Play is generally more relaxed about this, but its policies also discourage apps that are just a website in a frame. Either way, a wrapper that adds nothing gives users little reason to install it.
The other two rejection reasons we see most#
Even when the app is more than a wrapper, two rules catch a lot of first submissions.
Account deletion#
If your app lets people create an account, Apple requires that they can also start deleting that account from inside the app (guideline 5.1.1). A link to "email us to delete your account" is not enough. Many web apps built quickly do not have this at all, because nobody asked for it.
Reporting and blocking for user content#
If users can post anything other people see, such as comments, messages, profiles, photos or reviews, Apple expects ways to filter objectionable content, report it and block abusive users, plus a way to contact you (guideline 1.2). Community and marketplace apps are often rejected for missing this.
Your realistic options#
There is no single right answer. It depends on how much your users need the phone itself.
Option 1: Make the web app installable first#
A progressive web app (PWA) can be added to the home screen, opens full-screen and can work partly offline. It does not go through app review at all. For many early products this is enough to learn whether people want a mobile experience before you spend on one.
Option 2: A hybrid shell with real native features#
Tools like Capacitor let you keep most of your web code and add native features: push notifications, camera, biometric login, offline storage, share sheets, home-screen widgets. If the app genuinely uses the device and feels like an app, it has a far better chance with Apple than a plain wrapper. This is often the fastest path for a working web product.
Option 3: A proper cross-platform app#
React Native (usually with Expo) or Flutter give you a real native app for iOS and Android from one codebase. The interface is rebuilt for mobile, but your backend, database and business logic stay the same. This is the right choice when the mobile app is your main product, or when performance, gestures and offline use really matter.
| PWA | Hybrid with native features | Cross-platform native | |
|---|---|---|---|
| In the App Store | No | Yes | Yes |
| Reuses web code | Almost all | Most | Backend and logic only |
| Feels native | Partly | Mostly | Yes |
| Risk of 4.2 rejection | Not applicable | Low if it uses the device well | Low |
| Typical time | Days | A few weeks | Several weeks or more |
What to sort out before any of these#
Whichever route you choose, the same groundwork applies:
- Developer accounts in your name. An Apple Developer Program membership and a Google Play developer account, owned by your company, not by a freelancer.
- A backend that is safe to expose. A mobile app makes your API easier to inspect, so database rules and secret keys need to be right. Our pre-launch checklist for AI-built apps covers this.
- Payments that follow store rules. Selling digital content or subscriptions inside an iOS app generally has to go through Apple's in-app purchase system, with some exceptions that vary by country. Physical goods and real-world services can use normal payment providers. Check this before you design your pricing.
- Store listing basics. Screenshots for each device size, a privacy policy, data-use answers ("privacy nutrition labels" on iOS and the Data safety form on Google Play), and a test account for the reviewer if your app needs a login.
The short version#
A website in an app frame is the fastest thing to build and the most likely thing Apple rejects. If you only need a home-screen icon, ship a PWA. If you want to be in the stores, add real native features with a hybrid shell, or build a cross-platform app on top of the backend you already have. Either way, add account deletion, reporting and blocking before you submit.
If you are not sure which path fits your product, book a free strategy call. We will look at what you have and tell you the quickest route to the stores.
