How to Turn Your Website Into an App (Without Rebuilding It)

You have a working website. People use it on their phones. The obvious next step is an icon on the home screen and a listing in the App Store — and that is where most founders discover that "turn my website into an app" hides four very different projects with very different price tags.

Route 1: Add to Home Screen

Free, instant, and almost worthless commercially. Safari can pin any site to the home screen, and it will open full screen without browser chrome. What you do not get: a listing anyone can find by searching the App Store, Apple's payment sheet, reliable push notifications, or persistent storage — iOS clears data for sites the user has not opened in a while, which is why people quietly get logged out. It is a fine internal tool. It is not a product launch.

Route 2: A progressive web app

A PWA adds a manifest, a service worker, offline caching and a nicer install prompt. On Android it is genuinely capable. On iOS it remains a second-class citizen: no App Store presence, no in-app purchases, limited background behaviour, and push that only works after the user has manually installed it to the home screen. If your audience is on iPhone and you intend to charge a subscription, a PWA leaves most of the money on the table.

Route 3: Rebuild natively

Swift and SwiftUI, or React Native, or Flutter. You get everything, and you pay for it: a second codebase to keep in step with your website, a Mac, Xcode, certificates, and a first submission that typically takes six to twelve weeks including the review cycles nobody plans for. This is the right call when the product is genuinely device-first — camera, background location, heavy offline use. It is the wrong call when your product is a web app that people also want on their phone.

Route 4: A native shell around your existing site

Your website loads inside a native container, and the capabilities Apple cares about are implemented natively around it: in-app purchases through StoreKit, push through APNs, Face ID, haptics, the share sheet, offline handling. You keep one codebase and one deploy. Content changes appear in the app immediately, because it is your live site.

The catch, and how to get past it

Apple rejects thin wrappers under guideline 4.2, Minimum Functionality: an app that is "just a website" with no native value gets bounced. The rejection is not for using a web view — plenty of top-grossing apps do — it is for adding nothing. Apps pass when they behave like apps: native purchase, real push, biometric sign-in, sensible offline state, no visible browser controls, no dead links out to a mobile browser, and a listing that describes a product rather than a site.

Which route to pick

• Internal tool, a handful of users: home screen shortcut. Stop there.
• Free content, Android-heavy audience: PWA.
• Device-first product: rebuild natively and budget properly.
• Web product with paying users on iPhone: native shell — fastest route to a listing and to Apple billing.

Wanilla does the fourth route as a managed service: we build the shell, wire up purchases and push, produce the store assets, submit on your developer account and answer the reviewer. Book a free launch review and we will tell you which of the four routes your product actually needs — including when the answer is "not yet".