When the official Mac build will not run and the web version still does
The pattern is familiar enough to be a genre. A download finishes, the disk image mounts, the application gets dragged to the Applications folder, and macOS refuses it with a message about the version required. Or the App Store listing simply shows nothing to click. Meanwhile the same service, opened at its web address in a browser on the same machine, loads and works.
That gap is not an accident and it is not a temporary bug. Native applications and web applications carry completely different minimum requirements, and the difference between the two is often several years of hardware. Knowing where each floor sits turns a frustrating afternoon into a decision that takes ten minutes.
The floor the native build sits on
WhatsApp states the requirement on its own download page: the Mac application requires macOS 12.1 or newer. The Windows application requires Windows 10 or newer, with the desktop documentation narrowing that to Windows 10 64-bit version 1903 and newer. Those are hard gates. A Mac running macOS 11 Big Sur or anything earlier will not install the current Mac build, regardless of how much memory it has or how well it otherwise performs.
Two distribution routes exist for the Mac application, the App Store listing and a direct download from the WhatsApp site, and both lead to the same build with the same floor. Trying the other route does not lower the requirement. Neither does an older installer found on a download aggregator, which additionally carries a real security problem, because messaging clients handle credentials and an unofficial binary is an unverified one.
This floor also moves. Requirements rise on a schedule set by the vendor, not by the user. The same pattern shows up across the desktop applications a Mac user is likely to rely on. The Mac App Store listing for Microsoft Outlook currently requires macOS 14.0 or later, and Microsoft supports the three most recent major macOS versions for Microsoft 365 for Mac, removing support for the oldest as each new one ships. Any machine that stays on one macOS version long enough will eventually watch its applications leave, one at a time.
The floor the web version sits on
The browser requirement is a different number entirely, and WhatsApp publishes it. WhatsApp Web is supported on Windows, Linux, and macOS, with these minimum browser versions: Chrome 85 or later, Edge 85 or later, Firefox 115 or later, Safari 15.2 or later, and Opera 85 or later. Calling is described as working best on those same five.
Notice what that list is measured in. It is browser versions, not operating system versions. That distinction is the entire reason the web version works where the application does not. A browser that a Mac can still update to will usually clear these numbers even on a system several releases behind, because browser vendors keep shipping to older macOS releases longer than most application vendors do, and because the extended support channels that Firefox maintains exist precisely for that situation.
The practical test takes one minute. Open the browser, check its version number in the About panel, and compare it to the five numbers above. If the installed browser clears the bar, the web version will run. If it does not, the question becomes which browser on that particular Mac can still be updated furthest, and that is a far more solvable problem than the macOS 12.1 gate.
Why a native build has a floor at all
The difference is worth understanding, because it explains why the gap will keep appearing with other applications.
A native Mac application is compiled against the frameworks that ship inside macOS. The moment a developer adopts an interface element, a notification behaviour, or a security capability introduced in a newer release, the resulting binary cannot load on systems that lack it. There is no graceful degradation at that level. The application either finds what it expects at launch or it refuses to start, which is why the requirement is published as a single version number rather than a list of features that might not work.
A web application is compiled against nothing on the machine. It runs inside a browser engine, and that engine arrives as its own package with its own runtime. Updating the browser updates the platform the service runs on, without touching macOS at all. The service therefore states its requirement as a browser version, because that is the only thing it depends on.
This is why the same Mac can be too old for one version of a service and perfectly current for another. It is also why keeping the browser updated is the highest value maintenance task on an ageing Mac. One update keeps a whole category of services reachable, while each native application has to be handled separately and eventually cannot be handled at all.
Working out what this Mac can still run
Three checks settle the situation completely.
The macOS version comes from the Apple menu, under About This Mac. Compare it directly to the published requirement. Anything at macOS 12.1 or above clears the WhatsApp gate, and anything below it does not.
Whether that can change comes from System Settings, under General and then Software Update. A Mac that is offered a newer macOS has a real path forward, and taking it usually restores more than one application at once. A Mac that is offered nothing has reached the end of Apple's supported upgrades for that model, and no amount of effort inside the App Store will change the outcome.
The browser version comes from the About panel in whichever browser is installed. That number is the one that decides whether the web version is available, and unlike the macOS version it can usually still be raised.
What the browser version actually gives up
The web version is not a stripped demonstration. WhatsApp describes WhatsApp Web as offering calling to contacts for free, including internationally, using the internet connection, along with keyboard shortcuts, chat folders, and pinned chats. Messages, media, groups, and file sharing all work.
The differences sit in a narrow band. The download page markets the Mac and Windows applications on calling, screen sharing, and a faster experience, and the desktop documentation adds a few items that live in the application: joining a group call after it has started, viewing call history, dragging and dropping files directly into a chat, and previewing and editing PDF files inside the client, a feature the documentation credits to Adobe Acrobat.
| Capability | Native Mac application | Browser version |
|---|---|---|
| Messages, media, groups | Yes | Yes |
| Voice and video calling | Yes | Yes |
| Screen sharing in a call | Listed as an application feature | Not listed |
| Drag and drop files into a chat | Yes | Limited to browser behaviour |
| PDF preview and editing in client | Yes | Not listed |
| Works with the phone offline | Yes | Yes |
| Minimum requirement | macOS 12.1 | Browser version, not macOS version |
For most daily use, the list of losses is short enough that the web version is a genuine substitute rather than a fallback. The cases where it genuinely hurts are screen sharing during calls and heavy file handling.
The linked device rules apply either way
Whichever route is taken, the same account rules govern it, and they surprise people who assume the browser version is somehow less connected.
An account can link up to four devices to the primary phone. The primary phone has to be logged in to WhatsApp at least once every fourteen days, or the linked devices lose their connection. Linked devices work without the phone being online, which is the change that made the desktop and browser versions genuinely useful rather than a mirror of a live phone.
One documented rough edge is worth knowing before blaming the browser for it. WhatsApp notes a known issue where some linked devices do not display up to one year of chat history, with the full history remaining visible on the primary phone. That is an account level behaviour, not something the native application fixes and the browser breaks.
Linking is done by opening the web address and scanning the code shown, using Linked devices on the phone. Unlinking can be done from either end, from the phone under Linked devices by selecting the device and logging out, or from the linked device itself.
Making the browser version stop feeling like a browser
If the web version clears the browser floor and covers the needed features, the remaining complaint is usually ergonomic rather than technical. The conversation lives in a tab. It disappears behind other tabs, alerts arrive only while the browser is running, and there is no icon to click or to reach with the application switcher.
Three routes close that gap, and they have different requirements themselves.
Chrome can install a page as an app from the More menu, under Cast, save, and share, then Install page as app, producing an icon and a window without a tab strip. The option is not offered for every page, and the resulting app belongs to the browser profile it was created from, so resetting that profile removes it.
Safari can do something similar with Add to Dock, available from the File menu or the Share button, and Apple describes the result as a web app that functions independently of Safari and shares no browsing history, cookies, website data, or settings with it. The catch is the requirement: this feature starts with macOS Sonoma 14, which is well above the macOS 12.1 gate that sent most readers here in the first place.
The third route is a tool that turns a website into a standalone Mac app, which builds a real application bundle with its own icon, its own isolated profile, and its own notifications, driven by a Chromium browser already installed on the machine. This route runs on macOS 12 and later, so it helps the reader whose Mac is new enough for a wrapper but who still prefers or needs the web version, and it does nothing for a Mac below that line. The Features page covers per app profile isolation, and the Guide walks through building one.
For a Mac genuinely older than macOS 12, the honest answer is that the browser is the destination, and the work worth doing is picking the browser that will keep updating on that machine the longest and pinning the tab.
What to change first
Check the browser version against the five numbers WhatsApp publishes, because that single check decides everything that follows. If the browser clears the bar and the Mac is on macOS 12 or later, build the web version into a standalone app with a site to app tool such as Kagemusha so it stops living in a tab. If the Mac sits below macOS 12, update the browser as far as that machine allows and treat the web version as the permanent client rather than a stopgap.
Frequently asked questions
What macOS version does the WhatsApp Mac app need?
The WhatsApp download page states that the Mac application requires macOS 12.1 or newer. Both the direct download and the App Store listing lead to the same build with the same requirement, so switching routes does not lower it. Older Macs need the browser version instead.
Which browsers work with the web version?
WhatsApp lists minimum versions of Chrome 85, Edge 85, Firefox 115, Safari 15.2, and Opera 85, on Windows, Linux, and macOS. Calling is described as working best on those same browsers. The requirement is stated as a browser version rather than an operating system version, which is why it clears on machines the native application rejects.
Can calls be made from the browser version?
Yes. WhatsApp describes WhatsApp Web as allowing free calls to contacts, including internationally, over the internet connection. Screen sharing during a call is listed among the reasons to install the Mac or Windows application rather than as a browser feature, so a call that needs a shared screen is better made from the application.
Does the phone need to stay online?
No. Linked devices work without the phone being online. The phone does need to be logged in to WhatsApp at least once every fourteen days, otherwise linked devices are disconnected and have to be linked again by scanning the code.
Why does older chat history not appear on the computer?
WhatsApp documents a known issue where some linked devices do not show up to one year of chat history, with the full history still visible on the primary phone. This applies to linked devices in general rather than to one client, so switching between the browser version and the native application does not resolve it.