Tell us about your feature idea
The problem
PWABuilder currently generates packages for Android (TWA), Windows (MSIX), and iOS (Xcode project). macOS is the only major desktop platform with no generation support.
When a user installs a PWA on macOS via Safari's "Add to Dock" (macOS Sonoma+), the resulting web app always shows a persistent toolbar — back button, forward button, Share button, and any Safari extensions the user has installed. Apple hardcodes this toolbar into all Safari web apps and there is no manifest property, no CSS, and no JavaScript workaround that removes it.
When the same PWA is installed via Chrome or Edge on macOS, the window is completely chrome-free — just the app, identical to the Android TWA experience. But users have to know to use Chrome or Edge specifically, which is not intuitive.
The result is that Mac users get a noticeably worse experience than Windows, Android, and iOS users with no clear path to fix it unless a developer manually builds and distributes a native wrapper — which requires Xcode, an Apple Developer account ($99/year), code signing, and notarization.
Who this affects
Any PWA developer who wants a consistent full-screen app experience across all platforms. macOS is the only platform where the install experience is out of the developer's control and consistently worse than alternatives.
Do you have an implementation or a solution in mind?
Proposed solution
Add a macOS package generation option to PWABuilder alongside the existing Android, Windows, and iOS options.
The generated package would be a thin native macOS app — a WKWebView wrapper that opens the PWA URL full screen with no visible browser toolbar, similar to what Chrome and Edge already do when installing a PWA on macOS.
Technical approach
macOS already ships WKWebView on every machine. A minimal Swift or Objective-C app that:
- Creates a
WKWebView filling the entire window
- Loads the PWA's
start_url from the manifest
- Injects the manifest's
theme_color into the NSWindow title bar
- Sets the app name, bundle ID, and icon from the manifest
Would produce a .app bundle that:
- Opens full screen with no browser chrome
- Behaves identically to Chrome/Edge PWA install
- Can be distributed as a
.dmg for sideloading (same model as the Windows .msix)
- Uses the same icon and metadata already in the manifest
Precedent
The Windows MSIX generation already follows this exact model — a generated package that works for sideloading without requiring a paid Microsoft Store account. A macOS .app in a .dmg follows the same pattern. Users see a Gatekeeper warning on first open (same as Windows SmartScreen) but can proceed with right-click → Open.
For developers who have an Apple Developer account, the same package could optionally be signed and notarized to remove the Gatekeeper warning — similar to how the Android package uses the developer's own signing key.
Inputs needed from the manifest
name — app name and window titlestart_url — URL loaded in WKWebViewicons — converted to .icns for the app bundletheme_color — applied to the NSWindow title barbackground_color — splash screen backgroundid — used as the bundle identifier (com.yourapp.id)
Have you considered any alternatives?
Alternatives considered
1. Tell users to install via Chrome or Edge instead of Safari
Works today and gives the full-screen experience. Not a real solution — it requires users to know this and have a Chromium browser installed. Safari is the default browser on every Mac.
2. Electron
Generates a proper macOS app with no toolbar. Completely overkill — the generated .app would be 150MB+ just for the Chromium shell. Unacceptable for a website wrapper.
3. nativefier
Lighter Electron wrapper. Still 80–100MB, unmaintained, same problem.
4. Mac Catalyst
Requires an existing iOS app codebase to port. PWA developers don't have one. Not applicable.
5. Safari Add to Dock (current state)
Works but always shows the persistent toolbar. Apple has not provided any way to suppress it and has not indicated they plan to.
6. Tauri
Uses the system WebView (WKWebView on macOS). Could work but requires Rust toolchain setup and is aimed at developers building apps from scratch, not packaging existing PWAs.
The WKWebView thin wrapper approach is the only option that is lightweight, uses system components already on every Mac, follows the same pattern as the existing Android and Windows generators, and doesn't require the developer to install a large toolchain.
Tell us about your feature idea
The problem
PWABuilder currently generates packages for Android (TWA), Windows (MSIX), and iOS (Xcode project). macOS is the only major desktop platform with no generation support.
When a user installs a PWA on macOS via Safari's "Add to Dock" (macOS Sonoma+), the resulting web app always shows a persistent toolbar — back button, forward button, Share button, and any Safari extensions the user has installed. Apple hardcodes this toolbar into all Safari web apps and there is no manifest property, no CSS, and no JavaScript workaround that removes it.
When the same PWA is installed via Chrome or Edge on macOS, the window is completely chrome-free — just the app, identical to the Android TWA experience. But users have to know to use Chrome or Edge specifically, which is not intuitive.
The result is that Mac users get a noticeably worse experience than Windows, Android, and iOS users with no clear path to fix it unless a developer manually builds and distributes a native wrapper — which requires Xcode, an Apple Developer account ($99/year), code signing, and notarization.
Who this affects
Any PWA developer who wants a consistent full-screen app experience across all platforms. macOS is the only platform where the install experience is out of the developer's control and consistently worse than alternatives.
Do you have an implementation or a solution in mind?
Proposed solution
Add a macOS package generation option to PWABuilder alongside the existing Android, Windows, and iOS options.
The generated package would be a thin native macOS app — a
WKWebViewwrapper that opens the PWA URL full screen with no visible browser toolbar, similar to what Chrome and Edge already do when installing a PWA on macOS.Technical approach
macOS already ships
WKWebViewon every machine. A minimal Swift or Objective-C app that:WKWebViewfilling the entire windowstart_urlfrom the manifesttheme_colorinto theNSWindowtitle barWould produce a
.appbundle that:.dmgfor sideloading (same model as the Windows.msix)Precedent
The Windows MSIX generation already follows this exact model — a generated package that works for sideloading without requiring a paid Microsoft Store account. A macOS
.appin a.dmgfollows the same pattern. Users see a Gatekeeper warning on first open (same as Windows SmartScreen) but can proceed with right-click → Open.For developers who have an Apple Developer account, the same package could optionally be signed and notarized to remove the Gatekeeper warning — similar to how the Android package uses the developer's own signing key.
Inputs needed from the manifest
name— app name and window titlestart_url— URL loaded in WKWebViewicons— converted to.icnsfor the app bundletheme_color— applied to the NSWindow title barbackground_color— splash screen backgroundid— used as the bundle identifier (com.yourapp.id)Have you considered any alternatives?
Alternatives considered
1. Tell users to install via Chrome or Edge instead of Safari
Works today and gives the full-screen experience. Not a real solution — it requires users to know this and have a Chromium browser installed. Safari is the default browser on every Mac.
2. Electron
Generates a proper macOS app with no toolbar. Completely overkill — the generated
.appwould be 150MB+ just for the Chromium shell. Unacceptable for a website wrapper.3. nativefier
Lighter Electron wrapper. Still 80–100MB, unmaintained, same problem.
4. Mac Catalyst
Requires an existing iOS app codebase to port. PWA developers don't have one. Not applicable.
5. Safari Add to Dock (current state)
Works but always shows the persistent toolbar. Apple has not provided any way to suppress it and has not indicated they plan to.
6. Tauri
Uses the system WebView (WKWebView on macOS). Could work but requires Rust toolchain setup and is aimed at developers building apps from scratch, not packaging existing PWAs.
The WKWebView thin wrapper approach is the only option that is lightweight, uses system components already on every Mac, follows the same pattern as the existing Android and Windows generators, and doesn't require the developer to install a large toolchain.