Progressive
web app development
in Irvine

A PWA blurs the line between a website and an app. The same URL serves people in a browser tab and people who launched it from an icon. Standard web analytics lumps them together. To learn whether installation matters for the business, the two groups have to be separated first.

The simplest signal is the display mode. A media query for display-mode standalone returns true when the app runs in its own window. Read it on every page load and send it to analytics as a custom dimension. Older iPhones expose a navigator.standalone flag with the same meaning. From that moment, every report can be split by launch context.

Install events come next. On Chromium browsers the page receives beforeinstallprompt when the app qualifies for installation. If you show your own install button, log when it appears, when it is tapped and what the user chose through the userChoice promise. The appinstalled event fires once the installation completes, whether it came from your button or from the browser menu.

Safari offers no such events. Installation happens through the share sheet, and the page is never told. The only evidence arrives later, when a session starts in standalone mode. Count first standalone sessions per device as a proxy for installs on iOS. It is an estimate, and the reports should say so.

Desktop installs follow the Chromium pattern. Chrome and Edge fire the same events on Windows, macOS and Linux. Report desktop and mobile separately, though. The reasons people install differ. A desktop user often wants a separate window for a tool used all day. A phone user wants an icon next to other apps.

Uninstalls cannot be measured at all. No browser reports them. A useful substitute is the gap between standalone sessions. If a device that used to launch the app weekly goes silent for two months, treat it as lost and stop counting it as active.

Offline sessions create gaps of a different kind. Analytics requests sent without a connection simply fail. For an app built to work offline, that means the most loyal users may look the least active. Queue analytics hits in IndexedDB and replay them when the connection returns. Workbox ships a ready module for Google Analytics, and the same idea works for other tools. Keep the original timestamp so the event lands on the right day.

Server logs help fill the picture. Requests from an installed app can carry a header or a query flag set by the service worker. That lets the backend count active installed clients without any analytics script. It also works when a tracker is blocked. Many users block them.

Attribution needs a light touch. It is tempting to add a campaign parameter to start_url so that every launch from the icon is tagged. That works, but only if the manifest also has a fixed id field. Without it, changing start_url can make browsers see a new app. A cleaner option is to set the tag in code when display mode is standalone.

Choose a few metrics and watch them over time. The share of sessions launched in standalone mode shows how much of the audience has adopted the icon. Retention for installed users versus browser users shows whether installation changes behaviour. The acceptance rate of the install prompt, broken down by the screen where it appeared, shows where the offer makes sense.

Be careful with conclusions. Installed users are often the most engaged to begin with. They installed because they already liked the product. A higher retention figure in that group does not prove that installing caused it. To test causation, show the install prompt to a random half of eligible users and compare both halves over a few weeks.

Keep the event list short. Five or six well defined events beat forty vague ones. Name them once. Document what triggers each. Then build one dashboard that the product owner actually opens every week.

Finally, look at quality signals separately for each mode. Load times from a warm cache in standalone differ from first visits in a browser. Errors can differ too, especially when an old service worker serves stale files to installed users. Split crash and error dashboards by display mode, and old versions will stop hiding inside the averages.

Clients often ask whether a web app can reach the hardware of the phone. The answer depends on the feature and on the browser. Some capabilities work everywhere. Others exist only in Chromium, and a few remain native territory. Mapping this before design starts avoids promising a screen that cannot be built.

The camera is the easiest case. For a simple photo, an input element of type file with an accept attribute for images opens the camera or the gallery on every modern phone. The capture attribute hints that the camera should open directly. No permission dialog appears, because the user takes the picture through a system screen. For a live preview, such as scanning a document edge, getUserMedia gives the page a video stream after the user grants access.

Barcode and QR scanning deserve a note. The BarcodeDetector API is fast where it exists, but support is uneven, and Safari has lacked it for a long time. A JavaScript decoding library running on frames from getUserMedia works everywhere. It costs some battery and a slightly slower read. Most teams use the native detector when present and the library as a fallback.

Location works through the Geolocation API. It needs HTTPS and a permission prompt, and it runs only while the page is open and visible. There is no background tracking for web apps. Delivery drivers who need their route recorded with the screen off will need a native app. For a store finder or a check-in button, the web API is enough.

Accuracy is another limit. The browser may return a position from Wi-Fi or cell towers first. GPS takes longer. Request high accuracy only when the task needs it. It drains the battery. Show the accuracy radius on the map, too. Users forgive a wide circle. They do not forgive a pin placed on the wrong street.

Files are split by platform. Every browser can read files the user picks and download files the app creates. The File System Access API goes further, letting a desktop app open a file, edit it and save it back in place. That API is available on Chromium desktop browsers. A manifest entry called file_handlers can even register the installed app as a handler for certain file types on those systems.

Sharing has two directions. Sending is broadly supported: navigator.share opens the native share sheet with a title, text, a link or files. Receiving is narrower. The share_target field in the manifest lets an installed PWA appear in the share sheet of Android, so a user can send a photo from the gallery straight into the app. On iOS, web apps do not appear there.

Permissions work per origin. Once a user denies camera access, the browser will not ask again on its own. The app must explain how to re-enable it in settings. Ask at the moment of use. Never on the first screen. A button labelled scan a receipt justifies the prompt. A cold dialog on launch does not.

A handful of other features are Chromium only. Web Bluetooth, Web NFC and WebUSB let web apps talk to devices, mostly on Android and desktop. Vibration works on Android and is ignored on iPhones. Clipboard access works widely, though reading from the clipboard usually needs a user gesture and permission.

Contacts are a special case. The Contact Picker API lets the user pick a name and number from the address book. It exists in Chrome on Android. Elsewhere it is missing. A plain phone field is the fallback. Keep it short and forgiving.

Build with feature detection, never by checking the user agent. Test for navigator.share, for window.BarcodeDetector, for the existence of the method you plan to call. Offer the richer path when it is there and a plain fallback when it is not. A share button can become a copy link button. A live scanner can become a photo upload.

Document the result as a table of features against browsers, with the fallback written in each cell. Designers use it to plan both versions of a screen. Testers use it to decide which phones to hold in their hands. And the client sees in advance where a PWA stops and a native wrapper would begin.

Browsers add capabilities every year, so review that table at each major release rather than trusting a list written at kickoff.

Many PWA projects do not start from scratch. There is already a website with traffic, a CMS and a team that edits content every day. Rebuilding it as a single page app is rarely necessary. A careful sequence of small releases can add installation and offline behaviour to the site it already is.

Step one is an audit. The site must run on HTTPS everywhere, with no mixed content. Check how URLs are structured and which parts belong to the future app. A shop may want the catalog, the cart and the account area inside the app, while the blog and the careers page stay outside. Write that boundary down, because it becomes the manifest scope.

Step two adds the manifest and icons. Name, short name, id, start address, scope, display mode, colours and a maskable icon set. Link the file from every page in scope. Nothing changes for visitors yet, but browsers start to recognise the site as installable once a worker exists.

Step three registers a minimal service worker. At first it does one thing: when a navigation request fails, it shows a friendly offline page stored during installation. This release is small and easy to reverse. It also exposes deployment questions early, such as where the worker file lives and which cache headers the server sends for it.

Watch the error logs for a few days after this release. Registration failures show up here. So do conflicts with an existing CDN, a firewall rule or a security plugin that blocks the worker file. Fix those now. They get harder once the worker does more.

Step four caches static assets. Stylesheets, scripts, fonts and logos are precached or cached on first use. Build tools that add a content hash to file names make this safe. If the current build produces files with fixed names, change that first, or the worker will keep serving old styles after a redesign.

Step five handles content pages. Articles and product pages can use network first with a cache fallback, so a returning visitor can reopen what they read yesterday. Set limits on the number of stored pages. A news site does not need every article of the year on the phone.

Test the CMS preview too. Editors often open drafts at special URLs. If the worker caches those, an editor may keep seeing an old draft. Exclude preview paths and admin areas from every rule. Tell the editors what changed. They will notice first.

Step six is the dangerous one: personalised areas. Account pages, carts and anything rendered with the name of the user must stay out of generic caches. Many CMS platforms render personal elements into otherwise public pages, such as a greeting in the header. Those fragments need to load separately through an API call, or the whole page must be excluded. Skipping this step is how one user ends up seeing the basket of another.

Step seven decides what should work offline on purpose. This is a product question, not a technical one. Perhaps saved recipes, a downloaded ticket or a draft form. Build those features deliberately with IndexedDB and a clear interface state, instead of hoping the cache will cover them.

Step eight adds measurement: display mode tracking, install events and error logging from the worker. Without data, nobody can tell whether the new behaviour helps.

Step nine is housekeeping. Add the worker file and the manifest to the deployment checklist. Assign one person to own them. Review cache rules whenever the site gets a new section. A PWA layer without an owner decays quietly. Nobody notices until a user reports stale prices.

Keep each step as a separate release with a way back. If the worker causes trouble, the site must still function as a normal website. That is the quiet advantage of this approach. At every stage, the site stays a website, and the app features sit on top of it. Small releases also make the cause of any new bug easy to find.

When a PWA opens from the home screen in standalone mode, the browser interface disappears. No address bar. No back arrow. No reload button, no share icon, no way to see the current URL. The web page suddenly carries the whole job of navigation, and many sites are not ready for that.

Back navigation is the first gap. Android phones have a system back gesture that works with the history of the page. iPhones do not. In a standalone PWA on iOS, a user who follows a link into a product page may find no obvious way back. The fix is an explicit back control in the app header on inner screens, wired to history or to the parent screen.

Reloading is the second gap. In a browser tab, people refresh when something looks stuck. In standalone mode they cannot. Pull to refresh may work on some platforms and not on others. If a screen shows data that goes stale, add a visible refresh action or refresh the data when the app returns to the foreground. Listen for the visibilitychange event and reload lists that are older than a few minutes.

Links need rules. A link to an address outside the manifest scope leaves the app window. On Android it opens in a custom tab over the app. On desktop it goes to a normal browser window. On iOS the behaviour has shifted across versions. Mark external links clearly, and test each type, including payment pages, OAuth sign in and PDF files.

Sign in flows are a common failure. A redirect to an identity provider may open outside the app, finish there and never return. Prefer flows that stay within scope, such as a popup or a redirect back to an in-scope URL that the provider allows. Test the complete loop on each platform before launch.

Errors need a new home as well. In a browser tab, a failed page shows the familiar browser error. In standalone mode, the same failure can leave a blank white window with no controls at all. Catch navigation failures in the service worker and return an offline page that has the header, the back control and a retry button.

Sharing also changes. In a browser, people copy the address. In standalone mode there is nothing to copy. Add a share button on content that people will want to send, using the Web Share API with a copy link fallback.

The screen edges need attention. Phones with notches and rounded corners report safe area insets through CSS environment variables. Set viewport-fit to cover in the viewport meta tag, then pad headers and bottom bars with env(safe-area-inset-top) and the matching bottom value. Without that, a tab bar can sit under the home indicator and ignore taps.

Small web habits look odd in an app window. Long presses on images show a save menu. Text in buttons can be selected by accident. Double taps may zoom. Use CSS to disable selection on controls and callouts on interface images, while keeping text in content areas selectable.

Status bar colour needs a check on each platform. On iOS, a meta tag decides whether the status bar text is light or dark over the app. Pick the wrong one, and the clock disappears into the header. It takes a minute to fix. It is easy to miss in the browser.

On desktop, the title bar offers an extra option. The window controls overlay setting lets the app draw its own content in the title bar area, next to the minimise and close buttons. It gives a more native look, but the layout must reserve space for those controls.

Detect the mode and adapt instead of forcing one layout on both. The display-mode media query works in CSS and in JavaScript. A browser visitor keeps the familiar page. The installed user gets a header with a back button and a share action.