Discord Mac app: what changes when macOS 12 support ends

The downloaded client is sitting in the Applications folder, the same server list is open in a browser tab, and every few months the same question comes back: is the installed app actually doing anything the tab does not. In 2026 that question has a date attached to it. Discord has been retiring older versions of macOS on a published schedule, and the version of macOS on the machine now decides which answers are even available.

The macOS floor is moving, and that is the news

Discord publishes a minimum operating system table and keeps it current. The desktop entries read like this.

Platform	Minimum
Windows	Windows 10 or later
Mac	macOS 12 or later (Monterey)
Linux	Ubuntu 20.04+ and Debian 11+, openSUSE 16.2+ and Fedora Linux 32+

That table is a snapshot of a line that keeps rising. Support for macOS 11 ended on June 15, 2026, and the next step is already dated.

As of September 17, 2026, Discord will no longer be supported on macOS 12. Source: support.discord.com

Two things follow from that sentence. The first is that a Mac running Monterey will keep launching Discord after the date, but the build it launches stops receiving updates, and Discord states plainly that functionality and stability are not guaranteed once updates stop. The second is that the fix Discord itself points at is not a different download.

Asked directly whether the browser version is an option for people who cannot upgrade, the same support article answers that it is, as long as the browser meets the minimum requirements. That turns the whole question around. On a Mac that Apple no longer updates, the browser client is not a downgrade to tolerate. It is the supported path, and the only remaining decision is what window to put it in.

What only the installed client can do

Three capabilities live in the desktop build and do not travel to a browser tab. Knowing which three keeps the decision honest.

The first is custom keybinds. Discord distinguishes between keyboard shortcuts, which work in both places, and custom keybinds, which do not.

Custom keybinds can only be used on the desktop version of Discord. Source: support.discord.com

This is the one that matters to anyone who talks while doing something else. Push to talk bound to a key that fires while a game or a design tool has focus is a custom keybind. In a browser tab, the key only reaches Discord when the tab is the active window, which is exactly when it is least needed.

The second is stream quality. Discord's screen share documentation notes that a stream started through a browser cannot have its quality adjusted, so resolution and frame rate stay wherever the browser lands.

The third is audio capture during a screen share, and this one is more specific than it first looks.

Currently audio can only be captured by the Windows desktop, MacOS desktop, Chrome browser, and mobile clients. You cannot share your application's audio on other browsers or Linux. Source: support.discord.com

Read that list again. Chrome is on it. Safari and Firefox are not. The engine underneath the window, not the fact that it is a browser, is what decides whether sound goes out with the picture.

What the browser client has that the client does not

The browser side of the ledger is short but it is not empty.

It runs where the client will not. Discord's browser minimums are Chrome 108 or later, Firefox 142 or later, Opera 72 or later, Edge 86 or later, and Safari 15.4 or later. A 2017 Mac stuck on an older macOS can still meet those numbers through a browser that keeps updating on its own schedule, long after the Discord installer has stopped accepting the machine.

It does not install a background updater, a helper, or an auto-launch entry. For a shared machine, a work laptop under management, or a Mac where the Applications folder is already a graveyard, that is a real difference rather than a philosophical one.

It also has a boundary worth knowing: Discord states that running Discord in a mobile browser is not supported. The browser route is a desktop route, and an iPad browser is not a substitute for the tablet app.

One more practical point sits behind the version numbers. A browser updates itself on its own cadence, independently of whether Discord's installer still accepts the operating system. That is why the browser floor and the client floor drift apart over the life of a machine, and why the gap widens rather than closes.

Checking what the machine can actually run

The decision takes about a minute to make concrete, and guessing at it produces the wrong answer often enough to be worth the minute.

Open the Apple menu and choose About This Mac. The number under the macOS name is the one that matters. macOS 13 or later means every option in this article is open, including the official client with full support. macOS 12 means the client works today and stops receiving updates after September 17, 2026. macOS 11 means the client is already unsupported, and Discord recommends staying on an older build that will keep running as long as nothing newer is installed over it.

Then check whether the Mac can move at all. Some machines are held on an old macOS by Apple's hardware support list rather than by choice, and no amount of patience changes that. Others are held there by one piece of software that has not been recompiled. In the first case the browser route is permanent and worth setting up properly. In the second it is a bridge, and a rough setup is fine.

The last thing to check is what Discord is actually used for on this machine. A Discord that is used for typing is a different problem from a Discord that is used for talking. Text, threads, file drops, and notifications all work identically in a browser. Voice works, but the controls around voice are where the desktop build keeps its advantages, and that is the line that decides whether the browser route is a fair trade or a compromise.

Four containers, side by side

Once the browser client is on the table, the choice is no longer app or tab. It is which container holds the web client, and the containers behave differently.

Container	Custom keybinds	Audio with screen share	Runs on macOS 11	Login separate from the browser
Official desktop client	Yes	Yes	No	Yes
A pinned tab in Chrome	No	Yes	Yes	No
Safari, Add to Dock	No	No	No	Yes
An app built on an installed Chromium browser	No	Depends on the engine chosen	Yes	Yes

Safari's Add to Dock is genuinely useful and genuinely isolated, since Apple documents that a web app shares no cookies or website data with Safari. It arrived in macOS Sonoma 14, which rules it out on exactly the older machines that need a browser route most, and Safari is not on Discord's audio capture list.

A pinned tab costs nothing and solves nothing. It stays inside the browser window, it disappears when the browser is quit, and Cmd+Tab does not reach it.

Putting the web client in a window of its own

The fourth row is the one that gets glossed over. A site to app tool of this kind does not bundle a second copy of Chromium the way a packaged desktop app does. It points at a Chromium browser already installed and builds an app bundle around a single URL, which means the app inherits that browser's engine, its codecs, its update cycle, and its extensions.

For Discord specifically, the engine choice is not cosmetic. Seven engines are supported, including Chrome, Chrome Canary, Chromium, Brave, Microsoft Edge, Vivaldi, and Opera, and the supported services list already pairs Discord's URL, icon, and app name so nothing has to be typed in by hand. Building the app on Chrome puts the window on the same engine Discord names for audio capture. Building it on a browser Discord does not list means accepting the same gap a tab in that browser would have.

What the window buys is the ordinary behavior of an application. It appears in Cmd+Tab, it holds a Dock position, Mission Control treats it as its own space rather than one tab among forty, and quitting the browser does not close it. What it does not buy is custom keybinds, because those are a property of the desktop build, not of the window frame. Anyone whose main reason for opening Discord is push to talk during a game should stay on the client and upgrade macOS instead.

Two Discord logins at the same time

There is one job the official client is not shaped for, and it comes up constantly for people who run a work community and a personal one.

Each app built this way gets its own browser profile. Two apps made from the same Discord URL hold two separate sessions, sitting side by side in the Dock with different icons, neither one signing the other out. Extensions are enabled per app as well, so a moderation helper can live in the community app without following the personal one around.

The same mechanism covers a narrower case that comes up in offices: a Discord that must stay logged in to a shared support account without touching the browser where everything else is signed in. Profile isolation, not a second browser install, is what makes that clean. The features list covers what carries over from the browser and what does not, and the tool is free for up to three apps, which is enough to test the arrangement before deciding anything.

Notifications survive the move, with one setup step. The web client asks for browser notification permission on first use, and granting it inside the app window registers the app rather than the browser, so alerts arrive with the app's own name attached and the Dock icon can carry a badge. Denying it once and forgetting is the usual reason a browser based Discord feels silent, and the fix is in macOS System Settings under Notifications rather than anywhere inside Discord.

What this does not fix

Being straight about the limits is more useful than a list of benefits, because the wrong expectation here wastes an afternoon.

An app built on a browser engine runs the web client, so everything that is missing from the web client is still missing. Custom keybinds do not appear. Stream quality controls do not appear. Automatic game detection, the status line that names whatever is running, belongs to the desktop build, because it depends on reading local processes that no browser page can see.

One item people expect to lose here was never on the table. Discord's in game overlay is documented as compatible with Windows only and does not function on macOS or Linux, so a Mac user comparing containers is not giving up an overlay by leaving the client. That removes the loudest objection and leaves a shorter, clearer list: keybinds, stream quality, and game status.

Nothing on that shorter list matters to a Discord used for work, a study group, a client community, or a hobby server that runs on text and the occasional call. All of it matters to a Discord used for gaming sessions with a headset on. The honest split is that gamers on a Mac that can take macOS 13 should upgrade and stay on the official client, and everyone else has a real choice to make about what window the web client lives in.

What to change first

Start from the macOS version, since it is the one variable that takes choices off the table rather than adding them. If it is 13 or later, keep the official client and stop thinking about it. If it is 11 or 12, move Discord to the web client now rather than in the week the updates stop, and give it a window of its own on the Chrome engine so it behaves like an app instead of a tab, which is what Kagemusha is built to do.