How to Create an App From a Website: 3 Routes Compared

There are three ways to create an app from a website: turn the site into a progressive web app (PWA), wrap it in a native shell so it can go in the app stores, or rebuild it as a mobile app that shares your website's backend. A PWA is the cheapest and needs no store. A wrapper gets you a store listing. A rebuild gets you the best app, at the highest cost.

The route usually comes down to one question: do you need to be in the app stores? If not, build a PWA. If you do, read Apple's rules before you write any code, because guideline 4.2 is where a lot of website-to-app projects stall. It says your app should go beyond "a repackaged website."

Quick comparison

One thing to settle first: "app website" can mean a few different things. If you're not sure whether you have a marketing site or a real web application, start with our app website vs web app explainer. It matters here, because a brochure site has little reason to become an app. A web app with logins, saved data, and repeat use is the kind of site that gains from this.

Route 1: Turn your website into a PWA

A PWA is still your website. Google's web.dev guide defines PWAs as web apps built and enhanced with modern APIs, and they serve many kinds of devices from a single codebase.

Once someone installs it, the app gets an icon in their launcher or on their home screen, shows up in device search, and opens in its own window. You didn't build a package, and nobody visited a store.

What your site needs

MDN lists the installability requirements, and the list for Chromium-based browsers such as Chrome and Edge is short:

• A web app manifest linked from every page
• HTTPS on the live site
• Icons at 192px and 512px
• name or short_name, start_url, and display set in the manifest, with prefer_related_applications left out or set to false

A minimal manifest looks like this:

{
  "name": "Acme Orders",
  "short_name": "Acme",
  "start_url": "/",
  "display": "standalone",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Save it as manifest.json and link it with a link rel="manifest" tag in the page head. Then add a service worker if you want offline support. MDN notes that a service worker isn't required for installation, but many PWAs use one to work offline.

How it behaves on Android and iPhone

Installation differs by platform, and this is the part most guides skip.

On Android browsers that support it, the browser can show an install prompt, and you can trigger your own install button with the beforeinstallprompt event. Not every browser supports that event. The result varies too: MDN says Chrome with Google Mobile Services and Samsung Internet on Samsung devices install a full app, while other Android browsers add a browser-badged shortcut that opens the site in the browser.

On iPhone, your site can't rely on that prompt. People install it themselves. Apple's guide to turning a website into an app walks through the steps in Safari: tap Share, scroll down to Add to Home Screen, turn on Open as Web App, then tap Add. Depending on the tab layout, Share may sit behind another button first. MDN says Chrome, Edge, Firefox, and Orion can also install from the Share menu since iOS 16.4. Show users those steps inside your site.

Notifications have a similar catch. WebKit added Web Push for Home Screen web apps in iOS and iPadOS 16.4. The app has to be on the Home Screen first, and the permission request has to come from a direct user action, such as tapping a Subscribe button.

Where a PWA falls short

• No store discovery. People searching the App Store or Google Play won't find you.
• Weaker install flow. A home screen install takes more explaining than a store download, especially on iPhone.
• Uneven device access. Google's own PWA capabilities guide admits there are still gaps on the web, and support varies by browser and platform.

If none of those block you, stop here. A PWA has no review process and no store fees, and you ship updates by deploying your website.

Route 2: Wrap your website in a native app

A wrapper is a thin native app that displays your web content. It gives you a real store listing while your website keeps doing most of the work. There are three common tools, and they suit different jobs.

Android: Trusted Web Activity with Bubblewrap

For Android, Google documents a Trusted Web Activity (TWA). It runs your PWA full screen in the user's own browser. That keeps your app small.

Bubblewrap is the command-line tool for building one. It needs Node.js 18 or newer, and it offers to install the JDK and Android command-line tools on first run. Chrome's TWA quick start comes down to installing it and running two commands:

npm i -g @bubblewrap/cli
bubblewrap init --manifest=https://your-site.com/manifest.json
bubblewrap build

That produces a signed APK for testing on a device and a signed App Bundle to upload to the Play Store, which requires App Bundles for new apps. You also need to prove you own the site with Digital Asset Links, which means publishing a small verification file on your domain. Google Play re-signs your app after you upload it, so you'll need to update that file with Play's signing details.

Two limits are worth knowing. Android's docs say web content must be accessible and useful in the browser first, so get the site working well there before you start. And the host app has no direct access to web state like cookies and localStorage, so a TWA is a poor fit if you plan to mix in lots of native code.

PWABuilder: the no-command-line option

PWABuilder is an open source tool that packages PWAs for stores, including Microsoft, Google Play, and the iOS App Store. You enter your URL, it scores your PWA, and it generates a package for each platform. Your site needs a public URL, a complete manifest, and HTTPS.

The Android package is built on Bubblewrap, so you get the same TWA as above. On iOS, the picture is different. PWABuilder's App Store docs describe a native Swift app containing a WebView, mark iOS packaging as experimental, and say acceptance depends on your PWA's UI/UX and its use of native capabilities. You also need a Mac with Xcode.

Google's article on PWAs in app stores covers the account side: you need a developer account for each store. Google Play charges a one-time registration fee, and Apple charges a yearly one. Microsoft says its current onboarding has no registration fees.

Capacitor: for web teams who want native features

Capacitor describes itself as a cross-platform native runtime for building mobile apps. Your web code runs inside the app, and plugins give it access to native features, such as native push notifications.

The common misunderstanding: Capacitor isn't a "paste your URL, get an app" tool. Its setup docs ask for three things: a package.json, a separate directory of built web assets such as dist or www, and an index.html with a head tag at the root of that directory.

There's a server.url setting that loads an external URL, and tutorials often use it to point the app at a live site. Capacitor's config docs say it's intended for live-reload servers and is "not intended for use in production."

So Capacitor suits a modern JavaScript front end, such as a React or Vue single-page app, that can build to static files. A server-rendered site, like a typical WordPress install, won't drop in without real changes to how it's built.

Google Play's webview rule

Google's webview rule draws a clear line. Its spam policy bans apps whose primary purpose is to provide a webview of a website without permission from the website owner or administrator. Wrapping your own site is fine under that rule. Wrapping someone else's isn't. Your app still has to meet Google's separate functionality policy, which doesn't allow apps with only limited functionality and content.

Apple guideline 4.2: the rule that decides the wrapper route

Apple's App Review Guidelines are the main risk in this whole process. Section 4.2, Minimum Functionality, says your app "should include features, content, and UI that elevate it beyond a repackaged website." It adds that an app that isn't "particularly useful, unique, or 'app-like'" doesn't belong on the App Store.

Two sub-rules matter just as much:

• 4.2.2 says apps, other than catalogs, shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.
• 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they're submitted directly by the provider of the app's content.

That second rule catches a lot of website-to-app converter services. If one of them submits the app on your behalf, under its own account, you have a problem. Publish under your own developer account.

Apple doesn't publish a checklist for "app-like," so nobody can promise you a pass. These additions give a wrapper a stronger case:

• Native navigation, such as a real tab bar rather than your website's hamburger menu
• Push notifications tied to something useful, such as an order update
• Offline behavior, so opening the app with no signal doesn't show a blank screen
• Device features your site can't offer as well, such as camera scanning or biometric login
• Mobile-first screens that follow Apple's Human Interface Guidelines

Payments can catch you out too. If your site sells digital goods or subscriptions, section 3.1 of the guidelines may require in-app purchase, depending on the product and storefront. Read that section before you plan your revenue around a wrapper.

Route 3: Rebuild it as a mobile app

Rebuilding means writing a new mobile front end while your website's backend keeps running. Your database, business logic, and user accounts stay. The screens are new.

Rebuild when:

• Mobile is where your users spend most of their time
• You need smooth gestures, heavy media, or deep device integration
• A wrapper has been rejected, or reviews keep complaining that the app feels like a website

The hidden job here is usually the API. A mobile app needs clean endpoints for login, data, and payments. If your website renders everything on the server with no API behind it, building that layer may take longer than the mobile screens.

You don't always need a full development team. If you're rebuilding a simple product, an AI builder can get you a first version of a mobile app fast. Our AI app builder comparison covers what those tools generate. Guideline 4.2 applies to whatever you submit, however it was built.

How to pick your route

Work down these questions and stop at the first yes.

1. Is your site mainly marketing or content? Don't build an app. Make the site fast on mobile instead.
2. Do your users just need quick repeat access? Build a PWA.
3. Do you have a PWA and need a Google Play listing? Add a TWA with Bubblewrap or PWABuilder.
4. Do you need the App Store and have a modern web front end? Use Capacitor, and add real native value before you submit.
5. Is mobile central to the product, or has a wrapper failed review? Rebuild.

These routes stack. Ship a PWA first, because that work carries straight into a TWA, and see how many people use it before you pay for anything bigger.

FAQ

Can I turn my website into an app for free?

The PWA route has no store fees, and the main tools here, including Bubblewrap and PWABuilder, are open source. Publishing can still cost money, because each store requires a developer account. Google Play charges once and Apple charges yearly, while Microsoft says its current onboarding has no registration fees.

How do I convert a website to an app without coding?

PWABuilder is the closest option, but your site needs a manifest and HTTPS first. Many hosted converter services exist too. For the App Store, check Apple's guideline 4.2.6 before you use one, and submit under your own developer account.

Will Apple reject my web app wrapper?

It may. Guideline 4.2 says an app should go beyond a repackaged website, so a plain wrapper around a mobile site is at real risk. Native navigation, useful push notifications, offline behavior, and device features improve your chances, but nothing guarantees approval.

What's the difference between a PWA and a WebView app?

A PWA is your website, installed from the browser. A WebView app is a native app, usually distributed through a store, that shows web content inside it. On Android, a Trusted Web Activity is a third option: a store app that opens your PWA in the user's own browser.

Can a PWA be listed in the App Store?

Not directly. You have to package it first. PWABuilder can generate an iOS package, but it wraps your PWA in a native app with a WebView, so it goes through normal App Review.

Can I build a mobile app from any website?

Technically you can wrap almost any site, but only your own, or one where you have the owner's permission. Google Play's policy says so directly. A site also needs enough function to be worth installing, or it won't pass Apple's review and few people will keep it.

Do I have to update the app every time my website changes?

With a PWA or a TWA, most changes go live when you deploy your website, because the content comes from the web. With Capacitor, the web assets are bundled in the app, so changes normally ship as a new store release. A rebuild always needs its own releases.

Key points

• Three routes create an app from a website: PWA, wrapper, or rebuild
• A PWA needs a manifest, HTTPS, and icons, and it's the cheapest place to start
• On Android, a Trusted Web Activity built with Bubblewrap or PWABuilder puts your PWA in Google Play
• On iOS, every wrapper has to clear guideline 4.2, which rejects "a repackaged website"
• Capacitor bundles your built web assets, and its server.url setting isn't meant for production
• Rebuild when mobile is central to the product, and budget for the API work

Maybe what you really want is a working AI tool rather than your own mobile app. Taku doesn't turn websites into mobile apps. Taku is an AI-native desktop workspace where you can mirror an AI app someone else already built, remix it, and keep it. Taku is in Beta, and the Mac app is available now.