A separate place for work chat on a Mac

Searching for a WhatsApp desktop app for Mac usually ends quickly, because one exists and it is free. The longer question starts after it is installed. Work conversations now sit in the same window as family photos, and the other services that carry work chat, the ones with no Mac app at all, are still buried in a browser tab somewhere behind eleven others. Installing one app solved one tenth of the problem it was supposed to solve.

This article covers both halves. The first half is what the official app is and what accepting it commits a Mac to. The second half is what to do about every chat service that never shipped a Mac app, because the same fix applies to all of them at once.

The official app exists, and that part is settled

WhatsApp publishes a Mac application. It is listed on the download page alongside the Windows, Android, iOS and iPad builds, and the stated requirement is macOS 12.1 or newer. The same app is on the Mac App Store, where the listing gives a download size of 399.9 MB and the price as free.

Desktop Mac. Get calling, screen sharing and faster experience with the Mac app. Requires macOS 12.1 or newer. Source: whatsapp.com

Two details in that sentence decide whether the app is worth installing over the browser version. Calling and screen sharing are named as things the app has, which places them outside the browser route. And the version floor is macOS 12.1, which is high enough to exclude a Mac that has been kept on Big Sur or earlier for compatibility reasons. On those machines the browser is not a preference, it is the only route.

The download page also lists the browser option by name, WhatsApp Web, described as what to use when a device is not supported. That framing is accurate. The browser version is the fallback, not the flagship. It is also the version that any site to app tool works with, which matters later.

For a Mac running macOS 12.1 or newer with no other chat services in play, install the official app and stop reading. The rest of this is for the case where that is not the whole picture.

What linking a device commits a Mac to

Every desktop or browser copy of WhatsApp is a linked device, not an independent login. The phone stays the account holder. Two published limits follow from that, and both are worth knowing before building a workflow on top.

The first is the count. WhatsApp's help centre states that one primary phone can link up to four devices at a time. A Mac at the office, a Mac at home, an iPad and a work laptop reaches the ceiling, and adding a fifth means unlinking something.

The second is the renewal window:

You'll need to log in to WhatsApp on your primary phone every 14 days to keep linked devices connected to your WhatsApp account. Source: faq.whatsapp.com

For a phone in daily use this is invisible. For a second work phone that spends most of its life in a drawer, it is a recurring failure that looks like a bug on the Mac. The fix is always on the phone.

The help centre also carries a standing notice that some linked devices may not display up to one year of chat history, with the full history remaining on the primary phone. Searching an old thread from the Mac is therefore not guaranteed to find it. That one limitation is the strongest argument for keeping the phone within reach rather than treating the Mac as a complete replacement.

None of this changes between the official app and the browser version. Both are linked devices and both inherit the same rules, so the choice between them is not about account behaviour.

The services that never shipped a Mac app

WhatsApp is the easy case because it has an app. Most of the other places work conversations happen do not.

A typical week runs through some combination of a group chat, a shared inbox, a project board, a support queue and a client's own portal. Some of those have Mac applications. Plenty do not, and never will, because building and maintaining a native client for every platform is expensive and the browser already works.

The result is predictable. One chat service gets a Dock icon and a window of its own. The rest stay as tabs, and tabs behave differently from windows in three ways that matter:

• A tab has no entry in the Command Tab switcher, so reaching it means reaching the browser first, then finding the tab.
• A tab shows unread counts in the page title, which is truncated to a few characters in a crowded tab strip.
• A tab is one accidental Command W away from being closed, and reopening it means signing in again if the session was short lived.

Installing the WhatsApp app fixes those three problems for exactly one service. The interesting question is whether the same three can be fixed for the others without waiting for each company to ship an app.

There is a fourth effect that is easy to miss. A browser holds one signed in session per service per profile. The moment a second account on the same service enters the picture, a personal address and a work address on the same chat platform, the browser forces a choice between signing out repeatedly and maintaining a second profile. Neither is a workflow. Both are a tax paid several times a day.

Four routes to a chat service in its own window

The routes differ in what they cost, what they require of the service, and what they leave behind.

Route	Works for	Requires	Separate Dock icon
Official Mac app	Only services that publish one	macOS 12.1 or newer for WhatsApp	Yes
Browser tab	Any service with a web version	Nothing	No
Safari web app	Any site, macOS Sonoma 14 or newer	Safari as the engine	Yes
Site to app tool	Any site with a web version	A tool, usually paid	Yes

Safari's built in route is the one most people have and do not use. Since macOS Sonoma 14, File then Add to Dock turns the current page into a standalone web app. Apple's documentation is specific about how separate the result is:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

That separation is the feature. A work account signed in inside a web app stays signed in there and does not collide with a personal account signed into the same service in Safari. For anyone juggling two accounts on one service, this alone is worth the two minutes.

The limits of the Safari route are equally clear. It is Safari's engine, so a service that only supports a different engine will not cooperate. Chrome extensions do not exist on this path. Web apps do not sync between Macs, so a second machine means repeating the work. And every app is built by hand, one page at a time, with the name and icon typed in each time.

Deciding which conversations earn a window

Turning everything into an app produces a Dock as crowded as the tab strip it replaced. A rule keeps the count honest.

A service earns its own window when it is opened first thing and stays open all day. Anything opened once a week does not, and is better reached through Spotlight or a bookmark.

Applied to chat specifically, that usually produces a short list. The place where work conversations happen earns a window. The place where personal conversations happen earns a window, or deliberately does not, if the point is to keep it out of the working day. A client portal that is checked twice a month does not.

The second question is accounts. A single service used with two accounts is the strongest case for a separate window, because the alternative is signing out and back in, or running a second browser profile and remembering which is which. Two windows with two names under two icons removes the question entirely.

The third question is notifications. A window with its own Dock icon can carry an unread badge on that icon, which is either the reason to keep it visible or the reason to close it. Deciding that per service, rather than per app, is how a Dock stays readable.

Naming is the part that gets skipped and then costs time daily. Whatever name is typed when the window is created becomes the label under the Dock icon, the entry in the Command Tab switcher, and the string that has to be typed into Spotlight to reach it. Three windows whose names all begin with the same word produce three near identical rows in every one of those places. Splitting the first two characters, by putting the purpose or the account first rather than the service, is the cheapest speed improvement available here.

What a dedicated tool adds over the built in route

Once the list runs past two or three services, the manual route starts to show its cost. A tool that turns a website into a standalone Mac app exists to remove that cost, and the differences are concrete rather than cosmetic.

Presets are the first. Instead of opening each site, typing a name and hunting for an icon, the service is picked from a list that already has the correct URL, name and artwork. More than 300 services ship as prepared presets, and the catalogue itself is informative: the list on Supported services leans heavily toward tools that stay open all day, which is a reasonable proxy for what other people found worth pulling out of the tab strip.

Engine choice is the second. A service that only supports one browser engine is not a dead end when the engine is selectable.

Behaviour around external links is the third. A chat window is full of links to other places, and whether those open inside the window or hand off to the default browser changes how usable the window is. Control over that is the difference between a window that stays focused and one that turns back into a browser within a week. The rest of what separates the two routes is set out on Features, with the build steps on the Guide.

What to change first

Install the official Mac app if the machine runs macOS 12.1 or newer, since it is free and it covers one service properly. Then take the second chat service, the one with no Mac app, and give it a window using Safari's Add to Dock. Run both for a week, and if the list of services that deserve the same treatment keeps growing, Kagemusha does the remaining ones from presets instead of by hand.