When a service ships a desktop build and you still want the web one

Searching for a desktop build on a Mac usually ends the question. The application exists, it installs, it works, and the browser tab gets closed for good. For a smaller group the search ends differently: the desktop build installs, gets used for a week, and then quietly loses to the web version again.

That is not stubbornness. There are specific setups where the native application is the worse fit, and the reasons are structural rather than a matter of taste. Working out which group applies takes about five minutes and saves reinstalling the same application three times over the next year.

What the native build adds

Start with the honest list, because the desktop build is not a marketing exercise.

WhatsApp markets its Mac and Windows applications on calling, screen sharing, and a faster experience. The desktop documentation goes further and names the specifics: voice and video calls with up to thirty two people, call links that can be created and shared in advance, screen sharing during a video call, joining a group call after it has already started, and a visible call history. It also lists file handling improvements, including dragging and dropping files directly into a chat, and previewing and editing PDF files inside the client with drawing, highlighting, underlining, and strikethrough, a capability the documentation credits to Adobe Acrobat.

Beyond features, the application delivers notifications through macOS whether or not a browser is running, which is the single behaviour most people actually want from a desktop client. Status updates, Channels, and Communities are all present.

The requirement is macOS 12.1 or newer, stated on the download page. The application is available both from the App Store and as a direct download.

Nothing in that list is available in a weaker form in the browser. It is either there or it is not. Which makes the next question sharper: what does the web version have that the application does not?

The account limit that decides most cases

The strongest reason to stay on the web is not a feature. It is arithmetic about accounts.

WhatsApp does support two accounts on one device, but the documentation is explicit about where: multiple accounts require a separate phone number, secondary accounts can only be created from the primary mobile device, only mobile companion devices can switch between accounts, and the feature is not available on linked devices at all. Multiple accounts are currently supported on mobile devices only.

Translated to a Mac, that means one installed application equals one account, permanently. Anyone carrying a work number and a personal number, or managing a shared business line alongside their own, cannot solve it by installing the application twice, because macOS treats a second copy of the same bundle as the same application.

The browser solves it the way browsers solve everything, by keeping separate sessions in separate profiles. One profile holds the personal session, another holds the work session, and both stay linked simultaneously, within the limit of four linked devices per account. That limit is per account, so two accounts each get their own four.

This is also where the fourteen day rule matters. Each primary phone has to be logged in to WhatsApp at least once every fourteen days, or its linked devices disconnect. Two accounts means two phones to keep in mind, and a rarely used second number is the one that silently drops off.

Four other reasons the browser version keeps winning

Extensions. Password managers, translators, and content blockers operate inside a browser engine. The native application is a closed client, so none of them apply to it. For anyone whose workflow depends on a password manager filling credentials or a translator sitting on top of incoming messages, the native build removes a tool they use every day.

Machines where installing is not allowed. Managed laptops frequently block installing applications while leaving browsers untouched. In that environment the debate is already settled.

Update control. A native application updates on the vendor's schedule, and an update that changes a workflow arrives whether or not it was wanted. A web version also changes, but nothing needs to be installed, nothing requests permissions again, and nothing runs at login unless it is told to.

A smaller resident footprint. A desktop client installed for one service is a process that launches at login and stays running. Someone with six such clients has six of them, each holding memory, each checking for its own updates, each adding a few seconds to every login. The browser was going to be open anyway, so a seventh tab inside it costs far less than a seventh application. On a laptop that spends its day on battery, that difference is measurable rather than theoretical, and it grows with every service that decides to ship a desktop build.

Four linked devices is fewer than it sounds

The limit of four devices per account sounds generous until the slots are counted honestly, because every client occupies one whether or not it is used often.

A browser session counts as one. A standalone app built from a browser session counts as another, because it carries its own isolated session and has to be linked separately. The native Mac application counts as one. A tablet counts as one. A work computer and a home computer are two. Anyone running a browser session at the office, an app at home, and a tablet on the sofa has used three slots before adding anything deliberate.

When the fourth slot fills and a fifth device is linked, something has to give, and the device that drops is rarely the one expected. WhatsApp suggests checking linked devices regularly, which is done on the phone under Linked devices, where each entry can be selected and logged out. Logging out from the linked device itself works too.

The practical habit is to prune rather than to ration. A browser session linked once during a trip and never unlinked is a slot gone and a session left signed in on a machine that may not be yours any more.

What happens when both are installed

Running the native application and a browser session at the same time is allowed, and it is where a lot of low grade annoyance comes from.

Both are linked devices, so both receive every message. Both can raise a notification for the same message, which produces a double alert, one from the application and one from the browser, occasionally a second or two apart. Reading a conversation in one marks it read in the other, so the badge counts eventually agree, but not instantly, and the gap is long enough to be noticed.

The fix is not a setting hidden somewhere. It is a decision. Pick the client that will be the one on that Mac, and turn notifications off for the other in System Settings under Notifications, or unlink it entirely. Keeping both linked with alerts on is the configuration that makes people conclude the service itself is unreliable, when what they built was two clients competing for the same event.

What staying on the web actually costs

The costs are real and they are narrow.

Item	Native Mac build	Browser version
Messages, media, groups, files	Yes	Yes
Voice and video calls	Yes	Yes
Screen sharing during a call	Listed as an application feature	Not listed
Join a group call in progress	Yes	Not listed
PDF preview and editing in client	Yes	Not listed
Extensions such as password managers	No	Yes
Two accounts on one Mac	One account per install	One per profile
Alerts without the browser running	Yes	Only while running
Minimum requirement	macOS 12.1	Chrome 85, Edge 85, Firefox 115, Safari 15.2, Opera 85

The last row of the table is the one that usually gets ignored and should not. A browser version that lives in a tab delivers alerts only while that browser is open, and the browser being open is not the same as the tab being visible. That is the genuine weakness of the web route, and it is also the one that can be engineered away.

Keeping the web version without keeping the tab

Two routes give the web version a permanent home on a Mac, and they differ in an important way.

Browsers can install a page as an app. Chrome offers Install page as app under the More menu, in Cast, save, and share. Safari on macOS Sonoma and later offers Add to Dock from the File menu or the Share button, and Apple describes the result as a web app that runs independently of Safari and shares no browsing history, cookies, website data, or settings with it. Both produce an icon and a window with no tab strip, and both deliver notifications from that app rather than from the browser.

The limitation appears with the second account. A browser installed app belongs to the profile that created it, so building two of them from one profile produces two icons pointing at the same session. Safari's version has no profile separation at all and no extension support, which removes one of the main reasons for choosing the browser in the first place.

A tool that turns a website into a standalone Mac app takes the same idea further. Each generated app is a real application bundle with its own icon, its own isolated cookies and session, and its own notification permission, driven by a Chromium browser already installed on the machine. Because the profiles are isolated per app rather than per browser, two chat apps can sit side by side in the Dock, each permanently linked to a different number, and Chrome Web Store extensions such as a password manager keep working inside each one. The Features page describes how the isolation works, and the Supported services list covers the messaging and mail services that come already configured.

Where the native build is clearly the right answer

It is worth naming the cases where none of the above applies.

A single account, on a personal Mac, where calls are a daily tool and screen sharing during those calls matters, is exactly what the native application is built for. So is a workflow that involves receiving documents constantly, where in-client PDF review saves a round trip to another application. So is any situation where alerts must arrive whether or not anything else is running, with no configuration and no thought.

For that reader, installing the application and closing the tab is the correct end to the search, and the rest of this is noise.

What to change first

Count the accounts. One account with a need for calling and screen sharing means the native application, installed from the download page or the App Store, and nothing here changes that. Two accounts, or a dependency on browser extensions, means the web version is the right client, and the fix is to stop leaving it in a tab. Build it into a standalone app with a site to app tool such as Kagemusha, give each account its own icon, and let the alerts come from the app instead of the browser.