How to turn your website into an app — three paths that actually work

You vibe-coded a web app. It works, it's live, people are using it in the browser. Then someone asks the question every indie maker eventually hears: "Is there an app?"

There are three honest answers, and they're not equally good for your situation. You can make your site installable as a Progressive Web App, you can wrap it in a native shell and ship it to the app stores, or you can rebuild the front end natively. Most vibe coders reach for the wrong one — usually the most expensive one — because they think "real app" means "rewrite everything." It almost never does.

Here's how the three paths actually compare, when each one wins, and the one App Store rule that quietly sinks a lot of first attempts.

First, get clear on what "an app" means to you

Before you pick a path, figure out which of these you actually need, because they pull in different directions:

• An icon on the home screen that opens without a browser bar.
• Offline support so the app opens and does something useful with no signal.
• App store presence — being findable in the App Store or Google Play.
• Native device features — push notifications, camera, biometrics, haptics.

If all you want is the first two, you do not need the app stores at all, and you definitely do not need a rewrite. If you need store presence and a couple of native features, you want a wrapper. Only if your app lives or dies on deep native performance — heavy graphics, constant background work, tight hardware integration — do you need to think about rebuilding.

Write down which of those four boxes you actually need to tick. Most vibe-coded tools need one or two. Skipping this step is how people spend a weekend wrapping an app they could have shipped as a PWA in an afternoon.

Path 1: Make it a Progressive Web App (the afternoon option)

A Progressive Web App is your existing website plus two small additions that let browsers install it to the home screen. No new framework, no app store, no rewrite. For a lot of vibe-coded tools this is the entire job.

You need two things:

A web app manifest — a small JSON file that tells the browser your app's name, icons, theme color, and how it should launch (usually display: standalone, which hides the browser chrome). A service worker — a script that caches your core files so the app opens instantly and can work offline. Modern frameworks generate both for you; if you built on Next.js, Vite, or similar, there's a PWA plugin that wires this up in a few lines.

Once those exist, browsers offer an "Add to Home Screen" prompt. The result looks and feels like an app: its own icon, full screen, no address bar. On Android it's nearly indistinguishable from a store-installed app. On iOS it works too, with a few more limitations around notifications and background behavior, though those keep narrowing with each Safari release.

The honest trade-off: a PWA is not in the app stores, so people can't find it by searching the App Store, and you don't get that distribution. But you ship today, you keep one codebase, and you skip Apple's review entirely. If discovery isn't your bottleneck yet, start here. You can always wrap it later — a clean PWA is exactly what the next path builds on.

For more on what makes a web app feel finished before you package it, see our companion guide, “From prototype to production.”

Path 2: Wrap it for the app stores (the few-hours option)

When you genuinely need store presence and native features but don't want to rebuild your front end, you wrap it. A wrapper gives you a real native iOS and Android shell that loads your web app and bridges to native APIs — push notifications, biometrics, camera, deep links — without you rewriting the UI.

The modern standard here is Capacitor, from the Ionic team (it's the successor to the older Cordova). The pitch is exactly what a vibe coder wants: keep almost all your existing web code, get a native project you can submit to both stores. If your app already has clean routes and component logic, wrapping it can genuinely take a few hours rather than a few weeks. Tauri is a lighter-weight alternative worth knowing about, especially if you're also shipping a desktop build. And PWABuilder can take an existing PWA and generate store-ready packages for you, which is the fastest on-ramp if you've already done Path 1.

The rough workflow with Capacitor looks like: install it into your existing project, point it at your built web assets, add the iOS and Android platforms, open the generated native project, and build. Add native plugins only for the features you actually use. Then you're into the normal store submission process — developer accounts, icons, screenshots, review.

Here is the rule that sinks first attempts, so read this twice. Apple can reject your app under App Store Review Guideline 4.2 if it does nothing more than load a website and add no native value. A bare wrapper around your site is exactly what reviewers are trained to catch. The fix is to add genuine native value: push notifications, biometric login, offline caching, native sharing, or in-app purchases. A wrapper that uses two or three real native capabilities passes review consistently; one that just displays your URL in a full-screen webview often does not. Plan at least one native feature into your wrap before you submit — don't treat it as an afterthought.

The trade-off for Path 2 is real but manageable: two store accounts (Apple's costs $99/year, Google's is a one-time fee), review cycles that add days to every release, and a bit of native tooling to learn. In exchange you get searchable store presence, push notifications, and an install that your less technical users will trust more than a browser bookmark.

Path 3: Rebuild it natively (the weeks option — usually skip it)

The third path is to rebuild your front end in React Native, Flutter, or fully native code. This is the right call in a narrow set of cases: your app needs heavy graphics or animation, constant background processing, real-time hardware access, or performance that a webview can't deliver. Games, serious media tools, and apps where every millisecond of touch latency matters belong here.

For the overwhelming majority of vibe-coded tools — dashboards, trackers, generators, directories, CRUD apps, content tools — this is overkill. You'd throw away working code, double your maintenance (now you have a web app and a native app to keep in sync), and spend weeks rebuilding screens you already have. Unless you can name the specific native capability that forces your hand, don't start here. Ship a wrapper, learn what users actually need, and only go native for the parts that genuinely demand it.

How to choose, in one paragraph

If you need an installable icon and offline support and nothing more, ship a PWA this afternoon. If you need app store presence plus a couple of native features, wrap it with Capacitor — and bake in at least one real native feature so you clear Apple's 4.2 review. If, and only if, your app depends on heavy native performance you can't get from a webview, rebuild natively. When you're genuinely unsure between PWA and wrapper, ship the PWA first: it's the foundation the wrapper builds on anyway, so the work isn't wasted.

A few things that trip people up

A handful of gotchas catch almost everyone the first time:

• Test on a real device, not just the simulator. Install prompts, notifications, and safe-area insets behave differently on actual hardware. The simulator will lie to you about all three.
• Get your icons and splash screens right early. Stores reject submissions over missing icon sizes, and nothing makes a wrapped app feel cheaper than a stretched or off-center icon.
• Handle the offline state on purpose. An app that white-screens with no signal feels broken in a way a website never did, because users expect more from something on their home screen.
• Don't over-wrap. Every native plugin you add is something to maintain and a thing that can break on the next OS update. Add only the features you'll actually use.

For the broader question of when your weekend build is ready to harden at all, testing code you didn't write and reviewing AI-generated diffs are worth a read before you put anything in front of Apple's reviewers.

Where to start

If you've got a working web app, do this in order. Add a manifest and service worker and ship the PWA — confirm it installs and opens offline. Watch how people use it for a couple of weeks. If store presence becomes the real bottleneck, wrap the PWA with Capacitor or PWABuilder, add one genuine native feature, and submit. Skip the native rebuild until something specific forces it.

If you haven't built the web app yet, that's the actual first step — and it's a smaller one than turning it into an app. Browse what other indie makers have shipped on VibeShare to see what "done" looks like, grab a starting point from our templates, and follow the instructions to go from idea to live URL. Then come back to this post when someone asks whether there's an app.

Built something worth installing? Submit your project so other vibe coders can find it — and if you want one-click access to tools like this as you browse the web, grab the extension.

---

Tools mentioned: Capacitor, Tauri, and PWABuilder. We link to them directly; affiliate partnerships for the dev tools we recommend are still being set up.

Sources: Capacitor — Building Progressive Web Apps, Transform Your PWA to a Native App with Capacitor, How to Convert a Web App to Mobile App (No Full Rebuild).