Progressive Web Apps That Install, Work Offline, and Send Push

Progressive web apps: one app that installs, works offline, and skips the app store

A progressive web app is the same web page your customers already visit, upgraded so it can be installed to a phone or desktop, launched from an icon, run full-screen, work with no connection, and push notifications — without ever going through the Apple App Store or Google Play. It is not a second product bolted onto your website. It is your website, engineered to meet a short list of technical standards that browsers reward with app-like powers.

EVOTECH IT LLC builds production progressive web apps for companies across the United States — storefronts, booking tools, dashboards, member portals, field and internal apps, and content platforms. We are a US-based, remote-first team with more than 20 years in web and software development and a 5.0-star rating. Everything we build is yours: the source code, the data, and the app itself. There is no monthly per-seat rent and no platform that can pull your app over a policy change.

Below is a straight, working-level guide to what makes an app a PWA, what one can and cannot do, how offline and push actually function, and exactly what our build includes — so you can decide with real information whether a PWA fits your project, whether you hire us or not.

What actually makes a web app a PWA

Three technical ingredients turn an ordinary website into an installable progressive web app. Miss any one and browsers withhold the app-like behavior. Get all three right and the same URL becomes something a person can install and trust.

1. HTTPS (a secure context)

A PWA must be served over HTTPS. The powerful browser features a PWA relies on — service workers, push, geolocation, camera — are only granted to secure origins, because they are too sensitive to expose over an unencrypted connection that could be tampered with in transit. In practice this means a valid TLS certificate on your domain, which is standard and inexpensive today.

2. The web app manifest

The manifest is a small JSON file that tells the operating system how to treat your app once installed: its name and short name, its icons at every required size, the theme and background colors, the start URL it launches to, and — critically — its display mode. Setting display to standalone or fullscreen is what strips away the browser address bar so your app opens looking like a native app rather than a tab.

3. A service worker

The service worker is the engine of a PWA: a background JavaScript file the browser runs separately from your pages. It sits between the app and the network like a programmable proxy, which is what makes offline support, caching, push notifications, and background sync possible. A registered service worker with a fetch handler is the single feature that most separates a PWA from a normal responsive site.

When those three are in place, Chromium browsers offer an install prompt, iOS offers Add to Home Screen, and your site earns a passing grade in the installability audit. We build all three to spec and verify them on real devices before launch.

What a PWA can do that an ordinary website can’t

Meeting the PWA standard unlocks a set of abilities an ordinary website simply does not have. These are the capabilities we design around:

• Installation to the home screen. Users add your app with one tap or click and launch it from an icon, with no download from a store and no gigabytes of storage consumed.
• Full-screen, standalone launch. The app opens without browser chrome — no address bar, no tabs — so it reads as an app, with your own splash screen and theme color.
• Offline and flaky-network operation. Cached pages, assets, and data load instantly and keep working on a subway, a plane, a job site, or a hotel Wi-Fi that keeps dropping.
• Push notifications. Re-engage users with messages that arrive even when the app is closed — on Android, Windows, macOS, and, with one caveat we cover below, iOS.
• Background sync. Actions a user takes offline, like submitting a form or sending a message, are queued and completed automatically the moment the connection returns.
• Device hardware access. Through modern web APIs a PWA can use the camera, microphone, geolocation, and motion sensors, and on Chromium browsers even Bluetooth, USB, and NFC for many use cases that once required a native app.
• Fast, app-like navigation. With the app shell cached, screens change instantly instead of reloading a full page over the network.
• Share and file handling. A PWA can register as a share target and open specific file types, so it appears in the system share sheet alongside native apps.

Not every capability is available on every browser and operating system, and being honest about that is part of good engineering — we scope your build to the platforms your users are actually on and design graceful fallbacks for the rest.

How offline support really works (service workers and caching)

Offline support is the capability that most surprises people, so it is worth understanding how it works — because ‘works offline’ can mean very different things depending on how it is engineered.

The service worker intercepts every network request the app makes and decides how to answer it: from the network, from a local cache, from a stored database, or some combination. Two browser storage systems do the heavy lifting — the Cache API for files (HTML, CSS, JavaScript, images) and IndexedDB for structured data (records, messages, drafts). Choosing the right answer for each request is a deliberate design decision called a caching strategy.

The main caching strategies

• Cache-first. Serve from the cache immediately, only touching the network if a file is missing. Ideal for static assets and the app shell — the fastest possible load.
• Network-first. Try the network for fresh data, then fall back to the cache when offline. Right for content that changes often, like a feed or a price.
• Stale-while-revalidate. Serve the cached copy instantly for speed, then quietly fetch an update in the background for next time. The best of both for many screens.

App shell and background sync

We precache the app shell — the HTML, CSS, and JavaScript that make up the interface frame — so the app opens instantly even on a first offline visit, then load your live data into that shell. For actions taken while offline, the Background Sync API queues them and replays them automatically when connectivity returns, so a form submitted in a dead zone is not lost. We build these strategies with Workbox, Google’s battle-tested service-worker library, rather than hand-rolling fragile caching logic, and we always ship a clear offline fallback screen instead of a broken page.

Push notifications on the web — including the honest iOS caveat

Push notifications let your app reach users after they have closed it — an order update, a new message, an appointment reminder. On the web this runs on open standards: the Push API receives messages, the Notifications API displays them, and delivery is authenticated with VAPID keys so only your server can push to your users.

The honest iOS caveat

For years, web push did not work on iPhones or iPads at all. As of iOS and iPadOS 16.4, released in spring 2023, it does — but with an important condition: the user must first install the PWA to their home screen. Web push does not fire for a PWA merely open in a Safari tab on iOS. On Android, Windows, macOS, and Linux, push works in the browser without that requirement. We design your notification flow around this reality — for example, encouraging installation before offering to enable alerts — instead of pretending the limitation is not there.

Asking permission the right way

The fastest way to get blocked is to demand notification permission the instant a page loads, before you have earned any trust. We wire permission requests to a meaningful moment — after a purchase, or when a user opts into alerts they actually want — and we make them easy to turn off. Notifications that respect the user get accepted; notifications that ambush them get muted, and browsers increasingly penalize sites that abuse the prompt.

Installable, with no app-store gatekeeper

The most strategic feature of a PWA is what it does not require: an app store. A PWA is distributed at a web address. Anyone who visits can install it directly from the browser, and that shifts the economics and the control in your favor.

• No gatekeeper and no revenue cut. There is no review queue that can reject your release, no policy change that can pull your app overnight, and no platform commission skimmed off purchases routed through the web.
• Instant updates. When you ship a change it is live for everyone on their next launch. There is no app-store review wait and no fleet of users stuck on an old version because they never tapped ‘update’.
• One link to install. On Chromium browsers an install button or your own ‘Install app’ call-to-action, powered by the beforeinstallprompt event, adds the app in a tap; on iOS, users use Safari’s Add to Home Screen. The same URL you already share becomes the install.
• Better discovery than a buried listing. Because a PWA is a real website, it is indexed by Google and can be found in search — a channel a native app locked in a store does not get.

And if you do want a store presence, you can have both. Tools like PWABuilder and Android’s Trusted Web Activity can package the same PWA for Google Play and the Microsoft Store, so you get store distribution where it helps without maintaining a separate codebase. We advise on when that is worth doing and when the open web is enough.

When a PWA fits better than a native app — and when it doesn’t

A PWA is a superb fit for a large share of projects and the wrong tool for a specific few. The honest way to choose is to match the build to what your app actually needs to do, not to a trend. Here is the head-to-head we walk clients through.

A PWA is usually the better choice when…

…you want the widest reach from one codebase, fast iteration, search visibility, and low friction to install — think e-commerce, booking and scheduling, SaaS dashboards, customer and member portals, media and content, internal and field tools, and anything where getting users in without a download matters.

A native or cross-platform app is the better choice when…

…you rely on heavy 3D or augmented reality, continuous background location or sensor processing, tight integration with platform-only frameworks, or App Store presence as your primary marketing channel. We go deeper on this exact decision on our PWA vs. native app comparison, and if a native build is the right call we will point you to app development rather than sell you a PWA that fights its own limits.

PWA vs. cross-platform vs. native: choosing the right build

‘PWA or native’ is really a three-way choice, because cross-platform frameworks sit in between. Understanding all three keeps you from overbuilding.

Many products are best served by a PWA first — it is the fastest way to get a real, installable app in front of every user and to learn what they need — with a cross-platform or native build added later only if a specific requirement demands it. If your project leans toward the middle column, our cross-platform app development page covers React Native and Flutter in depth. We recommend the lightest approach that fully meets your needs, and never a heavier one just to inflate a quote.

What an EVOTECH progressive web app build includes

A PWA is only as good as its engineering. A checklist app that passes an audit but loads slowly, or one that caches so aggressively users never see updates, helps no one. Every EVOTECH progressive web app build includes:

• Built on your stack. We build with the right tool for your project — React, Vue, Angular, Svelte, Next.js, or plain JavaScript — so the PWA fits your team and future maintainers, not our convenience.
• A correct, complete manifest. Name, all required icon sizes, maskable icons, theme and background colors, and the right display mode, so the installed app looks polished on every device.
• A production service worker. Built with Workbox, with a deliberate caching strategy per resource type, a versioned update mechanism, and a real offline fallback — not a copy-pasted script that traps users on stale content.
• Offline and background sync designed around your actual data, so the app is genuinely usable without a connection, not just technically installable.
• Push notification infrastructure with VAPID keys, permission flows timed to earn opt-in, and the iOS install-first path handled.
• Performance tuning to pass Lighthouse. We optimize Core Web Vitals — load, interactivity, and visual stability — with code-splitting, lazy loading, and asset optimization, because a PWA that loads slowly defeats its own purpose.
• Responsive, accessible UI that works from phone to desktop and meets accessibility standards.
• Cross-browser and real-device testing, explicitly including iOS Safari, where PWA behavior differs most.
• Full ownership and documentation. You get the source code, the deployment, and a clear handoff. It is your app.

Our PWA development process, step by step

1. Free consultation. Over phone or video we learn what you are building, who uses it, and which PWA capabilities — install, offline, push — actually matter for your case. You get honest guidance on whether a PWA is the right fit before anyone talks scope.
2. Scope and fixed-scope quote. We define the features, platforms, and integrations, then give you a clear, fixed-scope quote. No hourly surprises and no invented numbers.
3. UX and architecture. We design the screens and the technical architecture together — data model, caching strategy, and which parts must work offline — so the engineering supports the experience.
4. Build. We develop the app in your chosen framework, wire up your backend or APIs, and implement the interface against real content.
5. PWA engineering. We add the manifest, build the service worker and offline strategy, and implement push and the install experience — the layer that turns a web app into a PWA.
6. Performance and audit. We tune Core Web Vitals and run Lighthouse until the app passes installability and performance, then profile on mid-range devices, not just fast ones.
7. Cross-device testing. We verify on Android, desktop, and iOS — installing, going offline, and testing push on each — because the gaps are always at the platform edges.
8. Launch and support. We deploy to your domain over HTTPS, hand off the code and documentation, and stay available. We are US-based and reachable at (832) 359-2425.

PWAs for small businesses vs. enterprise teams

PWAs earn their keep across very different kinds of organizations. Because we work nationwide with a remote-first team, we build for both ends of the spectrum.

Small businesses and consumer apps

For a store, restaurant, clinic, gym, or service business, a PWA is often the smartest first app: an installable storefront for e-commerce, a booking and scheduling tool, a loyalty or membership app, or a content and media experience that customers add to their home screen and get notified from — without paying to build and maintain separate iOS and Android apps or waiting on store reviews. It also keeps working in low-signal places like parking garages and event venues, and it shows up in Google search, which a store-only app never does.

Enterprise and internal tools

For larger organizations, PWAs shine as internal and field applications: inspection and work-order tools, warehouse and inventory apps, sales dashboards, and staff portals that must run on whatever device an employee has and keep functioning when the warehouse Wi-Fi or the rural job site drops. Because a PWA installs from a URL, IT can deploy and update it across a fleet without an app store or mobile-device-management gymnastics, and because you own the code, there is no per-seat license inflating as you grow. For workflows that outgrow a browser app, we also build full custom software.

Whether you are a single location or a national operation, the same core PWA engineering applies — we size the build to your reality and integrate with the systems you already run.

Common PWA mistakes (and how we avoid them)

Most disappointing PWAs fail for a handful of avoidable reasons. Knowing them helps you judge any developer — including us.

1. Caching so aggressively that users never see updates. A cache-first service worker with no versioning can pin people to old content and old bugs for good. We build a deliberate update mechanism so new releases actually reach users.
2. Begging for push permission on page load. Asking before you have earned trust gets you blocked and can hurt the whole site. We tie the request to a moment the user actually wants alerts.
3. Ignoring iOS. Safari on iOS handles PWAs differently — install-first push, stricter storage limits, quirks in standalone mode. A PWA tested only on Chrome breaks for a huge share of users. We test iOS explicitly.
4. No offline fallback. A PWA that shows a broken page with no connection is worse than a normal site. We always ship a clear offline experience.
5. A bloated bundle. Shipping megabytes of JavaScript kills the fast-loading advantage that justifies a PWA in the first place. We budget performance and code-split from the start.
6. Treating the PWA as an afterthought. Bolting a manifest onto a slow site does not make it an app. The offline model and architecture have to be designed in, not sprinkled on.
7. Silent storage eviction. Browsers can clear cached data under storage pressure, especially on iOS. We design for it so nothing important lives only in a cache that can vanish.

What affects the cost of a PWA project

Every PWA is scoped differently, so we give a real, fixed-scope quote after a free consultation rather than a fake ‘starting at’ number. The honest drivers of cost are:

• Scope and features. A handful of screens costs less than a full application with accounts, payments, and complex workflows. Features drive price more than anything else.
• Offline complexity. Caching a content site is straightforward; making a data-heavy app fully usable offline, with conflict handling and background sync, is real engineering.
• Push and real-time. Notification infrastructure and live updates add backend work beyond the front end.
• Backend and integrations. Connecting to your existing systems, a new API, payments, or a CMS affects effort — the more moving parts, the more work.
• Design. A polished, custom-designed interface takes more time than a clean template, and is often worth it.
• New build vs. retrofit. Turning a solid existing site into a PWA is usually lighter than building from scratch; retrofitting a slow or dated site sometimes means fixing the foundation first.

We offer a free consultation and fixed-scope quotes, by phone or video, anywhere in the United States. We will tell you the smallest build that proves the value, so you spend on what matters. To get real numbers for your project, book a free consultation or call (832) 359-2425.

Related services

Frequently asked questions