One app, four ways to reach a phone
You already have an app or game running on the web. The next question most builders ask is: "Can I put this on people's phones?" You can do it in four main ways. They differ a lot in cost, effort and what the app can do on a phone. This lesson defines each one in plain words and compares them, so the rest of this part of the course makes sense.
What to DO as you read: keep your own app in mind. At the end you will choose which approach fits it.
Step 1: Learn Five Key Terms
- Progressive web app (PWA): a normal website with a few extra files added. One is a manifest, a small file that gives the app its name and icon. Another is a service worker, a script that can keep the site working offline and receive notifications. A visitor can add the site to their phone's home screen, and it opens full-screen like an app. You don't need an app store.
- React Native: a toolkit from Meta (the company behind Facebook) that has been maintained since 2015. You write code in JavaScript, the same language used on the web. React Native turns it into the phone's own buttons, text and screens. One codebase produces both an iPhone app and an Android app.
- Expo: a framework built on top of React Native. React Native's own documentation recommends it as the way to start new apps. Expo handles much of the difficult setup and lets you preview your app on a phone quickly.
- Wrapper: a thin native app shell with your existing website running inside it, as if a browser were packed into an app box. Capacitor is a common tool for this. The result can go into app stores, and plugins let the web code reach some phone features.
- Fully native app: an app written in each phone maker's own language and tools:
- iOS (iPhone): the Swift language, written in Xcode, Apple's app-building program.
- Android: the Kotlin language, written in Android Studio, Google's app-building program. Google has called Android "Kotlin-first" since 2019. Java is the older Android language and is still supported.
Analogy: think of the web as a shop on a busy high street.
- A PWA is a loyalty card for that shop that customers keep in their wallet.
- A wrapper is a kiosk inside a shopping centre that sells the same goods.
- React Native with Expo is one workshop that makes branded shops for two shopping centres.
- Fully native means two separate workshops, each built to that centre's exact rules.
Step 2: Compare the Four Approaches
DO: read across each row and notice where the costs change.
| PWA | Wrapper (e.g. Capacitor) | React Native + Expo | Fully native | |
|---|---|---|---|---|
| App store presence | No. Installed from the browser | Yes, if it passes review | Yes | Yes |
| Access to phone features | Limited to what the browser allows | Moderate, through plugins | Broad | Full, including new features on day one |
| Performance | Web speed | Web speed inside an app shell | Close to native | Best |
| Number of codebases | 1 (your website) | 1 (your website) + a thin shell | 1 shared codebase for iOS and Android | 2 (Swift and Kotlin) |
| Work to build and maintain | Lowest | Low to medium | Medium | Highest |
Two points to note (checked October 2026; platform rules change, so check current documentation):
- iPhone PWAs: users must add the site to the home screen themselves from the Share menu, because the iPhone does not offer an automatic install prompt. Push notifications only work after the user does this.
- Wrappers and Apple: Apple's App Store Review Guideline 4.2 says an app should be more than "a repackaged website." A wrapper that adds nothing app-like risks rejection. A later lesson covers app review.
Step 3: Understand Why Native Is Back on the Table
For years, small teams usually ruled out fully native apps, for these reasons:
- Native meant two codebases, one for iPhone and one for Android.
- That meant two languages (Swift and Kotlin) and two sets of tools.
- Every feature and every bug fix had to be done twice.
- A solo builder could rarely learn both, so React Native, wrappers or PWAs won by default.
What changed: AI coding tools can now write Swift and Kotlin from your plain-language instructions. The extra work of a second codebase is much smaller than it was. It hasn't gone away: you still have two apps to test, release and maintain. But native is no longer automatically out of reach. The next lesson, on going native with an AI coding agent, looks at this in detail.
Step 4: Match the Approach to an Existing Website
You already have a working website, so this is the usual order to consider:
- Start with a PWA. It reuses the site you have, adds a home-screen icon and offline support, and costs almost nothing extra. Ask your AI assistant to "add a web app manifest and service worker," then check that the icon and name appear correctly.
- Add a wrapper if you need an app store listing or a few phone features, and you can make the app feel genuinely app-like.
- Consider React Native with Expo or fully native only when you need strong performance, deep phone features, or a mobile experience built for phones from the start. Either option means rebuilding the front end.
DO now: write one sentence: "My app is ___; the approach I'd try first is ___ because ___."
Key Takeaways
- A PWA is your website, installable to the home screen. You don't need an app store.
- A wrapper (such as Capacitor) puts your website inside an app shell so it can be listed in app stores.
- React Native turns one JavaScript codebase into real iOS and Android apps. Expo is the recommended framework for it.
- Fully native means Swift in Xcode for iOS and Kotlin (formerly Java) in Android Studio for Android: two codebases, with the best performance and access to every phone feature.
- AI coding tools have made native realistic for small teams again.
- For an app that already exists as a website, a PWA is usually the first step.