PWAs on a Mac: how to decide what you need
Three routes show up in every search: save the page from Safari, install it from Chrome, or use software built for the job. Each comes with a list of pros and cons, and the lists are accurate. They still do not produce a decision, because pros and cons carry equal weight until conditions are applied to them.
The conditions are not the problem either. The order is. Applied in the wrong sequence, all three routes stay alive to the end and the choice comes down to a coin flip. Applied in the right sequence, most people are left with one option by the third question, and the remaining three questions only confirm it.
Why the order decides the outcome
Conditions fall into two groups. Some delete a route outright when answered, and some can be satisfied by any route. Icon artwork, the name typed into the dialog, and where the icon sits in the Dock are in the second group. The macOS version and the device management policy are in the first.
Starting with the second group is what produces the familiar stall: an hour spent comparing icon handling, followed by the discovery that the machine cannot run the software that won the comparison. Starting with the first group means every later question gets asked only about routes that are still standing.
The six below are ordered by how much they delete. Work down the list and stop when one option remains.
The two conditions that delete options
Condition one: the macOS version on the machine
Check it first, under the Apple menu, in About This Mac.
Starting with macOS Sonoma 14, you can use Safari to save any webpage as a web app, so that you can use it independently of Safari. Source: support.apple.com
The free route built into Safari begins at macOS 14. Dedicated wrapping software sets its own floor, and current generation products have started requiring macOS 15 or later. Anything older than 14 deletes the Safari route immediately and leaves the browser install route plus whatever older software still supports that release.
This condition also moves every year. Products that follow macOS releases eventually raise their minimum, so the useful version of this question is not just which release is running today but how many more releases this particular Mac is eligible to receive. On a machine that has stopped receiving updates, the set of available routes is now fixed permanently, which is worth knowing before paying for anything.
Condition two: who administers the Mac
On a company issued machine, installing software may simply not be permitted. That deletes the paid route and leaves whichever browser the organisation already allows.
Management policies reach further than the installer, and that is the part that catches people out. Extension installs can be blocked, notification behaviour can be set centrally, browser versions can be pinned, and a second browser may not be installable at all. Each of these removes part of a route rather than the whole route, so the failure shows up after the app is built, when something quietly does not work and the cause is three layers away.
Two ways to answer this in advance: install any small harmless app and see whether it completes, or ask whoever runs the fleet. Both take minutes. Skipping the question costs the whole evaluation.
The two conditions about scale
Condition three: how many sites are involved
One or two sites, and the built in free routes are usually enough. The work is small and there is nothing to keep track of afterwards.
Above roughly five, the deciding factor changes. What matters is whether all of them can be created the same way, listed in one place, and removed by one procedure. Free routes are built one at a time by hand, so by the fifth app the settings chosen for the first one are no longer remembered, and there is no inventory to consult.
Counting accurately matters here, because the number tends to come out inflated. Bookmarked sites and monthly visits do not count. The number that counts is sites opened on three or more days this week, and browser history answers it better than memory does. Most people land between four and eight. This is the point where many readers can stop, since a low count with no device restrictions makes the free route hard to argue against. What the paid route adds beyond that count is listed on the Features page.
Condition four: how many accounts per service
This one splits the two free routes apart, which is why it deserves its own question rather than being folded into the feature comparison.
An app created through Safari's Add to Dock keeps its own cookies and its own logins, separate from Safari and from every other web app. Two accounts for the same service can be two apps, permanently signed in, with no switching. Wrapping software behaves the same way.
An app installed from Chrome reuses the browser profile it was created in. Being signed in already is convenient on day one and blocking on the day a second account arrives, because separating them means creating a separate browser profile and rebuilding the app inside it.
There is a cost on the separated side as well. A separate cookie store means nothing is inherited, so each new app starts signed out. Three accounts is three sign ins on the first afternoon. Knowing how passwords are stored before starting keeps that from becoming the reason the project stalls.
Condition five: how the site actually gets used
For anyone still holding more than one option, usage shape settles it. Count for three days:
- Opened twenty times, ten seconds each, such as chat or a calendar
- Opened twice, thirty minutes each, such as an admin console or a writing tool
- Open continuously at the edge of the screen, such as a spec or a dictionary
Both free routes produce exactly one thing: a normal window. That fits the second pattern well. For the first pattern it means a chat window competing for the app switcher against the tool actually being used, twenty times a day. For the third it means repositioning a window by hand every morning.
Measuring this is easier than it sounds and harder to guess than it seems. Estimates of how often something gets opened are consistently wrong in both directions, usually low for chat and high for tools that feel important. Browser history with timestamps gives the real distribution in a couple of minutes, and three days is enough to see the pattern. The distinction that matters is not the raw count but the ratio between how often a site is opened and how long it is kept open, because that ratio is what a window shape is answering.
So the real content of this question is whether a menu bar shape or a sidebar shape is needed. If not, no option gets deleted here. If so, only the paid route provides it, and the step by step setup lives in the Guide.
Condition six: who maintains this next year
The question nobody asks, and the one that generates the most rework.
Every app created becomes something to revisit when macOS updates, when the browser underneath it updates, or when the site redesigns. For one person that is a small annoyance handled on the spot. For a setup that has to be reproduced on a second machine, or handed to a colleague, or rolled out to a team, it becomes a documentation problem. Free routes leave their configuration inside one Mac and nowhere else. Software that owns the list has something to hand over.
Removal procedures belong in this question too, since whoever inherits the setup needs to be able to undo it. Safari web apps are dragged to the Trash from the home Applications folder. Chrome installed apps are removed from the app window's own menu, with an option to delete their data at the same time. Apps made by a wrapper are removed from that tool's list. Purchase model matters here as well, one time versus monthly, and the Pricing page sets out the difference.
The six in one pass
| Order | Condition | The answer that deletes options |
|---|---|---|
| 1 | macOS version | Older than 14 |
| 2 | Who administers the Mac | Managed by an organisation |
| 3 | Number of sites | More than five |
| 4 | Accounts per service | Two or more |
| 5 | Usage shape | Frequent and short, or always visible |
| 6 | Maintenance next year | Anyone other than the person building it |
Write the six answers down rather than holding them in mind. A written list survives the days between deciding and doing, and it also makes the decision reviewable later, when something changes and the question comes back. Most of the time only one line has moved, and the rest of the work does not need repeating.
Nothing in the right column applies: the built in free routes are sufficient and nothing else needs evaluating. Two or more apply: look at the route that handles all of them in one place first, because the free routes will hit at least one wall.
When the conditions contradict each other
The common conflict looks like this. The Mac is current and unmanaged, there are eight sites, there are two accounts, and there is no budget.
Resolve it upward. The list is sorted by how much each condition deletes, so bending a higher condition to satisfy a lower one is what produces rework later. Budget sits second from the bottom by design, which means it is the constraint to revisit rather than the one to protect.
There is a legitimate middle path when the conflict is genuine rather than a preference. Take the two or three sites where the conditions actually bite, handle those one way, and leave the rest on the free route. A mixed setup is often treated as a failure of decision making, when in practice it reflects the fact that eight daily sites rarely share the same requirements. The cost of mixing is having two procedures to remember instead of one, which is acceptable at small numbers and stops being acceptable somewhere past ten.
For calibrating condition three and condition five together, a preset catalogue is a useful reference point. The Supported services page lists more than 300 of them, grouped into chat, AI, video and music, productivity, business and development, shopping and lifestyle. Mapping a personal list of daily sites onto those groups answers both questions at once: a list concentrated in one or two groups points to a single usage shape, and a list scattered across five points to a volume problem rather than a shape problem.
What to change first
Answer conditions one and two today, before reading another comparison. Both take minutes, both are checked rather than reasoned about, and either one can end the decision on its own. If both come back open, count sites by the three day rule and the third answer will usually finish it. The setup paths for each route are written out in the Kagemusha reference.
Frequently asked questions
Does the order really matter if the answer ends up the same?
The final answer is the same either way, but the time spent getting there is not. Conditions one and two can delete entire routes with a single check, so asking them first removes work. Questions that every route can satisfy, such as icon artwork or naming, cost nothing to leave until the end.
Where is the macOS version shown?
Open the Apple menu at the top left and choose About This Mac. Safari's Add to Dock is available from macOS 14 onward. Dedicated wrapping software sets its own minimum, and current generation products have moved to macOS 15 or later, so check both numbers before buying anything.
Is anything still possible on a company managed Mac?
Usually yes, through whichever browser the organisation already permits, since both Safari and Chrome can produce an app from a page without installing anything new. Policies can still restrict extensions, notifications or browser versions, so confirming with whoever manages the fleet before building is the safer sequence.
Do free and paid routes produce a different app?
The page being displayed is identical, so the content looks the same. The differences are around it: whether the window shape can be chosen, whether notification and camera permissions are handled per app, and whether logins are stored separately from the browser. Whether those differences matter is exactly what the six conditions determine.