Mobile-First Design: Progressive Web Apps

Most businesses asking about Progressive Web Apps are really asking one of two questions: “What is this thing I keep hearing about?” or “Should we build one?” This post answers both, and it is honest about where the technology helps and where it does not.

What makes a website a Progressive Web App

Google’s web.dev documentation defines a Progressive Web App as “a web app that uses progressive enhancement to provide users with a more reliable experience…and can be installed.” That last part, installable, is the key distinction from an ordinary website.

The “progressive” in the name refers to an older web principle: the site works for everyone on any browser, and users on more capable devices or browsers get enhanced experiences on top of that baseline.

The three technical requirements

According to Google’s official PWA documentation, three components are required:

1. HTTPS: the site must be served over a secure connection. This is the baseline for modern web apps.
2. A service worker: a background script that runs separately from the main browser thread. It handles caching, offline behavior, and push notification delivery.
3. A web app manifest: a JSON file that tells the browser how to install and display the app: its name, icon, background color, and whether it opens in a standalone window.

Meeting all three unlocks installability. The browser can then offer the user a prompt to add the app to their home screen.

What “progressive” actually means

The practical implication is straightforward: someone on an older browser or a slow connection still gets a functional website. Someone on a modern device who installs the app gets a faster, offline-capable, notification-enabled experience. One codebase, one deployment, a spectrum of capabilities.

What PWAs can (and cannot) do

Install, offline, push notifications

Once installed, a PWA sits on the home screen like any other app, opens in its own window without browser UI, and can access content offline based on what the service worker has cached. A fitness studio, for example, can cache workout schedules so members can view them without a connection.

Push notifications are the capability most small businesses are actually interested in. They work on Android by default, and have worked on iOS since iOS 16.4, when Apple added Web Push support for home screen web apps. The iOS difference: there is no automatic install prompt in Safari. Users must manually add the PWA to their home screen before notifications can be enabled.

Where native still wins

A PWA cannot access every hardware API a native app can. The Web Bluetooth API is not supported on iOS Safari. The Web NFC API is limited to Android via Chrome. Augmented reality, advanced camera controls (manual focus, multi-lens switching, RAW capture), and deep OS integrations like ARKit or ARCore remain in native-only territory.

If your business needs those capabilities, a native app is the right path. For the vast majority of service businesses, they are not relevant.

PWA vs. native app: an honest comparison for small businesses

Development cost. A PWA runs on a single codebase that works across iOS and Android. A native app requires separate builds for each platform. The ongoing maintenance gap is meaningful: separate app store update cycles, review delays, and two codebases to keep synchronized.

Distribution. PWAs are installed directly from the web, no app store submission required. Native apps go through Apple App Store and Google Play review, which takes time and is subject to policy changes. Both Apple and Google charge up to 30% commission on paid in-app transactions (Apple reduces this to 15% for qualifying small businesses; Google applies 15% to a developer’s first $1M of annual revenue).

Discoverability. This is the most underappreciated advantage of a PWA for small businesses. Googlebot renders JavaScript and indexes PWAs the same way it indexes any website. A native app in the App Store is not indexed by Google Search. If your customers search before they download, a PWA has a structural SEO advantage.

When native wins. Hardware-dependent workloads (industrial equipment interfaces, professional camera tools, advanced AR), performance-critical experiences (high-frequency trading, real-time gaming), and situations where app store presence itself matters (enterprise apps that need iOS MDM management, or industries where users expect to find you in the App Store) are all cases where native development is the right investment.

Who should seriously consider a PWA

The businesses that see the clearest return are those with repeat customers who benefit from a persistent, app-like relationship:

• Appointment-based services (salons, fitness studios, medical clinics): home screen access, offline booking confirmation, and appointment reminder push notifications.
• Food and beverage with regulars: cached menus, order history, loyalty program access without waiting on a slow connection.
• Businesses whose customers are on variable connections: Houston’s suburban and outlying service areas have patchy cell coverage in places. A PWA that works offline is a real advantage.

The businesses where a PWA adds less value are those built around one-time transactions, pure content consumption without repeat visits, or audiences who are unlikely to install anything beyond what they already have on their home screen.

The Sweat Social fitness brand is a useful reference point: the app-like experience that drives repeat engagement and community access is exactly the kind of use case where a PWA earns its complexity. Similarly, the Motion Giraffx video studio site demonstrates how progressive enhancement principles can elevate a web presence without the overhead of a native app build.

The prerequisite: your site has to be fast first

This is the point most PWA conversations skip. A service worker caches what is already there. If your site loads slowly, the first visit is still slow, and the offline cache serves that slow baseline.

Before building PWA capabilities, a site should pass Core Web Vitals: LCP under 2,500 ms, INP under 200 ms, CLS under 0.1. These are measured at the 75th percentile of real user visits, which means even users on slower devices need to clear these thresholds.

A PWA built on a slow foundation will still receive poor Lighthouse scores, will underperform on repeat visits, and will not deliver the reliability improvement the architecture promises. The performance work comes first.

How to evaluate whether a PWA is right for your business

These questions separate businesses that will see real value from those that would be paying for complexity they do not need:

Do your customers come back repeatedly? If yes, home screen installation and push notifications have a clear use case. If most interactions are one-time, the investment is harder to justify.

Does your current site pass Core Web Vitals? If not, fix that first. The performance foundation has to exist before PWA capabilities add value.

Do you need hardware access beyond GPS and camera? If Bluetooth, NFC, or native AR are part of your product, plan for native from the start.

Do your users spend time on iOS? If your audience is predominantly iPhone users, the absence of automatic install prompts means you will need to educate users on how to add the app, which reduces adoption. Factor that into your expectations.

Does app store presence matter in your market? Some B2B buyers and enterprise procurement departments expect to find software in app stores. If that is your sales context, a native app may be necessary regardless of its technical overhead.

For most Houston service businesses, the honest answer is that a well-built mobile-first website, as covered in part one of this series and part two on touch-friendly interfaces, delivers more return than a PWA unless the use case clearly demands the extra capabilities.

When the use case is right, a PWA is a precise tool. It removes the app store friction, keeps the site discoverable in search, and delivers a genuinely app-like experience at a fraction of the cost of native development.

If you are evaluating a PWA for your business and want to work through whether the prerequisites are in place, get in touch with us for a scoping conversation.

Frequently asked questions

What is a Progressive Web App?

A Progressive Web App (PWA) is a website built with specific web technologies that allow it to behave like a native app. It can be installed to a device home screen, work offline, and send push notifications, all without going through an app store. The foundation is three technical requirements: HTTPS, a service worker, and a web app manifest.

Do Progressive Web Apps work on iPhones?

Yes. iOS and iPadOS have supported PWA installation and push notifications since iOS 16.4. The main difference from Android is that iOS Safari does not show an automatic install prompt. Users must manually add the PWA to their home screen first before push notifications can be enabled.

What is the difference between a PWA and a native app?

A native app is built for a specific operating system (iOS or Android), distributed through an app store, and requires separate codebases for each platform. A PWA is built on web technologies, works on any device with a modern browser, is discoverable by search engines, and requires no app store submission or commission. Native apps have advantages in hardware access and performance-critical workloads.

Can a small business benefit from a PWA?

Yes, under specific conditions. Service businesses with repeat customers, such as fitness studios, salons, or appointment-based businesses, see the clearest benefit because PWAs enable home screen access, offline content, and push notifications without the cost of native app development. The prerequisite is a fast, well-maintained website that already passes Core Web Vitals.