Notion as a desktop app: the setup order that holds up

The mechanical part of turning Notion into a Mac app takes about two minutes. Almost all of the time people lose goes to the part that happens afterwards, when something turns out to have been decided wrong and the whole thing gets built again.

Most instructions cover the two minutes and skip the decisions. This one goes the other way. Four things need settling before anything is created, and they are presented here in order of how hard each one is to change later. Settle them in that order and rebuilding stops happening.

The order is cost of reversal, not order of operation

The four decisions, ranked by what it takes to undo them:

• Which URL the app points at
• Which account it is signed into
• What it is named and which icon it carries
• Whether it is allowed to send notifications

Getting the first two wrong usually means starting over. The third is changeable but costs a relearned habit. The fourth is a toggle that can be flipped at any time, forever.

Notice that this is close to the inverse of how the process usually gets described. Typical instructions open with the install click and never mention URL selection at all, which is the one choice that is effectively permanent.

So the first work session involves creating nothing. It involves answering four questions. Once they are answered, the build is the easy part.

First decision: which URL

An app is permanently bound to the address it was built with. Every launch goes there, which makes this the decision that defines what the app is for. With Notion there are three reasonable targets.

The workspace entry point. Opens with the sidebar, suited to browsing and searching rather than going somewhere specific.

A particular page or database view. If the same task board gets opened every morning, pointing directly at it means the board is on screen the instant the app opens. This is the shortest path available. It is also the most fragile, because moving or rebuilding that page changes its URL.

A published page URL. For a handbook, a client manual, or anything read by people without Notion accounts, this is the only option that works.

Two published documented behaviors matter here. Notion states that the slug of a published page, meaning the part of the URL after the domain, can be customized on paid plans using letters, numbers, and hyphens up to 60 characters. And there is this:

Once you permanently delete a published page, its slug cannot be reused. If you think you might want to use the same slug again, update the slug before deleting the page. Source: notion.com

That reverses the sequence for published targets. The URL has to be finalized on the Notion side before the app exists, not after. While in there, confirm scope as well: publishing a page publishes its subpages along with it.

Second decision: which account

The second question is which signed in state the app carries. It ranks this high because changing it later means signing in again at best, and rebuilding at worst.

This only requires thought when more than one Notion account is in use. Work and personal, or an internal workspace alongside a client's. Keeping both as separate icons requires a method where the sessions are actually separate, and not all methods do that.

Apps created through a browser feature inherit that browser profile's session. Two accounts on the same service cannot both stay signed in, because signing into one replaces the other. Separate browser profiles solve it and introduce profile management as a new thing to maintain.

Some general purpose site to app tools give each generated app its own storage, which allows two accounts on one service to stay signed in simultaneously. Whether a given tool does this varies, so when multiple accounts are part of the requirement, this is the item to verify before building rather than after. The Features page sets out where that line falls.

Deciding how removal works belongs here too. Chrome's uninstall flow offers a separate option to also delete the app's data from Chrome, and notes that choosing it means signing in again on the next visit to that site. Knowing that in advance prevents the surprise of an experimental app being removed and taking a browser session with it.

With a single account, none of this applies. Every method produces the same result, and this decision can be answered in a sentence and moved past.

Third decision: name and icon

The name looks cosmetic and is actually about retrieval, because it is what gets typed into Spotlight or scanned in the application switcher.

Two workspaces both named Notion are indistinguishable at the moment of searching. Including a word that identifies the purpose means three or four keystrokes narrow it down. This never matters while arranging icons and always matters while looking for one.

For Chrome created apps there is a documented behavior worth knowing. Chrome notifies when a web app wants to change its displayed name or icon, offering update, ignore, or uninstall, and advises uninstalling if the change looks like an attempt to impersonate a different app. Names and icons are therefore not entirely frozen after creation.

Nothing here forces a rebuild. Renaming is cheap in mechanical terms and not free in habit terms, which is the argument for deciding once rather than adjusting three times.

Fourth decision: notifications

Notifications come last because they can be changed at any point with no consequence.

The decision itself is binary: should this app be permitted to interrupt. Grant macOS permission or do not, and reverse it later if the choice was wrong.

One realistic caveat. Wanting notifications is not sufficient, because the site has to implement them. Notifications and icon badges are extra features present in some web apps rather than a guaranteed property of any container. A site that sends nothing in a browser tab today will send nothing after being wrapped, so checking in a tab first saves the disappointment.

There is a scale effect too. One app with notifications enabled is unremarkable. Ten apps all permitted to interrupt recreates, in the Dock, exactly the attention problem that leaving browser tabs was meant to solve. Granting permission selectively produces a better outcome than granting it by default.

The setting that is easiest to miss

There is a fifth item that does not rank as a decision because it is usually a toggle, and that gets skipped for exactly that reason: what happens when a link leaves Notion.

Notion pages are full of outbound links. Shared documents, ticket references, vendor dashboards, articles someone dropped into a meeting note. Clicking one inside a wrapped app either opens it in that same frame or hands it to the default browser, and which behavior applies depends on the tool.

Keeping everything in the frame sounds tidy and produces an odd result in practice. An app built to be Notion ends up displaying an unrelated site, with no address bar to navigate back and no tab to close. Recovery means quitting and relaunching, which is a small annoyance repeated often.

Handing links off to the browser is the behavior that matches the intent of the exercise. The app stays a single purpose window, and the browser goes back to being the place where arbitrary web pages open. If a tool exposes this as an option, it is worth setting deliberately on the first build rather than discovering it three weeks later.

The same logic applies to authentication popups, which are technically outbound windows too. A sign in flow that opens a secondary window has to be allowed to do so, and a container configured to block extra windows will appear to simply do nothing when the sign in button is pressed. Testing one login immediately after building surfaces this in seconds.

What each decision costs to reverse

Decision	Reversible	What reversing costs
Which URL	Effectively no	Rebuild the app
Which account	Depends on method	Sign in again, or rebuild
App name	Yes	Relearn how to summon it
Icon	Yes	Adjust visual memory
Notification permission	Yes	Flip a setting
Window size	Yes	Opens at the new size next time

Only the top two rows are heavy. Everything else is a preference that can be revised on a whim. Knowing the shape of this table is what stops people spending half an hour on an icon and ninety seconds on a URL, which is the usual distribution and exactly backwards.

A practical consequence follows from that ranking. The two heavy rows should be tested rather than assumed. Paste the chosen URL into a fresh browser window and confirm it lands on the intended screen, with the intended account, without any redirect. If it bounces to a workspace home or prompts for a login, the address is not yet final, and building on top of it just moves the problem into an icon.

The build itself is just knowing the entry point

With the four decisions made, creating the app is a matter of knowing where the command lives.

In Chrome, the documented path is to open the site, select the More icon at the top right, then Cast, save, and share, then Install page as app. Some sites surface an Install control at the right of the address bar instead. Afterwards these can be managed at chrome://apps, where right clicking an app also allows setting it to open at login.

For the official Notion client, the download page lists macOS Universal, macOS Apple Silicon, and macOS Intel x64 builds, with Notion Calendar offered as a separate macOS download and the Web Clipper offered as a Chrome extension. Only the needed pieces get installed.

For a general purpose tool, the URL decided earlier gets entered and an application is produced. This is where the preparation pays off: with the address, the account, and the name already settled, there is nothing left to think about at the input field. Arriving unprepared means deciding all three simultaneously, which is where most attempts stall.

Two checks belong in the first minute after the icon appears, because both are cheap now and expensive later. Open the app once and confirm it lands on the intended page rather than a workspace home, since a redirect at this stage means the address was never final. Then press one outbound link and watch where it goes, which settles the link behaviour question without reading any documentation. Anything wrong at this point costs a rebuild of well under a minute.

One thing is worth doing immediately after creation. Resize the window to the size it will actually be used at. Notion's layout responds to width, so establishing that once means every subsequent launch looks the same.

What to change first

Choose the one Notion screen that gets opened every single day, copy its URL, and build exactly one app from it. Leave it alone for two weeks, and count two things: how often it got opened from the Dock instead of a browser tab, and how often something inside it failed and sent the work back to a browser. If the first number is high and the second is near zero, the same four decisions apply to the rest of the list, and the Guide covers extending it with Kagemusha.