Gmail desktop app on a Mac: four meanings, four answers

Search for a Gmail desktop app and the results split immediately, because the thing being searched for was never released. Google has no installer for Gmail on macOS or on Windows. What exists is a website, a set of browsers that Google supports it in, and several ways to give that website an application shape. The reason the results feel contradictory is that the phrase covers four different wants, and no single route satisfies all four. Sorting the wants first turns a confusing search into a short decision.

The starting fact: Gmail is distributed as a website

Google's supported browsers page for Gmail names Chrome, Firefox, Safari and Microsoft Edge, notes that Gmail works best in the newest and last prior version of those browsers, and adds that any browser used needs cookies and JavaScript turned on. Nowhere on that page is there a download. The page is the product surface. That is the whole story on the vendor side.

This matters more than it sounds, because it sets what any route can and cannot inherit. Every feature that lives inside the Gmail interface, from the layout of the inbox to add-ons installed into it, comes along only if the route keeps that interface. A different mail client connects to the account, not to the interface, so it shows the messages and leaves the interface behind.

Apple Mail is the obvious example. It is installed with macOS, costs nothing extra, and holds a Google account alongside other accounts. What it does not do is render Gmail's own screen. For a reader whose habits are built on filters, labels and keyboard behaviour inside that screen, switching clients is not a packaging change. It is a different program with a different model of what mail is.

There is a second consequence, less obvious and more annoying in practice. Because the vendor ships no application, nothing on the Mac knows that mail is an app. It has no icon, it cannot be the default handler for anything, and it does not appear anywhere the operating system lists programs. Every route below is really an attempt to create that missing registration, and they differ mostly in who creates it and how much of the browser comes with it.

So the first fork is not about apps at all. It is whether the Gmail interface has to survive. If the answer is yes, every remaining option is a window pointed at mail.google.com, and the question becomes which window.

Meaning one: an icon, and a place in the application switcher

The most common want behind the search is small and specific. The reader has a browser holding twenty tabs, mail is one of them, and getting to mail means finding the browser, then finding the window, then finding the tab. Three steps, forty times a day.

Both Safari and Chrome answer this without any third party involved. In Safari, File and then Add to Dock saves the current page as a web app. Apple documents this as available starting with macOS Sonoma 14, and states that the web app is saved to the Applications folder of the home folder, reachable from the Dock or Spotlight. In Chrome, the equivalent lives under the More menu, then Cast, save, and share, then Install page as app.

The result in both cases is a window with its own Dock icon and its own entry in the application switcher, which means Command and Tab reaches it directly. That is the entire benefit, and for many readers it is enough. It is worth being clear about what it is not. It is not a global hotkey. macOS does allow custom shortcuts to be assigned to menu commands, under System Settings, Keyboard, Keyboard Shortcuts, App Shortcuts, and Apple notes there that some apps may not allow shortcuts to be set at all. A website in a tab has no menu commands of its own to bind. An app made from that website at least has an application to point at.

Meaning two: mail that still opens without a network

The second want is stricter, and it is the one that eliminates most routes. Google's own instructions for offline Gmail are unusually specific about the conditions.

You can only use Gmail offline in a Chrome browser window that isn't in Incognito mode. Source: support.google.com

Four further conditions sit in the same page and are easy to miss. Offline Gmail works only with the account that was signed in at setup, so a second account has to be enabled separately by signing into it and repeating the steps. Messages sync only while Chrome is open, so quitting the browser stops the sync that the offline copy depends on. A message sent while offline lands in an Outbox and goes out when the connection returns. Attachments can be downloaded and opened in a local application, but not previewed.

The storage note is the one that surprises people who assume a desktop app means a local archive of everything.

When offline, Gmail only uses the space available to your browser. It's a fraction of your computer's total storage. Source: support.google.com

Read together, these conditions point at one family of routes. Anything built on Chromium keeps the browser storage that the offline copy lives in. Anything built on Safari falls outside the condition Google states. A reader who flies often, or works from trains, should treat this section as the deciding one and stop comparing on looks.

Meaning three: being told about mail without hunting for the tab

The third want is notifications, and here the official documentation quietly reveals which platform it was written for. Google's page on Gmail notifications says notifications arrive in Chrome, Firefox or Safari after signing in and opening Gmail in the browser. It then adds that on Windows 10, notifications show up outside the browser, and that Chrome notifications should be turned on in the Windows Action Center.

Two things follow for a Mac. The first is that the equivalent control is not the Action Center but System Settings and then Notifications, which is why step lists copied from Windows guides dead end. The second is more structural: notifications depend on the thing being open. A browser tab that has been closed sends nothing. This is the quiet reason people describe the tab route as unreliable, when the actual behaviour is exactly as documented.

An app made from the website changes the shape of this. Apple's description of Safari web apps notes that for websites that send notifications, the web app's icon in the Dock can show the number of unread notifications, and that the web app then appears in the Notifications settings list under its own name rather than the website's URL. That last detail is worth more than it looks. A settings list full of URLs is unmanageable. A list of named apps can be tuned per app, including which ones are allowed through a Focus.

Meaning four: two accounts open at the same time

The fourth want comes from anyone holding a personal address and a work address. In a single browser, one Gmail session is foreground and the other is a switch away, which is fine until a link opens in the wrong account.

Apple's documentation of Safari web apps is direct about the separation:

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

This is why a newly created Safari web app asks for a login even though the browser was already signed in, a behaviour that reads as a bug and is the documented design. It also means two web apps built from the same address can hold two different accounts, permanently, without switching.

Chrome reaches the same place by a different mechanism. Sessions belong to profiles, so an installed app inherits the account of the profile it was created in. That works, and it has an edge: the profile picker and the app windows are easy to confuse once several exist, because the windows look identical. Naming each app for the account rather than the service is the practical fix, and both Safari web apps and purpose built wrappers allow the name and icon to be set at creation.

The routes, side by side

	Apple Mail	Tab in a browser	Safari web app	Chrome installed app	Purpose built app
Shows Gmail's own interface	No	Yes	Yes	Yes	Yes
Meets Google's stated offline condition	Not applicable	Only in Chrome	No	Yes	Depends on the base browser
Own switcher and Dock entry	Yes	No	Yes	Yes	Yes
Separate sign in from the browser	Yes	No	Yes	Per profile	Per app
Name and icon set by the user	Not applicable	Not applicable	Yes	Limited	Yes
macOS floor	Ships with macOS	macOS 13 for Chrome	macOS 14	macOS 13 for Chrome	Depends on the base browser

Reading the table by column rather than by row is what makes it useful. No column is filled in. The browser tab column is the only one that is free of setup and the only one with two clear gaps. Apple Mail is the only column that stops showing Gmail's own screen, which is either the point or the disqualifier depending on the reader. The three window based columns differ far less from each other than the marketing around them suggests, and the differences that remain are the offline row and the macOS floor.

The bottom row is the one that ends arguments on older hardware. Chrome's published requirement on Mac is macOS 13 Ventura or later, while Safari web apps start at macOS Sonoma 14. A Mac sitting on Ventura has the Chrome routes and not the Safari one.

What is worth packaging beyond mail

Once the four wants are separated, the same test applies to everything else open in the browser all day. The list of presets on the supported services page is a useful mirror of what people actually keep open: mail, chat, boards, admin screens and the AI assistants. What they share is not category but rhythm. They are opened many times a day, stay open a long time, and gain nothing from sitting beside unrelated tabs.

Mail scores high on that test, which is exactly why it is the most searched case. The more interesting result is that internal tools score higher still. A payroll console, a ticket queue, a client dashboard: none of these will ever ship a Mac app, and each is opened as often as mail. The features page and the pricing page are the right places to check whether a route covers a whole set of these rather than one address, because the cost of the decision is per person, not per site.

What to change first

Pick the want, not the tool. If the need is only an icon and a switcher entry, use what is already installed and stop there. If offline mail or a permanently separate second account is the need, choose the route that meets that condition and let everything else follow from it. Once the same shell has to cover the other sites open all day, the setup steps are laid out in the Kagemusha guide and the edge cases in the FAQ.