The best way to move from mobile web to an app: keep the website, connect the two, move users step by step

Move when your mobile users show at least one of these signals:

They come back often. The same people open the site several times a week to do the same task: book, log, check, message. An icon on the home screen saves them the search or the bookmark every time.

You need notifications they will accept. On iPhone, a website can send push notifications only after the user adds it to the Home Screen. Apple added this in iOS 16.4: “Now with iOS and iPadOS 16.4, we are adding support for Web Push to Home Screen web apps.” An app asks for permission on first use, with no extra step.

You need the phone, not the browser. Background location, widgets, offline use, the camera all day, health data, or new hardware such as foldables. A browser reaches some of these and not others.

You want to be found in the stores. Some users search the App Store or Google Play before they search the web.

Stay on mobile web when most visits come from search and happen once: a recipe, a price check, an article. An app does not help a visitor who will not come back.

A progressive web app (PWA) is your website with an install option and offline support. It needs no store review and no second codebase. On iPhone, push notifications work only after the user adds it to the Home Screen, and it is not listed in the App Store.

A wrapper puts the website inside a native shell and into both stores. Apple reviews it like any app, and guideline 4.2 says: “Your app should include features, content, and UI that elevate it beyond a repackaged website.” A wrapper that only shows the website risks rejection. Capacitor vs Despia compares two wrapper tools.

A native app rebuilds the screens in Swift for iPhone and Kotlin for Android and calls the same backend as the website. It is the most work and gives full access to the phone.

The rule of thumb from the signals above: frequent use but nothing phone-specific → PWA; you need store presence fast and add some native features → wrapper; you need the phone itself or want it to feel like an app on each platform → native.

Do not copy the whole website into the app. List what returning mobile users do, from your analytics, and pick the two or three tasks they repeat. The app does those well; everything else stays on the website and the app links to it.

This also answers Apple’s 4.2 test: an app built around repeated tasks with native screens is not “a repackaged website.”

The app calls the same API as the website, and a user signs in with the same account on both. Do not create a second user database for the app.

Four App Review rules apply the moment the app has accounts or payments:

Account deletion. Guideline 5.1.1(v): “If your app supports account creation, you must also offer account deletion within the app.”

Social login. If the app uses Google, Facebook or another third-party login for the main account, guideline 4.8 requires an equivalent login option as well; Sign in with Apple is the usual way to meet it.

Payments. Guideline 3.1.1: “If you want to unlock features or functionality within your app ... you must use in-app purchase.” If your website sells subscriptions, read section 3.1 for your case before you design the app’s paywall.

Saved passwords. Apple’s associated domains also cover shared web credentials, so passwords saved for your website can be offered in the app. It uses the same file as the links in step 3.

Both platforms let your existing https URLs open the app when it is installed and the website when it is not. Apple: “Users who don’t download the app get the same information in a web browser instead of the native app.” Every link you have already shared keeps working.

iPhone: Universal Links. Host a file named apple-app-site-association, with no extension, at https://<your domain>/.well-known/apple-app-site-association. Apple: “You must host the file using https:// with a valid certificate and with no redirects.” In Xcode, add the Associated Domains capability with an entry like applinks:example.com. The file lists which paths open the app, so pages the app does not cover keep opening on the web.

Android: App Links. Host https://<your domain>/.well-known/assetlinks.json, “served with content-type application/json” and “accessible without any redirects”. Google: App Links open your content “without requiring the user to select your app from a disambiguation dialog”, on “Android 6 and later, on devices that have Google services.”

Each subdomain (www, app, help) needs its own file on both platforms. Apple also warns that links are a way into your app: “validate all URL parameters and discard any malformed URLs.”

For your developer: Apple’s CDN “requests the apple-app-site-association file for your domain within 24 hours”, so test the file before release day.

iPhone: Smart App Banner. Add one meta tag to the pages that lead into the app’s jobs:

<meta name="apple-itunes-app" content="app-id=YOUR_APP_ID, app-argument=THE_PAGE_URL">

Apple: “If the app is already installed on a user’s device, the Smart App Banner intelligently changes its action, and tapping the banner simply opens the app.” The app-argument carries the page URL, so the user lands on the same item in the app. The banner does not show in the iOS simulator; test it on a phone.

Android. Show your own small banner on the same pages, linking to the Google Play listing.

Use a banner, not a full-screen prompt. Apple contrasts its banner with one “that interrupts their experience with the web content”. A visitor who came from search to read one page should be able to read it.

Search engines index your website, not the screens inside your app. Keep the mobile pages, their URLs and their content after the app launches. With Universal Links and App Links on the same URLs, one link serves both: the page for people without the app, the app for people with it.

Do not redirect mobile visitors from the website to the store. The visitor who arrived from search loses the page they came for.

Open the store accounts early. Apple’s Developer Program costs 99 USD per year; Google Play charges 25 USD once. New personal Google Play accounts must “run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days” before production, so recruit those testers from your most active web users.

Turn on the banner page by page. Start with the pages that lead into the app’s jobs, then widen.

Measure the move. Track the share of returning visitors who open the app, and which jobs move first. Keep the web flow working for the users who stay on the web.

How to publish an app on the App Store walks the Apple submission.

Shipping the website in a shell. Apple’s 4.2 rejects apps that are “a repackaged website”, and users who already have the website have no reason to install it.

A second account system. Users who sign up again in the app lose their history from the website.

Links that open the store instead of the content. Without Universal Links and App Links, a shared link opens the browser even for users who have the app.

Switching off the mobile pages. The search traffic that brought your users stops.

Forgetting the store rules for accounts and payments. Account deletion, Sign in with Apple and in-app purchase are the most common surprises for teams coming from the web.