Progressive
web app development
in Bethesda

A progressive web app installed on a phone often sits untouched for days between opens. When the user finally taps the icon, stale content is the first thing they see. A dashboard from last week. A feed with nothing new at the top. The user has to wait for a manual refresh, or worse, assumes nothing changed and moves on without ever seeing what actually did.

Periodic Background Sync closes part of that gap. A service worker registers a sync tag with a minimum interval, and the browser wakes the app in the background from time to time to fetch fresh data and update whatever the cache holds. The next time the user opens the app, the content is already current. No spinner. No wait.

The word periodic matters here, and it is worth separating this from ordinary background sync. Ordinary background sync queues an action the user already took, such as a form submitted while offline, and fires it once a connection returns. Periodic sync runs the other direction. Nobody has to act first. The app simply refreshes itself on a schedule the browser sets, whether or not the user is even nearby.

That schedule is a loose promise, not a fixed commitment. The browser decides the real timing based on signals like battery level, network type, and how often the person actually opens the app. A tag registered for a one-hour interval might run close to that mark on a phone charging on wifi. On a phone running low on battery, the same tag might not fire again until the device is plugged in.

Support is narrower than for most other web platform features covered elsewhere. Periodic Background Sync currently works in Chromium-based browsers on Android for an installed app, and nowhere else. A fallback matters more here than almost any other feature: refresh the data the normal way, on open, and treat periodic sync purely as a bonus for the subset of users whose browser supports it.

What gets refreshed in the background should stay small and cheap. A handful of headlines. An unread count. The latest few records in a list. Pulling a full dataset on every periodic wake drains battery and data for content the user has not even asked to see yet, and browsers penalize apps that behave that way by granting less background time going forward.

Access to this feature is not automatic even on a supported browser. The browser grants periodic sync privileges based on engagement: how often the person opens the app, how long they stay, whether they have it installed at all. An app nobody opens more than once a month is unlikely to get meaningful periodic sync time, no matter how the code is written.

Testing periodic sync in the normal course of development is awkward, because the real interval is decided by the browser, not the developer. Browser developer tools include a manual trigger to simulate a periodic wake on demand for exactly this reason. Real field testing on an actual device, left alone for a day, still catches timing behavior a manual trigger cannot.

The feature earns its place on products where content genuinely changes between visits and freshness matters at the moment of opening: a news reader, a dashboard, an inbox-style tool. For a page that rarely changes, or an app already using push notifications to signal every update, periodic background sync adds engineering cost without a matching benefit. The decision is worth revisiting once usage patterns are clearer, rather than settled permanently at launch.

One detail surprises teams used to push notifications: periodic sync needs no explicit permission prompt from the user. Push requires an opt-in the person can decline. Periodic sync runs quietly as part of the installed app experience, governed by browser heuristics rather than a visible request. That makes it a gentler feature to ship, but it also means a user has no direct switch to turn it off beyond uninstalling the app or adjusting browser-level settings buried well outside typical reach.

Not every update deserves a push notification. A single new message. One pending approval. Three unread items sitting in a queue. None of that needs a banner interrupting whatever the user is doing on the phone at that moment. Yet leaving no signal at all means the user opens the app out of habit rather than because something changed. That slowly trains them to check less often over time.

A small numeral placed directly on the home screen icon fills that gap. The Badging API lets an installed progressive web app set a number, or a plain dot, on its own icon. It works the same way a mail app or a messaging app shows a small circle with a count. The signal sits quietly on the home screen until the user is ready to look. It never pushes itself into the notification tray uninvited.

Setting a badge takes very little code. The app calls a badge-setting method with a number when something changes, and a clearing method once the user has seen it. The browser and operating system handle the rendering, positioning, and any platform-specific styling of the dot or number. The app itself only needs to track which count is accurate at any given moment.

Support is uneven across platforms. Any team considering this feature needs to plan around that, rather than around the best case. Desktop browsers on several operating systems support badging cleanly once a progressive web app is installed. Mobile support varies by platform and browser combination. A badge that never appears for part of the user base should not derail the whole notification strategy. It works best sitting alongside push as one signal among several, not as the only one.

The count itself deserves real thought before implementation starts. A raw count of every unseen item is honest but can climb fast. Nobody wants a badge that reads in the hundreds. Grouping related items helps. So does capping the display at a fixed ceiling, or badging only items that require action rather than everything that merely changed. All three keep the signal meaningful instead of numbing.

Where a badge earns its place is in workflow tools. Task queues. Approval inboxes. Support ticket systems. Anywhere a specific number tells the user something actionable is waiting. Where it does not belong is anywhere the count is cosmetic. A badge showing how many articles were published that day gives information without giving anyone a reason to act on it. A meaningless badge trains people to ignore badges altogether.

Clearing the badge at the right moment matters as much as setting it. A badge that only clears when the app is opened and fully loaded, rather than the instant the user actually reads the relevant item, will sit at a stale number. That quietly erodes trust in the signal. The clearing logic belongs next to whatever marks an item as read inside the application state. Not bolted on separately as an afterthought.

Combined with a light use of push notifications for genuinely time-sensitive events, a badge gives a progressive web app two distinct channels. One is for something that needs attention now. The other is a quiet, glanceable count that respects the difference between urgent and merely unread.

Testing badges properly means checking real devices rather than trusting a simulator. A simulator often renders a badge that never appears on the actual hardware a customer owns, especially on older phones running an outdated browser build. Syncing the count across a phone and a laptop where the same account is installed twice is worth checking as well, because a badge that only updates on one device quietly loses the trust it was meant to build.

Certain features push plain JavaScript past a comfortable performance ceiling. Image and video editing filters. On-device compression before an upload. Encryption of a file before it leaves the browser. A calculation engine handling a large spreadsheet of numbers. Run any of that directly in JavaScript on a mid-range phone and the interface stutters exactly when the user needs it to feel instant.

WebAssembly gives a progressive web app a second execution path for exactly that kind of work. Code written in a language such as Rust or C or C++ compiles down to a compact binary format. That format runs inside the browser at speeds close to a native application, sitting alongside the regular JavaScript that handles the interface. The two pieces talk to each other. JavaScript manages the screen. The compiled module does the heavy arithmetic or byte manipulation underneath it.

Nothing about adding WebAssembly changes what makes the app a progressive web app in the first place. The service worker still caches it for offline use. The manifest still controls installation. The compiled module ships as just another file the caching strategy already knows how to store. A user opening the app without a connection gets the same compute-heavy feature working offline, because the binary sits in the cache alongside the rest of the app.

Choosing what to move into WebAssembly is a narrower decision than it sounds. Moving the entire application into a compiled binary rarely pays off. The interface layer, the forms, and the navigation are usually fast enough in plain JavaScript already. Rewriting them adds engineering cost without a matching speed gain. The return sits specifically in the small number of functions doing genuinely heavy computation. Not in the surrounding application shell around them.

Loading a WebAssembly module has its own cost, and it needs to be weighed against the speed it buys. The binary has to download and compile before it can run. A module used on every page load needs to stay small. A module used rarely, such as an export tool touched once a session, can afford to be larger. It can load lazily, only when that specific feature is actually opened by someone.

Debugging compiled code is a genuinely different skill from debugging JavaScript. A team without prior exposure to it should budget time to learn the toolchain, rather than assume the transition is free. Source maps and browser developer tools now support stepping through the original source language in many cases. That closes most of the gap. But it remains a second toolchain running alongside the familiar one everyone already knows.

For most progressive web apps, WebAssembly never comes up at all. That is the correct outcome for a simple content site or a standard business tool. It becomes worth the conversation specifically when a feature involves the kind of work a spreadsheet, an image editor, or an encryption routine performs. Sustained, numeric, byte-level computation. Plain JavaScript was never built to make that fast.

Not every browser supports WebAssembly equally well, though support is now broad across modern engines. A sensible build checks for support first. Then it falls back to a slower JavaScript implementation of the same feature when the check fails. That fallback path rarely needs to match the compiled version on speed. It only needs to keep the feature working for the small number of visitors on an older browser, rather than breaking the page outright.

An installed progressive web app usually opens in its own window, separate from the browser. But a user can still end up with the same app running in two or three places at once. The installed window. A second copy opened from a bookmark. A tab shared by a colleague. Each of those windows can drift out of sync if nothing coordinates them.

The clearest failure shows up with offline data. Suppose two open windows both let a user edit the same record while the connection drops. Each window queues its own change for background sync, unaware the other window exists. When connectivity returns, both changes fire with no certainty about which one lands last. The user sees one window report success while the other quietly overwrites it minutes later.

A shared worker or a broadcast channel closes that gap. That is the point. Both are browser mechanisms. They let separate windows and tabs of the same app talk to each other directly, without a round trip through a server. One window can announce that it just changed a record. Every other open window updates its own view immediately, rather than each window trusting its own stale copy of the data.

The pattern that works well in practice treats one layer as the single source of truth. Usually the IndexedDB store the service worker already maintains. Every open window becomes a display of that layer, rather than an independent owner of it. A window writes a change to that shared store first, then broadcasts the change. It never lets its own in-memory state get ahead of what the store actually holds.

Conflicting writes still need a resolution rule. Coordination alone does not remove the case where two windows edit the same field within the same second. A last-write-wins rule, timestamped at the moment of the edit, is simple to build and works for most business tools. Anything where losing an edit silently is unacceptable, such as a shared document or a financial record, needs a visible conflict prompt. Not a rule that resolves the clash without telling anyone.

None of this coordination needs to run for an app used in a single tab by a single person at a time. That case is the norm. Adding shared worker logic to a product that never faces this scenario is unnecessary complexity. It matters specifically for collaborative tools and admin dashboards commonly left open in several browser windows. It also matters for any workflow where the same account is plausibly active in more than one place at once.

Testing this behavior deliberately catches problems that rarely surface in ordinary single-window use. Open the app in two windows side by side. Edit the same record in both. It is a small addition to a QA pass. It remains the most reliable way to confirm the coordination logic works before real users find the gap themselves.

Most business tools never need this level of coordination, and it is worth saying so plainly before a team spends a sprint building it. A single-user account accessed from one device at a time has nothing to synchronize. Only add this layer once real usage data, support tickets, or a specific customer requirement shows the multi-window case actually happens, rather than building it speculatively on the assumption that someone, somewhere, might one day open two tabs.