Keeping Gmail open all day on a Mac without a mail client

Gmail is open somewhere in the browser right now, pinned, three windows back, behind a spreadsheet and a documentation page. It has been open since morning. Finding it again takes a Mission Control swipe and a squint at eleven favicons that all look like each other at that size. Searching for a mac os gmail client is usually what happens next, and the search results split into two very different answers that get presented as if they were the same thing.

One answer is a native Mac email program that connects to the Gmail account and shows the mail in its own interface. The other answer is Gmail itself, unchanged, living outside the browser in a window with its own Dock icon. Those two answers solve different problems, and picking the wrong one costs a week of relearning habits before the mistake becomes obvious.

The two questions hiding inside one search

The first question is about the interface. Gmail's web interface has labels instead of folders, conversation threading that cannot be fully switched off in some views, a search language with operators like has:attachment and older_than:1y, and a set of keyboard shortcuts that do not resemble anything else on macOS. Someone who dislikes all of that wants a different program, not a different window.

The second question is about the window. Gmail's interface is fine, the search operators are muscle memory by now, and the only real complaint is that a tool used forty times a day is buried in a browser alongside forty things that are not mail. That person does not want a different program at all. They want the same Gmail with a Dock icon, a Command-Tab entry, and a window that does not get closed by accident when a browser window gets closed.

Most articles about a mac os gmail client answer only the first question. That is a real answer, but it is the expensive one, because Google's own Gmail apps are published for iPhone and Android, not for macOS. Any native Mac client is a third party reading the account through Google's APIs or through IMAP, and every one of them makes a different set of compromises to do it.

What the native clients ask of you

Four options cover most of the ground. Each is a real Mac application, each handles Gmail, and each asks for something different in return.

Client	Price	Notes
Apple Mail	Included with macOS	Adds a Google account through the Internet Accounts panel. Presents labels as mailboxes.
Outlook for Mac	Free with ads, ad-free with a Microsoft 365 subscription	Supports Gmail, Yahoo, POP and IMAP accounts. Native build tuned for Apple Silicon.
Thunderbird	Free, open source	Available for macOS from Mozilla. Funded by donations.
Mimestream	49.99 US dollars per year, or 4.99 per month	Built specifically around the Gmail API. Requires macOS 12 Monterey or newer.

The pattern is worth reading carefully. The free options are general purpose mail clients that treat Gmail as one IMAP account among many, which means Gmail-specific behaviour has to be approximated. Labels become mailboxes, and a message with three labels shows up three times. Gmail's server side search gets replaced by the client's own index. Snooze, the promotions and social tabs, and Gmail's filter rules either disappear or stop matching what the web interface does.

The paid option in that table exists precisely because of that gap. Mimestream is built on the Gmail API rather than on IMAP, so labels stay labels and Gmail's search stays Gmail's search. That is what the annual price buys. Whether the price is worth it depends entirely on how much of Gmail's specific behaviour is load bearing in a given day.

There is one more cost that never appears in a comparison table. A native client is another program holding a copy of the mail on disk, another set of credentials, another thing to configure on a new Mac, and another place where a rule can be set and then forgotten about. For someone who genuinely wants a different mail interface, that is a fair trade. For someone who only wanted Gmail out of the tab bar, it is a large amount of work to solve a window management problem.

Keeping Gmail, losing the tab

The second answer is simpler and gets discussed far less. Gmail stays exactly as it is. What changes is where it lives.

macOS has a built-in version of this. Starting with macOS Sonoma 14, Safari can turn any page into a web app through File then Add to Dock. Apple's documentation is specific about what that produces: the web app is saved to the Applications folder of the home folder, and it shares no browsing history, cookies, website data, or settings with Safari. For websites that send notifications, the icon in the Dock can show the number of unread notifications. Settings for the app, including its name and icon, are reachable by opening the app and choosing Settings from the menu bar.

Chrome has its own version, reached through the More menu, then Cast, save, and share, then Install page as app. The result is similar in spirit: a separate window, a separate Dock icon, no tab strip.

Both are free and both are already installed. They are the right starting point, and for a single Gmail account they may be the whole answer. The limits show up in three places. The Safari route requires macOS Sonoma or newer, which rules out Macs that Apple stopped updating. Chrome's Install page as app menu item is not offered on every site, and it lives inside Chrome's own profile system, so a second account means a second Chrome profile. And neither one lets the icon, the window behaviour, or the browser engine be chosen independently of the browser that made it.

There is a smaller benefit that only becomes obvious after a few days. Gmail's keyboard shortcuts were designed for a full browser window, and inside a crowded tab strip several of them sit uncomfortably close to browser shortcuts that do something else entirely. In a window that contains nothing but Gmail, the browser's own chrome is out of the way, the close command closes mail rather than whichever tab happened to be focused, and the window can be sized and placed for reading mail instead of inheriting whatever shape the last browser window had. None of that is dramatic. It simply removes a category of small daily friction that is hard to notice until it stops happening.

A dedicated site to app tool exists to cover exactly those gaps. It builds the app as a standalone bundle, lets the engine be picked from several Chromium based browsers, keeps each app's cookies and sessions separate from the others, and lets the icon be set from a preset, an uploaded image, or the site's own favicon. The Features page lays out which of those are relevant per app.

The two things that actually break

Whichever route gets chosen, two specific behaviours are worth checking before committing, because they are the ones people notice on day three rather than day one.

The first is offline. Gmail offline is a Chrome feature. Google's documentation is explicit: it works only in a Chrome browser window that is not in Incognito mode, it stores the latest 30 days of email and attachments by default, and mail written while offline waits in an Outbox folder until a connection returns. A Safari web app does not get that. A Chromium based site to app tool inherits it, since the engine underneath is the same one Gmail is checking for. A native client, by contrast, has offline mail as a basic property rather than a feature to enable, which for anyone who works on planes or trains is the single strongest argument for going native.

The second is notifications. Gmail's web interface asks for browser notification permission, and that permission is granted per origin per profile. Move Gmail into a separate app with its own cookie store and the permission has to be granted again inside that app. This is not a fault, it is the isolation working as intended, but it does mean the first hour in a new setup involves opening Gmail's settings, turning desktop notifications on, and accepting the macOS prompt. Skipping that step produces the very common complaint that the new app "does not notify", when in fact nothing has been asked of it yet.

Two Gmail accounts on one Mac

Anyone running a personal address and a work address hits the same wall in the browser: Gmail's multi-account switcher works, but it is a switcher, not two windows. Both accounts cannot be visible at once without a second browser profile or an Incognito window that forgets the login every time.

Native clients handle this well. Apple Mail, Outlook and Thunderbird all take multiple accounts and show one unified inbox, which is the strongest practical argument in their favour.

The window based route handles it differently, by making two apps instead of one. Because each Safari web app has its own cookie store, two web apps pointed at Gmail can hold two different signed-in accounts at the same time. The same logic applies to a site to app tool with profile isolation, where separate cookies and login sessions per app are the stated behaviour. The result is two Dock icons, two windows, two sets of notifications, and no account switching at all. Whether that is better than one unified inbox is a matter of how separate the two roles need to stay. People who want a hard line between work and personal tend to prefer two icons. People who triage everything in one pass prefer one client.

Matching the answer to the complaint

The decision gets much easier once the actual complaint is named out loud.

If the complaint is about Gmail's interface, labels, threading, or the absence of proper offline mail, a native client is the answer, and the table above is where to start. Try Apple Mail first, because it is already there and costs nothing to test.

If the complaint is about the window, the tab, the Dock, the missing Command-Tab entry, or two accounts fighting over one browser session, then a native client is the wrong tool and will create new problems while solving none of the stated ones. Keep Gmail. Move it.

If both complaints are true, the honest order is to fix the window first, because it takes five minutes, and then see whether the interface complaint survives a week. It often does not. A tool that is hard to find gets blamed for being hard to use.

What to change first

Open Gmail in Safari and choose File then Add to Dock, or use a browser's install option, and give it a week before spending money on anything. If that week exposes a real gap, a second account that needs its own window, an icon that cannot be told apart in the Dock, or a browser engine that has to match what the rest of the workflow uses, then a purpose built tool is the next step. Kagemusha runs on macOS 12 and later and offers a free tier covering up to three apps, which is enough to test the idea properly before deciding. The Supported services list shows which sites already have a preset waiting.