Guides / How to build

How to Build a Mobile-Friendly Web App

Build a web app that works well on phones: responsive layout, touch-friendly design, installable PWAs, their limits, and when you need a store app.

Mythex Team · 2026-09-29 · 6 min read

A mobile-friendly web app is a website that works like an app on a phone: it fits the narrow screen, has large touch targets, loads fast on mobile data, and can be added to the home screen as a progressive web app (PWA). For most new apps this is the practical first version — one codebase, one link, no store review. It has real limits, though, especially around notifications on iPhone and deep device access, and this guide is straightforward about when you need a native app instead.

Three ways to be "on mobile"

A PWA is a responsive web app with a few extras, so you don't have to choose between the first two. Build responsive first, then make it installable. For a deeper comparison see native vs progressive web apps.

What web apps can and can't do on phones

Browsers can do more than many people assume:

• Camera and photo upload, through standard file inputs.
• Location, with the user's permission.
• Installing to the home screen with an icon and full-screen launch.
• Offline use, by caching pages and data with a service worker (a background script the browser runs for your site).
• Push notifications — with a catch on iPhone. Apple's WebKit team says web push came to iOS and iPadOS 16.4 for web apps added to the Home Screen. Users must install the app first, then allow notifications.

Where native still wins:

• Deep device features such as background location, Bluetooth accessories, health data and home-screen widgets — support in the browser is limited or varies by platform.
• App store discovery. If people will search the store for you, you need to be in it.
• Heavy offline work, such as large data sets synced in the background.
• Performance-critical graphics, such as demanding games.

If none of those are central to your app, a web app will likely serve you well.

Designing for phones first

Design the phone layout first and let it expand for larger screens; the reverse usually produces cramped phone screens.

Layout

• One column on small screens. Sidebars become a bottom bar or a menu.
• No sideways scrolling. Wide tables become cards or scroll inside their own container.
• Readable text without zooming — body text around 16px.

Touch

• Big tap targets. Around 44 by 44 pixels is a common minimum. Leave space between them.
• Primary actions within thumb reach, near the bottom of the screen on tall phones.
• No hover-only features. Tooltips and menus that appear on hover don't exist on touch screens.
• The right keyboard. Email fields should bring up the email keyboard, phone fields the number pad. Ask for the correct input types.

Speed

• Small images at sensible sizes, loaded as they come into view.
• Fewer heavy libraries. Every one adds download time on mobile data.
• Skeleton screens or clear loading states, so the app never looks frozen.

Safe areas and the address bar

On modern phones, content can end up under the notch or the home indicator, especially in a full-screen installed app. Ask for safe-area padding. Also watch out for full-height layouts that jump as the browser's address bar appears and disappears.

Making it installable (PWA)

To be installable, a web app needs:

1. A web app manifest — a small file with the app's name, short name, icons, theme colour and how it should open (usually full-screen "standalone").
2. Icons in the sizes the platforms expect, including one suitable for Apple devices.
3. HTTPS, which any properly hosted app already has.
4. A service worker if you want offline support or push.

Then tell users how to install. Android browsers typically offer an install prompt or menu item; on iPhone it's the Share button, then "Add to Home Screen". A short "Install this app" note with those steps helps a lot.

Offline support is where PWAs get complicated. Caching the app's pages so it opens without a connection is straightforward. Letting people change data offline and syncing it later is real work — only ask for it if your users truly need it.

A first prompt that works

Build a web app for our cleaning team to see today's jobs and mark them done. Design for phones first: one column, large tap targets, the main action button fixed near the bottom, no hover-only controls, no sideways scrolling, and correct keyboards for phone and email fields. Each job shows the address (tap to open in maps), the client's phone (tap to call), a checklist and a "Mark complete" button that can take a photo. Managers log in on a laptop to assign jobs; on a wide screen show a table instead of cards. Make it an installable PWA with a manifest, icons and a standalone display, and cache the app shell so it opens without signal. Save data in a database.

Build steps

1. Build the phone layout first, on sample data, and check it in a phone-sized preview.
2. Test on real phones — at least one iPhone and one Android if your users have both. Emulators miss things like the on-screen keyboard covering inputs.
3. Walk the main task with one thumb. If anything needs two hands or zooming, fix it.
4. Add the manifest and icons, then install it on both platforms and check the icon, name and splash.
5. Decide on offline. Start with "opens without signal and shows a clear message"; add offline editing only if needed.
6. Check speed on a slow connection. Your browser's developer tools can simulate one.
7. Add notifications last, if at all — and plan an email fallback for users who don't install.

Common mistakes

• Designing on a big monitor only. Check every screen at phone width as you go.
• Tables that overflow. Turn rows into cards on small screens.
• Tiny tap targets and links close together.
• Forms that fight the keyboard — wrong input types, fields hidden behind the keyboard, no "next" flow.
• Assuming iPhone push works in the browser tab. It needs the app installed to the Home Screen.
• Promising an App Store app you can't ship. If the store matters, plan for it separately.
• Wrapping a website and calling it an app. Apple's App Review Guidelines ask for apps that go beyond a repackaged website; a thin wrapper risks rejection.

When you need a native app

Go native (or plan a native version after the web app) when:

• Store presence is how customers will find you.
• You rely on background location, Bluetooth, health data, widgets or other device features browsers don't offer reliably.
• Your app must work fully offline for long periods.
• Your users expect it — some audiences simply won't use anything that isn't in the store.

Store publishing has its own costs and steps. As of September 2026, Apple's developer program costs US$99 a year and a Google Play developer account a one-time US$25, according to their own sites, and every release goes through review. Many teams start with a mobile-friendly web app to prove people want the product, then invest in native once they know. How to build an app with AI covers that first stage end to end.

Building it with Mythex

Mythex builds web apps: you describe the app in chat, and check it in the live preview on desktop and in a phone-size frame you can resize. The docs have a mobile-responsive prompt for fixing small-screen layouts. You can ask for a PWA manifest and icons like any other feature, then publish to a public link that works on any phone. Native App Store and Google Play apps are coming soon on Mythex and not available today. See the AI web app builder or browse app templates to start. For a worked example, read how to build a habit tracker app.