HTML5 App Development: Web Apps and PWAs That Feel Native
How we build web apps and PWAs that feel native, work offline and install to the home screen, and where the platform limits sit, especially on iPhone.
HTML5 app development today means building web applications that behave like apps: they load instantly on repeat visits, keep working on a weak connection, can be installed to the home screen and respond to touch the way people expect. Most people call the result a progressive web app, or PWA.
Done well, a web app reaches every device from one codebase, ships updates the moment you deploy and needs no store approval. Done carelessly, it feels like a website pretending to be an app. This article covers how we build the first kind, and where the platform limits are, particularly on iPhone.
What we build with web technologies
- Installable PWAs for booking, ordering, loyalty and self-service, where a detour through an app store would lose customers.
- Internal tools and field apps for teams that need something on their phones soon, without store accounts or device management.
- Web experiences that complement a native app: onboarding, campaigns and pages people share by link.
- Hybrid apps that put a web codebase inside a native shell with Capacitor, for a store presence and access to native plugins.
- Rebuilds of dated front ends in current HTML, CSS and TypeScript, including anything built for Flash or Silverlight, which browsers no longer run.
- Lightweight interactive experiences and casual games on canvas and WebGL.
These sit on the same foundations as our broader web application development: TypeScript, a modern framework such as React or Angular, and an API designed for the clients that use it.
What makes a web app feel native
Users do not judge a web app by its technology. They judge it by whether it hesitates, and these details decide that:
- An app shell that loads from cache. A service worker stores the shell and static assets, so repeat launches render immediately and only data comes from the network.
- A proper manifest. Name, icons, theme color and standalone display mode give the installed app its own icon and window, without browser controls.
- Layout that respects the device. Safe-area insets around notches and home indicators, dynamic viewport units so collapsing toolbars do not jolt the layout, and inputs that stay visible above the keyboard.
- Touch-first interaction. Large targets, immediate feedback on tap, controlled overscroll, and animated navigation with the View Transitions API where the browser supports it, while respecting reduced-motion settings.
- Native form behavior. The right input types and autocomplete attributes bring up the correct keyboard and let the browser fill in addresses and one-time codes, while passkeys replace passwords through WebAuthn.
- A performance budget. JavaScript size and Core Web Vitals are measured in CI and from real users, because a heavy bundle on a mid-range phone is the fastest way to feel like a website.
Offline support that holds up
“Works offline” can mean anything from a friendly error page to a full local database. We decide per feature, then choose the strategy:
- Cache-first for versioned static assets, which never change once published.
- Stale-while-revalidate for content that can be briefly out of date, such as catalogs or articles.
- Network-first with a cached fallback for data that should be fresh when possible, such as balances or order status.
- IndexedDB for structured data people work with offline, with a request for persistent storage where the browser supports it.
Offline writes are the hard part. We queue changes locally, show them as pending and sync when the connection returns. The Background Sync API can do this even after the page is closed, but only in Chromium-based browsers; on iOS, syncing waits until the user opens the app again. Conflicts need a rule decided in advance: the server wins, the latest change wins, or the user chooses.
Updates need the same care. A service worker can keep serving an old version long after you deploy a new one, so we build an explicit update flow that tells users a new version is ready and reloads cleanly. We use Workbox to keep caching rules readable, and we test offline paths, flaky networks and storage eviction deliberately, on real devices.
Installability, and the limits on iOS
Installation works very differently on the two mobile platforms, and the difference shapes what a web app can promise.
| Capability | Android (Chrome) | iPhone and iPad |
|---|---|---|
| Install prompt | Your app can offer installation from its own UI | No prompt; users choose Add to Home Screen from the Share menu |
| Push notifications | Supported | Supported only after the app is added to the Home Screen |
| Background sync | Supported | Not supported |
| Bluetooth, NFC and USB | Available through Web Bluetooth, Web NFC and WebUSB | Not available |
| Store distribution | Google Play, packaged as a Trusted Web Activity | App Store only inside a native wrapper that adds real functionality |
On iOS, browsers use Apple’s WebKit engine almost without exception, so Safari’s feature set is effectively the ceiling. Storage deserves caution too. Safari can clear data for sites the user has not visited recently, and although Home Screen apps are treated more generously, we design as if local data can disappear, with the server as the source of truth.
None of this makes PWAs a bad idea on iPhone. It means installation has to be explained inside the product, and any feature that depends on push or background work needs a fallback.
When a web app is the right choice, and when it is not
A web app or PWA is a strong choice when:
- Reach matters more than store presence: people arrive from links, search, QR codes or ads and should be using the product within seconds.
- The product is content, forms and transactions with modest device needs.
- You update often and do not want every change to wait for review.
- You are validating an idea before committing to two app stores, or building internal tools.
It is the wrong choice when the product depends on Bluetooth, NFC, background location or reliable background processing on iPhone; when most of your users are on iOS and notifications are central to the product; or when the app stores are your main acquisition channel. In those cases we recommend a store app, often a single React Native codebase, and our overview of mobile app development compares the options side by side.
Hybrid apps built with Capacitor sit in between. They reuse a strong web codebase and add native plugins for push, biometrics and files, which works well for content and form-driven apps. They are weaker than React Native or native code on animation-heavy interfaces and platform feel, so we recommend them mainly when the web app already exists and is good.
How we run an HTML5 app development project
Discovery starts with your audience’s actual devices and browsers, and with a list of the native capabilities the product needs. That list decides between a PWA, a hybrid app and a store app before any code is written. Design is mobile-first, with installation, offline and update states drawn as real screens rather than left to engineering.
We build in TypeScript with performance budgets enforced in CI. QA tests on real iPhones and Android phones, not only in desktop browser emulation, because Safari’s behavior is where most surprises live. Accessibility follows WCAG, starting with semantic HTML, and security covers HTTPS everywhere, a content security policy, careful token storage and regular dependency audits.
A team for this work is typically a business analyst, a designer, frontend and backend engineers and a QA tester, working in short iterations with a deployable build at the end of each. You receive the code in your repository, the deployment pipeline and, where it applies, the store packaging and listings. Because a web app can be deployed at any moment, we agree a release process with you instead of letting production drift. For deeper interface engineering, see our notes on frontend development.
Frequently asked questions
Is a PWA cheaper than a native app?
Usually, because there is one codebase and no store release process. It stops being cheaper if the product later needs capabilities the web cannot provide on iOS and you build the app anyway, which is why we check that list first.
Can a PWA be listed in the App Store and Google Play?
On Google Play, yes, by packaging it as a Trusted Web Activity. On the App Store, only inside a native wrapper that adds genuine app functionality, since Apple rejects apps that are little more than a website.
Do web push notifications work on iPhone?
Yes, for web apps the user has added to the Home Screen and that ask for permission after a tap. That extra step is a real barrier, so plan email or SMS as a fallback for anything important.
Will our web app work offline?
If it is designed for it. We decide feature by feature what must work offline, what can be read-only and what needs a connection, and we design those states explicitly.
Can you replace our old Flash or Silverlight application?
Yes. Those runtimes no longer work in modern browsers, so the application has to be rebuilt. We often keep the backend and data, rebuild the interface in modern HTML and TypeScript, and use the rebuild to fix what users disliked about the old one.
If you want an app that people can open from a link today, and an honest view of what the web can and cannot do for your product, tell us about your product. We will tell you whether a web app is enough, or where it will fall short.
