Notion as a desktop app: how to decide what you need

Almost everyone approaches this the same way. Line up the options, read the differences, pick the best one. The official desktop client, Safari turning a page into a Dock web app, Chrome installing a page as an app, a general tool that wraps a URL into a standalone Mac application. Four columns, one decision.

That approach stalls, and it stalls for a structural reason. None of the four is better than the others in the abstract. Each one is better under a specific set of conditions, and the conditions belong to the reader, not to the tool. Comparing before the conditions are written down means reading a table with no idea which row applies. The faster route is to settle four requirements first, then let the remaining options narrow themselves.

Order the requirements by how much they narrow the field

Not all requirements carry the same weight. Some remove three options at once. Others only break a tie between two that were already close. Settling them in the wrong order wastes the effort, because a late hard requirement invalidates everything decided before it.

The four below are ordered by elimination power.

Offline reading comes first because it is binary and only one option satisfies it. If the answer is yes, the decision is largely made in one step. The sign-in path comes second because it can silently disqualify an entire category of tools, and it is the requirement people discover last, usually after installing something. Dock icon count comes third: it decides the shape of the result but rarely rules anything out completely. What else sits on the daily list comes fourth, and it matters more the longer that list is.

Working in this order usually produces a decision in a few minutes, because the first two questions often collapse the field to one or two candidates. Working in the reverse order produces a shortlist that then has to be thrown away.

One more thing is worth fixing before starting. These four requirements describe the current situation, not a permanent one. A new job adds a workspace. A company migrating to single sign-on changes the login path overnight. The point of writing the answers down is partly to make the next revision cheap, because the answers can be revisited one at a time instead of starting the comparison again.

Requirement one: reading with no network

The question is whether Notion has to open when there is no connection. Trains, flights, basements, sites with unreliable reception.

Notion's pricing page states that Notion can be used offline on the desktop and mobile app, that pages can be chosen for download, and that recents and favorites download automatically for offline use. This works because the desktop client keeps a local copy. Everything else on the list renders a live web page, so a dropped connection leaves an empty window. That is not a configuration problem and no setting fixes it.

This makes it the least negotiable of the four. If the answer is yes, the official client stays installed, and the rest of the decision is about what to add alongside it rather than what to replace it with.

The trap is answering from intention rather than from history. Plenty of people keep the official client because offline access might be needed someday, and then never open it without a network. A better test is a count. Over the last three months, how many times was Notion actually opened with no connection available. If the answer is zero, the requirement can be dropped, and dropping it opens up every remaining option. If the answer is several times a month, it is real and it takes precedence over everything below.

Requirement two: the sign-in path

This is the requirement that catches people after the fact, because it looks like an implementation detail until it blocks the first login attempt.

Notion accounts sign in by emailed code, by Google account, or through SAML single sign-on in organizations that use it. The Google case has a documented constraint.

Google might stop sign-ins from browsers that: Don't support JavaScript or have JavaScript turned off. Have unsecure or unsupported extensions added. Are being controlled through software automation rather than a human. Are embedded in a different application. Source: support.google.com

Google's developer guidance is consistent with that: OAuth authorization requests are not supposed to be directed at embedded user agents. A window that wraps a web page is, by construction, a different application containing a browser. So the Google sign-in button inside such a window is not a guaranteed path.

That does not rule the category out. It turns into two checks. Does the tool hand the sign-in step to the system browser and receive the result back. Can the Notion account fall back to the emailed code method instead. If either holds, the problem does not arise. If neither holds, that particular tool leaves the shortlist, and finding out now costs one test instead of a migration that has to be undone.

Organizations on single sign-on have a third check. The identity provider's domain is a separate host from Notion, so whatever handles the login has to follow that redirect and come back. Confirming this once, before anything is moved, is the cheapest step in the whole process.

Requirement three: how many Dock icons the setup should produce

The third requirement is about the unit, and there are three of them.

Service level means one icon for Notion as a whole. The official client is built for exactly this. It holds several accounts and workspaces inside one application and switches between them, and the Dock count stays at one no matter how many workspaces exist.

Workspace level means one icon per workspace, so that work and personal sit next to each other as separate applications. Page level goes further: a single database opened every morning gets its own icon, and it opens directly on that page. Both require an approach that creates an icon per URL, which is what the container approaches do.

The distinction that decides this is switching versus side by side. Switching means only one context is on screen at a time, and moving between them is an action taken deliberately. Side by side means both need to be open simultaneously, often in view at once. Someone who moves between contexts a few times a week is a switcher, and for them extra icons add steps rather than removing them. Someone who crosses between work and personal several times an hour needs them separated, and a single icon is the constraint that sent them looking in the first place.

A useful proxy: count the round trips made in the last working week. The number answers the question faster than reasoning about it does.

Requirement four: everything else on the daily list

The fourth requirement is the one most often skipped, because the search that led here named a single service.

Write out every URL opened on a normal working day. Then mark the ones that ship an official Mac client. Notion is in the marked group. Many internal tools, admin panels, dashboards, and smaller web services are not, and for those the only route to a Dock icon is a container of some kind.

The ratio decides the answer. If nearly everything is marked, installing official clients one by one is the simplest path and there is nothing more to solve. If most of the list is unmarked, a single mechanism that handles all of them is worth more than the sum of its parts, because creating, arranging, and removing them all work the same way. That consistency is invisible at one service and compounds steadily as the count rises.

There is a second reason to run this count. A service with no Mac client has exactly one route to a Dock icon, so the decision there is only about which container to use. Notion is in the harder group, where an official client already exists and the reason to look past it has to be something more specific than availability. Separated workspaces, a published page, or matching the way the other ten icons were made. Naming that reason out loud is what keeps the choice from drifting back to a preference argument.

The Supported services page is a quick way to see which side a given daily site falls on, since it lists services that already have Mac clients alongside ones that do not.

Putting the four answers together

With the four answers written down, the mapping is mechanical.

Answers so far	Where it points
Offline reading is needed	Official desktop client, kept regardless of everything else
One workspace, service level unit, no offline need	Official desktop client
Two or more workspaces open side by side	An approach that creates one app per URL
A published page that readers open without an account	An approach that creates one app per URL
Google sign-in, tool cannot pass login to the system browser	That tool leaves the shortlist
Six or more daily sites, most without a Mac client	One mechanism covering all of them

More than one row will usually apply. When they conflict, the offline row takes precedence, because it is the only capability on the list that nothing else can supply. Note also that the rows are not mutually exclusive in practice. The official client and a set of Dock web apps can both be installed and do not interfere with each other, so a common resolution is to keep the client for offline reading and add separate icons for the workspaces that need to sit side by side.

Three things to verify before moving over

Once a candidate is picked, three short tests are worth running before anything is migrated. Skipping them tends to produce a reversal about a week later.

The first is sign-in. Run the exact path identified in requirement two, once, all the way through to a loaded page. If it fails, the decision can be revised immediately rather than after everything has been rebuilt.

The second is link behavior. Following a link inside Notion can open the destination in the same window or hand it to the default browser, and both behaviors are defensible depending on the situation. What matters is knowing which one happens and whether it can be changed.

The third is notifications. macOS grants notification permission per application, so a page that produced alerts inside a browser does not automatically produce them inside a new app until permission is granted to that app. What a given tool exposes here is set out on the Features page, and the setup steps themselves are covered in the Guide.

What to change first

Write the four answers on one line before opening any comparison: offline yes or no, sign-in method, Dock unit, and how many other daily sites lack a Mac client. Those four usually leave one or two candidates standing, and Kagemusha is one way to build the per URL side once the requirements point there. Run the three verification tests on the survivor, then move.