PWAs on a Mac alternatives: what you can drop

The search for an alternative almost always starts the same way. A site that gets opened twenty times a day should be an app, the address bar shows no install icon, the Safari menu has nothing that looks right, or the Mac is managed and a second browser is not an option. The usual response is to go looking for a different tool, which is the wrong move, because the blocker is rarely the tool.

The word PWA bundles five separate capabilities into one label. Four of them can be obtained in several ways. One of them cannot be obtained at all unless the site itself provides it. Splitting the label is what makes the substitute obvious, and it is also what stops a week of evaluating products that were never going to help.

The five things the label is holding together

Pulled apart, a progressive web app on a desktop is offering these:

• A standalone window with a Dock icon, separate from browser tabs
• Content that still renders when the connection drops
• Notifications and an unread badge on the icon
• Cookies and logins stored separately from the browser
• The ability to receive files, or to handle a particular type of link

Most people who go looking for an alternative want the first one, sometimes the third, occasionally the fourth. The second is the one that gets assumed and almost never checked, and it is the only one on the list that no external tool can supply.

Only one of the five depends on the site

Installability is not a property of the Mac or the browser alone. It rests on a file the site publishes.

As a minimum requirement for installability, most browsers that support it use the Web App Manifest file and certain properties such as the name of the app. Source: web.dev

Offline rendering rests on something further still: code the site registers to serve its own content when the network is gone. A site that never shipped that code will never render offline, no matter what the page is wrapped in. This is the single most useful fact in the whole decision, because it removes an entire category of products from consideration in about ten seconds.

Everything else on the list is supplied by whatever is doing the wrapping. A standalone window, a Dock icon, a notification permission, a separate cookie jar: all of these belong to the container, not to the site. That is why substitutes exist at all.

Naming the complaint before naming the product

Picking a substitute goes faster when the complaint is written down as a physical action rather than a feeling. "Hard to find" is not a specification. "Two browser windows are open and the tab gets found by reading left to right" is, and it points straight at the first capability.

The same translation works for the rest of the list. "Replies are late" becomes "the tab was checked at noon and two hours of messages were sitting there", which is the third capability. "Constant switching" becomes "signing out of one account and into the other twice a day", which is the fourth. "Cannot work on the train" becomes the second, and that one ends the search early.

Written this way, most people find they need exactly one capability, sometimes two. The products being compared all supply four out of five, which is why comparison tables feel unhelpful until the complaint is specific. Once it is specific, most of the table stops mattering.

Route one: Add to Dock in Safari

Since macOS Sonoma 14, Safari can save any open page as a web app through File > Add to Dock, or through the Share button. The result lands in the Applications folder inside the home folder, and it opens without Safari being in the picture.

The important behaviour is the storage boundary.

It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

Read that twice, because it cuts both ways. A second account for the same service can stay permanently signed in alongside the first, which solves a real problem for anyone running a work login and a personal login. It also means the new app opens signed out on day one, and every stored password has to come across again.

What is adjustable: the name and URL, the icon, whether the navigation controls appear in the toolbar, whether the title bar picks up the site's colour, and which Safari extensions are active inside that particular app. Notifications produce a red unread badge on the Dock icon, but the permission has to be answered inside the web app. Answering it in Safari does nothing for the app. Removal is a drag to the Trash from the home Applications folder.

What is not available: any window shape other than a normal one. There is no menu bar mode and no sidebar mode. Note also that this mechanism is not the standards based install described above, and documentation written from the standards side still lists Safari on macOS as not supporting installability. Two different mechanisms, one shared English phrase.

Route two: Install page as app in Chrome

Google documents the path as the three dot menu, then Cast, save, and share, then Install page as app. Installed apps are listed at chrome://apps, can be set to launch automatically at sign in, and are removed from the app window's own menu, with an option to delete the associated data at the same time.

The storage boundary is the opposite of Safari's. An app installed this way keeps using the browser profile it came from. Already signed in inside the browser means already signed in inside the app, which is convenient right up until the goal is a second account, at which point a whole separate browser profile has to be created and the app rebuilt inside it.

On disk, these land in a dedicated folder inside the shared Applications folder rather than in the home folder, which is worth knowing when a Dock icon needs replacing or an app has to be found without going through the browser. The chrome://apps listing is the reliable inventory: anything installed shows up there, including apps created months ago and forgotten.

Two more properties matter over time. The app's name and icon come from what the site publishes, so a name too long to read in the Dock cannot be shortened from the app side. And the app is not a standalone program: it runs on the browser underneath it. Remove that browser, or have it version pinned by a device management policy, and the app follows.

Route three: a tool built for wrapping

The third route is software whose entire job is turning sites into Mac apps. It costs money where the first two do not, so it is worth being precise about which of the five capabilities it adds.

It adds window shapes. A normal window, a menu bar window that drops down and retracts, a sidebar window pinned to the edge of the screen. It adds per app permission handling, so notifications, camera, microphone and location get answered once per site rather than once per browser. It adds a separate cookie store per app, so accounts stay apart without touching browser profiles. A list of what that covers sits on the Features page.

Window shape is the one that changes a working day rather than a settings screen. A chat app opened twenty times for ten seconds each does not belong in the same app switcher queue as the tool actually being worked in. Neither free route can produce anything except a normal window, so this is the gap the money is closing.

There is a maintenance dimension too. Apps made through the free routes exist only as settings inside one particular Mac, which is fine for one person and awkward the moment the same setup has to reach a second machine or a colleague. A tool that owns the list of apps has somewhere to keep that configuration, and something to hand over when the question comes back a year later.

It does not add offline rendering. Nothing does, except the site.

Route four: stop building an app at all

Sometimes the honest answer to the first capability is that the real goal was never a separate window. It was reaching the page without hunting for it.

A Dock bookmark, a Spotlight query, or a keyboard shortcut assigned through the Shortcuts app all deliver that in one action. All three open a browser tab, so the window is not separate, the cookies are shared with the browser, and notifications follow browser wide settings. One capability out of five, at zero cost and zero maintenance.

The name given to the bookmark or the app decides how fast this route feels. Spotlight matches on the first characters typed, so a name chosen for how it will be typed beats a name copied from the site's own branding. Three characters that nothing else on the Mac starts with is the practical target.

For a site opened twice a day, with one account and no notification requirement, that trade is often correct. Every app created is also an app to revisit when macOS updates, when the browser updates, or when the site changes its layout. Owning fewer things is a defensible outcome.

What survives each route

Capability	Safari Add to Dock	Chrome install	Wrapper tool	Bookmark or shortcut
Standalone window and Dock icon	Yes	Yes	Yes	No
Offline rendering	Site dependent	Site dependent	Site dependent	Site dependent
Notifications and badge	Yes	Yes	Yes	Browser wide
Separate login storage	Yes	Shared with profile	Yes	Shared with browser
Window shape options	Normal only	Normal only	Three shapes	None
Cost	Free	Free	Paid	Free

Reading across a row rather than down a column is what makes this table useful. Pick the row that describes the actual complaint, then take the cheapest column that says yes.

Two things shift the answer away from the free columns: the number of sites involved, and whether window shape matters. A tool that ships presets is worth a look once the count climbs, and the Supported services page lists more than 300 of them across chat, AI, video and music, productivity, business and development, shopping and lifestyle. A large share of those sites publish no manifest at all, which is the clearest signal that wanting a site as an app and a site being installable are separate questions. Cost structures for the paid column differ between one time purchase and monthly, and the Pricing page lays out that difference.

What to change first

Open the site in Chrome and look for an install icon in the address bar. If it appears, the site publishes a manifest and the only remaining question is which of the five capabilities is actually needed. If it does not, offline rendering is off the table permanently, and the choice narrows to which container gives the best window and storage behaviour for the number of sites in play. The setup routes for the paid column are written out in the Kagemusha guide.