Notion as a desktop app not working: what to check, in order

The setup worked on the day it was built. Then the window opens blank, or the sign-in screen refuses to move forward, or notifications that used to arrive in a browser tab stop arriving at all. The symptoms look similar enough that people try the same fixes on all of them: rebuild the app, reinstall, start over.

That is the slow route. The faster one is to identify which layer the failure lives in before touching anything, because each layer has a different set of checks and fixing the wrong layer changes nothing. This article sets out the four layers, the single test that separates them, and what to look at once the layer is known.

Four layers, and only one of them is the app

When a Notion window packaged as a Mac app misbehaves, the cause sits in one of four places.

The container layer is the app itself: how the window is built, where it stores the session, how it decides what to do with a link. The page layer is Notion, including outages and changes on the service side. The network layer covers dropped connections and corporate filtering that blocks specific traffic. The system layer is macOS, which controls whether the app is allowed to launch, post notifications, or reach files.

Two of these are new. Nobody thinks about launch approval or per app notification permission while a site lives in a browser tab, because the browser already holds those permissions and every site inside it inherits them. Splitting a site out into its own application splits the permissions out too. Something that worked in the browser and does not work in the new app is very often not broken at all. The permission simply has not been granted yet to this new thing.

That distinction matters for how the checks are ordered. Working outward to inward is faster: rule out the page and network layers first, then the system layer, then the container settings. Going the other way means adjusting settings that were never the problem, and each adjustment adds a variable that has to be undone later.

The first move is always the same

Whatever the symptom, start by opening the same URL the app points at in an ordinary browser tab.

If the symptom appears there too, the cause is the page layer or the network layer. No amount of container configuration will change it. What follows from there is checking whether Notion is having an incident, whether the network is filtering something, or whether the page itself has changed.

If the browser tab behaves normally and only the app misbehaves, the cause is the container layer or the system layer, and only now is there any reason to open a settings screen.

This test takes about thirty seconds and it is the one step people skip. Skipping it is expensive in a specific way. When the fault is on Notion's side, an hour of container troubleshooting produces no improvement, and the conclusion that tends to form is that packaging the site as an app was the mistake. The test prevents that conclusion from forming on bad evidence.

Check one more thing at the same moment: the exact URL the app was built from. An app built against a single page rather than a workspace entry point will show nothing at all if that page was deleted, archived, or moved. In that case the app is working correctly and the target is gone.

The window opens but nothing appears

A window that stays blank or sits on a loading state has several plausible causes, so the useful thing is an order rather than a list.

First, the app may have launched before the network was available. This happens right after a Mac starts or wakes from sleep, and quitting the app and opening it again clears it. It is routinely mistaken for a permanent failure because the first attempt of the day is the one that fails.

Second, the stored session may have expired. In that state, some containers show an empty view where a login screen should be. If the tool exposes a way to clear stored site data, that is the fix. If it does not, rebuilding the app is usually quicker than hunting for the cache.

Third, window width. Notion's layout responds to the available width, so a window kept very narrow can collapse its content into something that reads as empty. Widening it once settles the question.

Fourth, blocking software. Extensions installed in a browser do not carry over to a new app, but system wide blockers do apply to the new app, and a rule that never affected browsing can affect a single application's traffic. If several packaged apps fail at once, this is the candidate worth checking first.

Sign-in starts and never finishes

This is the most common failure of all, and part of it is documented behavior rather than a defect.

Notion accounts sign in with an emailed code, with a Google account, or through SAML single sign-on at organizations that use it. For the Google path, Google's own account help states that sign-ins may be stopped from browsers that are embedded in a different application. A window that wraps a web page is exactly that shape. Google's developer guidance points the same way: authorization requests are not meant to be directed at embedded user agents. So a Google button that does nothing is not necessarily a bug to be fixed. It can be the documented outcome.

There are two ways through. Either the tool hands the sign-in step to the system browser and takes the result back afterward, or the Notion account switches to the emailed code method, which has no such restriction. One of the two is usually available.

Single sign-on fails differently and needs its own check. The login leaves Notion's domain, authenticates at the identity provider's domain, then returns. A container configured to send anything outside its original URL to the default browser will break that return trip halfway through. The fix is to allow the navigation, or to add the identity provider's domain as an exception. Which controls exist varies by tool, so the Features page is the place to confirm what can be adjusted before assuming it cannot.

macOS refuses to launch the app

A double click that produces only a warning dialog has nothing to do with Notion or with the contents of the window. This is the system layer.

If you try to open an app that isn't registered with Apple by a known developer, you get a warning dialog. The app has not been reviewed, and macOS can't check whether the app has been modified or broken since it was released. Source: support.apple.com

Apple documents the override path through System Settings, Privacy and Security, then Security, then Open Anyway, followed by the login password. Apple also notes that the Open Anyway button is available for about an hour after the attempt to open the app. That detail explains a common confusion: going to look for the setting later and finding nothing there. Trying to open the app again makes the option reappear.

The more important part of that page is the warning attached to it. Apple states that overriding security settings to open an app is the most common way a Mac gets infected with malware, and advises against doing it for apps that have not been checked. The practical reading is that this dialog is a question about provenance, not a step in a setup guide. If a packaged app triggers it every time, the thing to examine is what built the app and whether that builder is registered as a known developer, since that determines whether the dialog appears at all.

Links open in the wrong place

Reported as a bug, this one is almost always a configuration boundary working as designed.

It shows up in two directions. A link to another Notion page opens in the default browser instead of staying in the app, which defeats the purpose of having the app. Or an outbound link to an unrelated site opens inside the app, leaving a window that was built for one job now showing something else entirely.

The container decides this, usually by comparing domains. Same domain as the original URL, keep it in the window. Different domain, hand it to the browser. The rule is simple and mostly correct, and Notion runs into its edges because shared links, attachments, and file previews can be served from hosts other than the main one.

What to look for is whether additional domains can be added to the keep it inside list, and whether outbound link handling can be switched. Some tools expose both, some expose neither, and in the latter case this behavior cannot be changed at all. The Guide covers where those controls live, which is worth reading before concluding that a setting does not exist.

Notifications never arrive

Alerts that used to appear from a browser tab stop appearing once the site becomes its own app. Given the layer model, this is predictable rather than surprising.

macOS manages notification permission per application. Permission granted to a browser does not transfer to a newly created app, so the new app starts from an ungranted state. The check is in System Settings under Notifications, looking for whether the app appears in the list at all.

There is a second gate. If the page uses web notifications, the site's own permission is required in addition to the system permission, and granting only one of the two produces silence. Both have to be in place.

Beyond that, tools differ in what happens while the app is closed. Some receive nothing until the app is running. Some stay resident. For anyone relying on Notion alerts during a working day, that difference is worth confirming before migrating rather than after. Apple's documentation on notification settings describes what can be controlled for each application.

Symptoms that are not defects

Some things survive every check above because they were never fixable. Recognizing them ends the search.

Symptom	What is actually happening	Fixable
Nothing renders with no connection	The window shows a live web page	No. Keep the official client for this
No tabs inside the app	Tabs belong to the official desktop client	No
Two apps share one logged in account	Session storage is shared between them	Depends on the tool
Large file attachments fail	Plan level upload limit	Not at the app layer
A Notion change appears immediately	A live page is never a version behind	Working as intended

The first row causes the most confusion. Notion's pricing page lists offline use as available on the desktop and mobile app, with pages selectable for download. A wrapper around a live page is outside that. A blank window with no network is the expected result, not a fault.

The attachment row is similar. Notion's published limits put file uploads on the Free plan at 5MB each, page history at 7 days, and external guests at 10. Those sit in the subscription layer, and changing how the page is opened does not move them. Tool cost and plan cost belong to different layers as well, which is why the Pricing page is read separately rather than added to a Notion invoice.

What to change first

Before adjusting any setting, open the same URL in a browser tab and note whether the symptom follows. That one result splits the four layers into two, and the remaining checks take minutes. If the fault turns out to sit in how the apps were built, rebuilding them consistently through one mechanism such as Kagemusha makes the next failure easier to isolate, because identical apps can be compared against each other.