Desktop PWAs need a display override profile, not just standalone

Desktop PWAs compete with native apps for window management attention. When a PWA launches in a browser-without-branding frame, users compare it to the apps they already trust. The display_override manifest member is how PWAs evolve that comparison from "close enough" to "native-level."

Why this matters

The MDN Web App Manifest display_override member lets PWAs specify fallback display modes in priority order. The first supported mode becomes the effective display. This is critical for desktop PWA experiences because:

• Window Controls Overlay use display_override: ["window-controls-overlay"] to give web content the full window surface while overlaying maximize, minimize, and close controls. Without this entry, Chrome won't enable WCO even if your PWA is installed.
• Future display modes (like tabbed or custom) will only be accepted via display_override, not the legacy display member. The Chrome docs explicitly state that browsers won't consider display_override unless display is also present for backward compatibility.
• Desktop differentiation separates PWA profiles by target platform (desktop vs mobile). A mobile-first PWA might prioritize standalone on narrow screens but explicitly request WCO on desktop.

What display_override enables

The most significant OpenPWA use case is window-controls-overlay:

• Full-surface writing for productivity PWAs that want the cursor everywhere without a title bar using space.
• Immersive creative apps that control canvas layout themselves and treat window controls as an overlay to be styled around.
• Tailored experiences where the browser frame breaks the design (dashboard tools, kiosk interfaces, custom shells).

When enabled, WCO makes your PWA feel like a platform-specific app, not a web page in a window. That distinction drives retention—users keep apps that feel integrated with their OS workflow.

A display override checklist

Use this rubric to ship desktop PWAs that deliver native-app UX, not web-in-a-window:

• [ ] Backward compatibility: Always include a display: "standalone" member alongside display_override so older browsers fall back gracefully.
• [ ] Target specificity: Use display_override: ["window-controls-overlay"] only for desktop PWAs that explicitly design for the overlay experience.
• [ ] Mobile fallback: For PWAs that support desktop and mobile, consider two display strategies: mobile-first (standalone only) and desktop-first (standalone + WCO in override).
• [ ] CSS integration: When using WCO, add @media (display-mode: window-controls-overlay) queries and read the titlebar-area-x/y/height/width geometry from navigator.windowControlsOverlay so your layout adapts to the overlay position.
• [ ] Viewport management: Adjust viewport-fit and safe area insets so content doesn't render under window controls when WCO is active.
• [ ] Fallback testing: Verify that PWA features still work in standalone mode if you list window-controls-overlay as the first override option.
• [ ] Platform documentation: Document that WCO is a Chrome-specific display mode—Safari and Firefox may not support it, so your display_override fallback chain is critical.
• [ ] Identity consistency: Ensure that your WCO design doesn't break the "what app is this?" trust signal—icons, colors, and branding must still identify the app clearly without a title bar.

What this means for install decision

When users install a desktop PWA, they're deciding whether to place it alongside system apps in their window management workflow. If your PWA launches in a standalone-style window on desktop (with a title bar, frame, and OS-reserved controls) while competing native apps run in WCO mode, users notice the regression in space efficiency and integration. That's a post-install trust gap that storefronts and marketplaces surface in reviews.

From a marketplace review standpoint, desktop PWAs that target creative or productivity use cases should be evaluated on whether they've adopted display_override for WCO integration. A "desktop PWA" without WCO or a platform-specific display profile looks like a mobile web app repackaged for desktop by accident, not by design.

What to avoid

Don't add display_override: ["window-controls-overlay"] if your PWA doesn't read the WCO geometry or adapt its layout for the overlay. WCO with bad collision handling is worse than no WCO—users will lose UI elements under the window controls.

Next steps

Read the Chrome display override docs to understand the Window Controls Overlay API and the security considerations for full-surface web apps. Test your PWA in both standalone and window-controls-overlay modes before listing it in a desktop PWA marketplace.