Source: https://www.hype-stack.dev/stacks/how-to-create-mobile-app-from-website

# How to Create a Mobile App From a Website: Three Routes

> Most people asking this do not need an app built from scratch. They need their website to be installable, or their web
> app to have a real mobile client that shares its backend. Those are three different jobs with three different prices.

The question how to create mobile app from website hides three questions. The first is "can my site be on a phone's home
screen": yes, in an afternoon, and no store is involved. The second is "can my site be in the app stores": yes, with a
wrapper, and the stores will have opinions. The third is "can my web app have a proper mobile app": yes, and the
sensible version shares the backend with the website instead of rebuilding it. Which one you mean decides everything
below, so start there.

## The three routes

|  | Installable site (PWA) | Wrapped website | A real app, shared backend |
| --- | --- | --- | --- |
| What you build | A manifest and a service worker on the site you already have. | A native shell that shows your site in a web view, from Capacitor or a converter service. | A separate mobile app that talks to the same API as the website. |
| Where it lives | Added from the browser to the home screen. | App Store and Google Play, after review. | App Store and Google Play, after review. |
| What it feels like | A website with an icon. Offline support if you add it. | A website inside an app. Navigation and gestures stay web-shaped. | An app. Native navigation, gestures, push, the camera. |
| What it costs you | A day. No accounts, no fees. | Developer accounts for both stores, a converter fee or Capacitor setup, and a review cycle. | The same store accounts, plus the screens, which are the real cost. |
| When it is the right call | Content sites, dashboards, anything people visit in a browser anyway. | The store listing is the point and the site already behaves like an app. | The app is the product and the phone is where people use it. |

A store reviewer's view is worth knowing before you choose the middle column. A wrapper that is only a website in a box
is the kind of submission Apple's guidelines single out, so the wrapped route works best when the site already does
app-shaped things and the wrapper adds something native, such as push notifications or the camera.

## Route one: make the site installable

A progressive web app is a website with two files added: a manifest that names the app and its icon, and a service
worker that lets the browser cache it. On Android the browser offers an install prompt; on iOS the person adds it to the
home screen from the share sheet. No store, no review, no second codebase. If your "app" is a site people check rather
than a tool they live in, stop here and spend the saved month on the site.

## Route two: wrap the site for the stores

Capacitor puts a website into a native shell and gives it access to native features through plugins. The converter
services on the first page of results do the same job as a product: upload a URL, get store-ready builds. Either way you
now own two developer accounts, a review process, and an app whose every screen is still a web page. Reasonable for a
business that needs a store listing for credibility or discovery. Unreasonable as the foundation for a product that will
grow a mobile-specific feature set, because every such feature is a plugin and a workaround.

## Route three: a real app that shares the backend

This is the route for a web app that is becoming a product: a SaaS, a tool, anything with accounts. The mistake people
make here is rebuilding the backend for mobile. The website already has an API, a database and auth. The mobile app
should be another client of exactly those, so one bug fix lands on both and one login works on both.

**What a shared-backend app is made of**

- **One API** The same Hono routes the website calls, over HTTPS. Auth, data, billing, all of it. Nothing is duplicated for mobile.
- **One typed SDK** The mobile app imports the same client the website uses, so a route change fails the build on both instead of breaking one at runtime.
- **Native screens** Expo with expo-router for navigation and NativeWind for styling, so the Tailwind classes the website uses mean the same thing on the phone.
- **A build pipeline** EAS builds the store binaries; a development build or Expo Go runs it on your own phone while you work.

_The screens are the only layer you write twice. Everything under them is shared._

This is the part we make. Hype Stack is an MIT template with a web app, an admin app and an Expo mobile app around one
Hono backend on Postgres. The mobile app lives in `apps/mobile`, uses expo-router and NativeWind, and imports the same
typed HyperFetch SDK as the web app, so a route added for the website is available on the phone with its types the
moment it exists. `pnpm dev` starts Metro alongside the API and the web app, and the docs cover running it on a
simulator or a physical device, including the one thing that trips everyone: a phone cannot reach `localhost`, so the
mobile env takes your machine's address.

**From a website to a mobile app on this template**

1. **Scaffold the stack** — One command gives you web, admin, mobile and the API as one repository, with auth and the typed SDK already shared. (npx @hype-stack/cli create my-app)
2. **Move the website's data behind the API** — If the site had its own backend, its tables become Prisma models and its logic becomes routes. The website and the app now read the same thing.
3. **Write the mobile screens** — The screens are the work. Start with the three people use daily; a coding agent writes them fast against the SDK because the types tell it what exists.
4. **Run it on your phone** — A development build or Expo Go from sign.expo.dev, pointed at your machine's address. Expo Go from the stores stopped at an older SDK, so build your own.
5. **Ship to the stores** — EAS produces the binaries. Store accounts, screenshots and review are the same for every route and are yours to handle.

## What you write yourself, and what is not here

The screens are yours, every one of them, and so is anything native: push notification setup with the providers, camera
and file access, deep links into specific screens. The template gives those a place to live and a typed API to talk to;
it does not pre-build a mobile feature set beyond auth, navigation and the shared data layer, and the feature packs are
web and admin first, with mobile slices where they make sense rather than everywhere.

Two things it does not do at all. It will not wrap an existing website, so if route two is what you want, Capacitor is
the tool and we are not. And it does not remove the store work: accounts, review, the EAS build minutes, and the pace at
which Apple and Google change their rules are the same for everyone.

## Which route, in one sentence each

If people visit your site, make it installable and stop. If the store listing is the point and the site already behaves
like an app, wrap it and accept the two-account tax. If the app is the product, build a real mobile client on the
backend you already have, and never build the backend twice.



The web side of the same decision is in [How to Build a Web App](/stacks/how-to-build-a-web-app), and the narrower
question of whether the site needs an app at all in
[How to Create an App for a Website](/stacks/how-to-create-app-for-website). The starting question is in
[How Do I Make an App](/stacks/how-do-i-make-an-app).