Linear Mac app: what installing it actually changes

Searching for the Linear Mac app usually happens at one of two moments. Either the tab keeps getting lost in a window of twenty others and something more permanent is wanted, or a notification arrived late and the desktop build looks like the fix. Both are reasonable. Neither is answered by the download button alone, because what the installer delivers is the same interface that runs in the browser, wrapped in a window of its own.

That is not a criticism. It is the shape of the product category, and knowing it changes what to expect after the install and what to do about the other seven tools sitting in the same browser window.

What the download gives you

Linear publishes desktop builds from its download page alongside the mobile apps. The page lists web, macOS, Windows, iOS, and Android. There is no Linux desktop build offered there.

The macOS download arrives as a disk image built as a universal binary, which means one file covers both Apple silicon and Intel machines with no version to choose. At the time of writing, that file is around 213 MB. The Windows installer at the same version is around 199 MB, which is a useful sanity check: the two are within a few percent of each other because both carry the same bundled engine.

That size is the whole story of what a desktop build of a web product is. The interface is the web app. The bulk of the download is the browser engine shipped alongside it so the app does not depend on whichever browser happens to be installed. Every product that ships a desktop build this way makes the same trade, which is why a Mac with eight of them has eight copies of nearly the same engine on disk and eight separate update cycles to maintain.

Version numbering is worth a glance for a different reason. The desktop build updates itself on its own schedule, independent of the browser and of the web app's own deploys. A stale desktop build is a thing that can happen. A stale tab is not.

What installing it actually changes

Four differences hold up in daily use, and they are the reason people install it.

A dedicated window that is not a tab. The app gets its own window, its own entry in Command-Tab, and its own tile in the Dock. Reaching it stops depending on finding the right tab in the right window of the browser.

Notifications that behave like an app. Linear's documentation is direct about the routes available:

For real-time alerts, you can use the Linear desktop app, mobile app, Slack, or email digests. Source: linear.app

A Dock badge for unread items. That badge is not automatic, and the documentation names the settings involved: notifications have to be enabled for Linear in macOS settings, with the red badge option turned on. When a badge fails to appear, that pair of settings is where to look before anything else.

The absence of a URL bar and tab strip. This matters more than it sounds. A window that cannot show another site is a window that cannot become a browsing session, and the tab that quietly turns into forty tabs is the actual failure being solved here.

What it does not change

The web app is the same web app. Keyboard shortcuts, layouts, and features come from the same code either way, so nothing new appears in the interface after installing.

Notifications in particular are not exclusive to the desktop build:

Desktop notifications are supported in both the Linear desktop app and supported web browsers. Source: linear.app

A tab that has been granted notification permission delivers the same alerts. If notifications were the only reason to install, the permission prompt in the browser is worth trying first, because it costs nothing and takes a few seconds.

The plan does not change either. Linear's pricing page lists a Free tier at zero cost with unlimited members, 2 teams, and a 250 issue limit, then Basic at $10 per user per month and Business at $16 per user per month when billed yearly, with Enterprise quoted separately. The desktop app is not a paid tier and does not lift any of those limits.

Offline behaviour is also not a feature the wrapper grants by itself. A web app that requires the network requires it inside a desktop window too, and a dropped connection produces the same failure in both places.

One more expectation worth resetting: installing does not reduce what the browser is doing. The browser stays open for everything else, so the memory and battery cost of the desktop build is added to it rather than moved from it.

Counting the cost per tool

The install decision looks obvious for a single product. It stops looking obvious once the same question is asked about everything else open in the browser.

	Official desktop build	Browser tab	Site turned into an app
Where it comes from	The vendor, per product	Already installed	Built locally from a URL
Disk cost per tool	Its own bundled engine, often 150 to 250 MB	None	Uses a browser already installed
Notifications	Yes	Yes, once permission is granted	Yes, once permission is granted
Dock tile and app switcher entry	Yes	No	Yes
Extensions	Whatever the vendor allows	The browser's own	The engine browser's own
Update path	Its own updater per app	The browser's	The engine browser's
Available for	Only products that ship one	Everything	Everything with a URL

The row that decides most cases is the last one. Linear ships a desktop build. Plenty of the tools beside it in the same browser window do not, and no amount of searching produces one. Internal admin panels, dashboards, small vendor portals, and regional services rarely have a Mac app at all, and those are frequently the ones that get lost in the tab strip.

That asymmetry is the practical argument for treating the problem as one problem rather than eleven. A tool that turns any URL into a standalone Mac app produces the same Dock tile and the same separate window for every tool, whether or not its vendor ever shipped one. Because the app runs on a Chromium browser already installed rather than shipping another copy of an engine, the disk cost of the eighth app is close to the cost of the first. The full list of services that come preconfigured is at Supported services, and the behaviour those apps get is described under Features.

The two account problem

One case comes up often enough with issue trackers to name it. Contractors, agency staff, and anyone helping a second organisation end up with two workspaces, and switching between them inside a single installed app means logging in and out or clicking through a switcher.

A browser solves this with profiles, at the cost of the tab problem returning. Two separate app containers solve it differently: each one holds its own session, so both workspaces stay signed in and both sit in the Dock under different names with different icons. The second is worth setting up before a busy week rather than during one, because the switching cost is small per instance and large in aggregate.

Naming deserves a moment here too. Two tiles both called Linear are two tiles that will be clicked wrongly. Giving each one the client or workspace name at creation time is a ten second decision that pays out every day afterwards, and it is visible in the Dock, in Command-Tab, in the force quit window, and in notification settings.

Reaching the window once it exists

Installing changes how the thing is retrieved, and the retrieval method is where the time is actually saved or lost. Three routes exist and they suit different habits.

Command-Tab orders applications by how recently they were used, so a tracker checked every few minutes usually sits one or two positions away. This is the fastest route for something in constant rotation, and the slowest for something opened at 9am and again at 4pm, because by then it has drifted to the end of a long list.

Spotlight is the opposite. Typing the first few letters of the app name reaches it in the same number of keystrokes whether it was used a minute ago or last Tuesday. Consistency is its whole advantage, and it is the reason the name given at install time matters: a distinctive name reaches the app in three characters, while a generic one collides with documents, folders, and other apps in the results.

The Dock is the third route, and it is the one that survives a break in concentration. A tile in a fixed position can be hit without reading anything, which is not true of a list that reorders itself. Placing the tile at the end of the Dock rather than the middle shortens the pointer travel, and the icon becomes recognisable at a glance only if it is visually distinct from its neighbours.

Worth noting: none of these three can reach a browser tab. A tab has no entry in the app switcher, no Spotlight result, and no Dock tile. Every tab is found by looking at the tab strip and reading titles, which is why the same site takes longer to reach than any installed app, no matter how good the browser's own shortcuts are. That gap, rather than any feature inside the product, is what a desktop window is actually buying.

When the tab is the right answer

Installing is not automatically correct, and there are cases where it adds friction.

Occasional use is one. A tool touched twice a month does not need a permanent tile, a background updater, and 200 MB of disk. A bookmark is the proportionate answer.

Heavy cross referencing is another. Work that constantly moves between the tracker, a spec document, and a pull request is work that benefits from those things being tabs in one window, where a single keystroke moves between them. Pulling one of the three into a separate window can make that flow worse, not better.

A managed Mac is a third. Where installation of applications is restricted, the browser route is the one that works, and it delivers notifications and a bookmarkable URL without asking anyone for permission.

The honest test is whether the tool is entered deliberately every working day. Deliberate and daily justifies a tile. Anything else does not.

What to change first

Try the browser notification permission before installing anything, since it takes seconds and settles the most common reason people go looking for the desktop build. If a permanent window is genuinely wanted, install the official build for the products that publish one, then decide what to do about the tools that never will: Kagemusha gives those the same Dock tile and separate window without a separate engine per app.