By Maciej Pyrc, who maintains Hype Stack.Published .
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
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
The same Hono routes the website calls, over HTTPS. Auth, data, billing, all of it. Nothing is duplicated for mobile.
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.
Expo with expo-router for navigation and NativeWind for styling, so the Tailwind classes the website uses mean the same thing on the phone.
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
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-appMove 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.
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.
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.
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, and the narrower question of whether the site needs an app at all in How to Create an App for a Website. The starting question is in How Do I Make an App.