Frontend interview: How would you design a Badging API fallback for unread PWA messages?

Prompt and scope

An installed PWA should show an unread count on its app icon. Explain capability detection, update and clear flows for the Badging API, and the fallback when a browser does not support it or the call fails.

What the interviewer evaluates

• Knowing that navigator.setAppBadge() and clearAppBadge() require a supported secure context.
• Distinguishing page and Service Worker WorkerNavigator capabilities and handling Promise failures.
• Treating the API as a presentation hint rather than the source of truth for unread data.
• Providing perceivable fallbacks such as title, in-app counts, and accessible status text while throttling updates.

Clarifying questions

1. Is the target an installed PWA icon or an ordinary browser tab?
2. What is authoritative for unread count, and how do refreshes and multiple tabs stay consistent?
3. Are offline updates, background push, and specific browser/OS combinations required?
4. How should screen-reader users receive the same state, and should counts be capped or redacted?

30-second answer framework

I would treat the badge as an optional presentation layer. In HTTPS, detect navigator.setAppBadge, update it from the synchronized unread count, check Promise failures, and call clearAppBadge at zero. If unsupported or failed, retain an in-app count, title or favicon indicator, and accessible status text. The page and Service Worker share one versioned count protocol, updates are throttled, and reading messages never depends on the badge.

Step-by-step deep dive

1. Define capability and display boundaries

The Badging API targets installed web-app icons; the 2026 W3C Working Draft exposes setAppBadge and clearAppBadge on Navigator and WorkerNavigator. It is a secure-context capability, and a user agent may omit it or change how a value is displayed, so exact cross-platform numbers cannot be promised.

2. Drive updates from authoritative unread data

Get a non-negative integer from the server or synchronization layer, cap and deduplicate it, then call navigator.setAppBadge(count). At zero, call clearAppBadge(); to show only a flag, omit the number. Handle every Promise rejection and log capability or error type, never message contents.

3. Design foreground and background paths

The page can update after a synchronization event; a Service Worker can use its corresponding worker capability for background events, subject to actual browser support. Both paths write the same versioned count so an old event cannot overwrite a newer value. On startup, resynchronize the authoritative count; the badge is not a database.

4. Handle failure and accessibility

If the capability is missing, the context is insecure, the PWA is not installed, or the call fails, retain the in-app list, navigation count, and document-title cue, plus readable text such as “3 unread messages.” Throttle aria-live announcements to changes. The badge must never be the only channel, and failure must not block reading or marking messages read.

High-quality sample answer

I would first confirm that the product targets an installed PWA icon rather than a normal tab. In an HTTPS page I would detect navigator.setAppBadge, drive it with a synchronized non-negative unread count, clear at zero, and catch Promise failures. The page and Service Worker would consume one versioned count and resynchronize on startup, preventing stale events from winning. Because support is limited and a platform may render a large value as a marker, I would keep in-app counts, title or favicon fallbacks, and throttled accessible status text. The badge is only a hint; its failure cannot block message reading.

Common mistakes

• Assuming every browser tab supports an exact numeric badge.
• Skipping HTTPS, installation, method-existence, or Promise-rejection checks.
• Using the badge as the only unread-data store, causing refresh and multi-device drift.
• Letting page and Service Worker maintain independent counts so stale events win.
• Offering only a color change with no title, in-app count, or accessible fallback.
• Calling the API for every message, causing churn, battery use, and needless updates.

Follow-up questions and answers

Why not update only the favicon?

A favicon affects tabs or bookmarks and cannot represent an installed app icon. Combine Badging API, favicon, title, and in-app count as capability-dependent presentation layers.

What happens if I pass 4000?

The user agent may compress a large value to 99+ or show only a marker. Cap the visual value and keep the exact count in the app.

How would you test the fallback?

Cover secure and insecure contexts, an uninstalled PWA, a missing method, Promise rejection, zero clearing, out-of-order background events, and screen-reader text; in every case verify that the message data flow still works.