PWAs on a Mac: the setup order that holds up

Turning a website into a standalone app on a Mac takes about fifteen seconds. Keeping it is the part that goes wrong. Most people build one, use it for a week, then rebuild it because the name is awkward to type, or it opens the wrong account, or a login link kicks them back into the browser and never returns. None of those are bugs. They are all consequences of decisions that were made silently at the moment the app was created. The order below puts those decisions in front of the click instead of behind it.

The qualifying question, before the four decisions

Not every site is worth a container, and building one for a site that does not need it is how Docks fill up with icons nobody presses. Three signals separate the sites that repay the effort from the ones that do not.

How many times a day does the site get reopened rather than stayed on. A site opened once in the morning and left running until evening benefits enormously. A site visited twice a week does not, and a bookmark handles it better.

Should notifications from the site arrive while the browser is closed. If yes, this is the strongest single argument for a standalone container, because no browser tab can do it.

Does mixing this site with everything else cause real damage. A personal shop and a production admin console sharing a window is a different risk from two reference pages sharing one.

A site matching two of the three is worth the fifteen minutes. A site matching one is usually better served by a pinned tab. Running this filter first keeps the Dock legible, which is the entire reason for starting.

Four decisions that belong before the first click

These are ordered because the later ones depend on the earlier ones. Deciding the name before deciding the account, for example, tends to produce two apps called the same thing.

Which browser owns the app

A standalone web app built by a browser runs on that browser's machinery for the rest of its life. There is no way to move the app to a different engine later. Three questions settle it.

Does the site render correctly and quickly in that browser. Internal admin panels and older business systems often behave in exactly one browser, which closes the question immediately.

Are notifications part of the point. A web app created through Safari on macOS supports web push and badging, so unread counts appear as a red badge on the Dock icon. If the reason for building the app is to stop missing messages, this matters more than anything else on the list.

Is an extension doing real work on that site. Translation, form filling, clipping, ad filtering. An extension that lives in the browser does not follow the site into a standalone window in the same shape, so the browser that carries the extension is the browser that has to build the app.

Firefox is not an option here. The site specific browser feature it once prototyped was only ever reachable through a hidden preference, and it was removed in version 86. There is no stated plan to bring desktop installation back, so a Firefox user is choosing between Safari, a Chromium browser, and a separate wrapper tool.

Which account is signed in at the moment of creation

This is the single largest cause of rebuilds, and it is almost never mentioned in step by step guides.

When a site is added to the Dock from Safari, that site's cookies are copied into the new app at the moment of creation. The app opens already signed in, which feels like magic on day one. The copy happens once. After that the app and the browser share nothing: no history, no cookies, no website data, no settings. Signing out in the browser does not sign out the app. Signing in inside the app does not reach the browser.

The practical consequence is a sequence. Sign in to the work account in the browser, build the work app. Switch accounts in the browser, build the personal app. Reverse that order, or forget the switch, and the result is two icons that open the same identity.

Chromium browsers bind the app to the profile it was created from rather than to a snapshot of cookies. The effect at the Dock is similar: whichever profile was active becomes the app's identity. Check which profile is in front before starting.

What the app is called

The name is not decoration. A created app lands in the Applications folder inside the home folder, which means Spotlight indexes it, which means the first two or three letters of the name become a keystroke that gets typed several times a day.

Two rules keep that keystroke short. Avoid the full official product name, because long names are harder to distinguish in a results list. And when two apps exist for the same service, put the distinguishing characters at the front rather than the back, so that one keypress separates them instead of six.

The name is requested during creation. Renaming the file afterwards in the Finder is possible, but Dock position and any assigned keyboard shortcut do not always follow, which is why the name belongs in the decision list rather than in a cleanup pass.

How far the app is allowed to roam

Clicking a link inside a standalone web app either stays inside it or hands off to the default browser, depending on whether the destination falls inside the app's scope. Since macOS Sequoia, a link that matches the scope of an installed web app opens in that app rather than in the default browser, which is the behaviour most people expect and rarely get by accident.

The failure case is authentication that routes through a second domain. Single sign on portals and third party account providers sit outside the scope, so the browser takes over partway through, finishes the login there, and leaves the app where it was. Sites built this way are still worth installing, but they should be created from an already authenticated session so that the round trip happens as rarely as possible. That is the fourth decision leaning on the second one.

The Safari route

Open the site and navigate all the way to the screen that gets looked at first every morning. Not the marketing homepage, not the account root. An inbox, a board filtered to one project, a dashboard. Whatever is on screen at the moment of creation becomes the app's starting point.

From the menu bar choose File, then Add to Dock. The Share button in the toolbar offers the same item. Type the name that was decided earlier, adjust the icon if the option appears, and confirm.

The app is written into the Applications folder inside the home folder, not the system wide one at the root of the disk. Removing it later means opening the home folder, opening Applications, and dragging the app to the Trash. Knowing which of the two Applications folders holds it saves a confusing search a month later.

The Chromium route

In Chrome the item now sits under the menu entry for casting, saving and sharing, and reads as an instruction to install the page as an app. It used to live under the tools submenu with a different label, so older walkthroughs send readers to a menu that no longer contains it. Some sites also surface an install control at the right edge of the address bar.

Installed apps land in the home Applications folder inside a folder named for the browser that made them. A Mac with several Chromium browsers ends up with several of these folders side by side, one per browser, each holding lookalike icons. Deciding which browser is the owner, as in the first decision above, prevents that pile from forming.

The full list of installed apps is reachable at the browser's internal apps page, and uninstalling from inside the app window offers to clear the site data along with it.

	Safari	Chromium browsers	Firefox
Where the app is stored	Applications folder in the home folder	Browser named folder inside the same place	Nothing is created
Identity at creation	Cookies copied once	Bound to the active profile	Not applicable
Site without a manifest	Still becomes an app	Still becomes an app	Not applicable
Removal	Drag to the Trash	Uninstall from the app menu	Not applicable

The five minute check right after creation

Skipping this is why people discover problems on the morning they actually needed the app.

Close the new app and reopen it from the Dock. If a login screen appears, the account state at creation time was not what it seemed, and the fastest fix is to rebuild rather than to investigate.

Turn on notifications inside the site and wait for one to arrive. Confirm that a badge appears on the Dock icon. Notification behaviour can also be adjusted per app, so this is the moment to find that setting rather than during a busy week.

Click one link of the kind that gets clicked daily. Watching whether it stays inside the window or jumps to the browser removes the surprise later.

Type the name into Spotlight. If the app is not the first result after two or three characters, change the name now, while rebuilding costs nothing.

Pin the icon in the Dock. A freshly created app often disappears from the Dock the next time it closes unless it has been explicitly kept there.

Duplicate containers are the usual mess

The second most common complaint after unexpected logouts is a Dock holding two icons that look the same and behave differently. It has three causes, and all three are avoidable at creation time.

The first is building the same site in two browsers while comparing them, then keeping both. Only one can be the owner, and the loser should be deleted the same day rather than left as a backup that slowly becomes indistinguishable from the winner.

The second is building twice from the same account by accident, usually because the account switch in the middle was skipped. The two containers then differ only in name, and finding out which is which means opening both.

The third is renaming in the Finder instead of rebuilding. The file gets a new name while the Dock entry and any assigned keyboard shortcut keep pointing at the old identity, so the desk ends up with one app and two mental models of it.

A monthly pass through the Applications folder inside the home folder catches all three in about a minute. Anything that cannot be identified by its name in two seconds is a candidate for deletion, because an app nobody can identify is an app nobody opens.

When rebuilding beats repairing

Four situations are faster to redo than to fix. A different account is needed alongside the first one. The owning browser is being replaced. The name turned out to be awkward to type. The screen that matters has moved, so the app opens to the wrong place every time.

In all four the app is a thin container holding a decision, and decisions are cheaper to replace than to edit. Delete the old one from the home Applications folder in the same pass, otherwise two near identical icons start competing in Spotlight.

What to change first

Pick one site: the tab opened first thing in the morning and never closed. Walk it through the four decisions, build it, run the five minute check, and use it for a week before adding a second. The categories that reward this treatment most are visible in the supported services list, and the settings worth knowing about before building are collected under features and in the guide. For anyone who would rather not hand each app a separate browser and a separate profile to keep track of, a dedicated tool such as Kagemusha makes those four decisions explicit fields instead of side effects.