Running Gmail and Google apps as Mac apps

Gmail is usually the tab that gets clicked most and found least. It sits somewhere in a row of thirty, it gets reopened by accident in a second window, and the fastest way back to it is a search through the tab strip. Making it a desktop app on a Mac fixes that in about a minute. The part that takes longer is deciding which of the three routes to use, because they differ on exactly the things that matter for a mail client: which account is signed in, whether notifications arrive, and whether anything works without a network.

What the three routes actually produce

All three wrap the same page. None of them download Gmail, compile anything, or make it faster. What each one produces is a window with a Dock icon, no tab strip, and its own entry in Command Tab. The differences show up in storage and dependencies.

	Chrome install	Safari Add to Dock	Dedicated site to app tool
Requires macOS Sonoma 14 or later	No	Yes	No
Signed in immediately after creation	Yes	No	Depends on the tool
Session shared with the browser	Yes	No	Usually separate per app
Chrome extensions keep working	Yes	No	Depends on the engine used
Survives deleting the browser profile	No	Not applicable	Usually yes
Cost	Free	Free	Free tier or paid

The row that decides most cases is the session row. Everything else can be worked around later. A wrong session model means the app shows the wrong inbox, and that is discovered on a Monday morning rather than during setup.

Worth stating plainly before going further: none of these routes changes how Gmail performs. The page is still fetched over the network and rendered by a browser engine. Anyone hoping the app version loads faster than the tab will not see it.

The Chrome route, and the menu item that looks right but is not

Chrome has two menu items with similar names, and the wrong one is the one most guides still describe.

Open Gmail, open the three dot menu, and look under Save and share. There is Create Shortcut, and there is Install page as app. The one that produces a standalone window is Install page as app. Create Shortcut now produces a bookmark that opens in a normal tab, and the Open as window checkbox that older articles refer to is no longer in that dialog.

Starting in Chrome 128, the Create Shortcut menu item in More > Save and share now creates a bookmark on the user's desktop or homescreen. The previous behavior of this menu item on desktop has moved to the Install Page as App option. Source: developer.chrome.com

Because Gmail ships an app manifest, an install icon also appears at the right edge of the address bar. Using it gives the same result as the menu.

The app that comes out of this runs inside the Chrome profile that created it. That has one immediate benefit and one delayed cost. The benefit is that it opens already signed in, with the profile's extensions active, so a mail workflow that depends on a tracking blocker or a CRM extension keeps working. The cost is the coupling. Rename or delete that profile and the app breaks. Move to a Mac without Chrome and the app does not come along.

The Safari route, and why the new app asks for a login

Safari can do the same thing on macOS Sonoma 14 and later. Open Gmail, choose File, then Add to Dock, confirm the name, and the app lands in the Applications folder in the home directory.

The surprise arrives on first launch: a Google sign in screen, even though Safari has been signed in for years. That is the intended behavior.

A web app functions separately from Safari. Its browsing history, cookies, website data, and settings aren't shared with Safari. Source: support.apple.com

For Google services specifically, that separation is a feature rather than an annoyance. A work account and a personal account can live in two apps side by side, both signed in, with no switching. Chrome cannot do that from one profile, since every app built from it follows the same login.

The cost on this side is extensions. Only Safari extensions run, and a Chrome extension has no path into a WebKit window. If the daily mail routine depends on one, that particular service belongs on the Chrome route instead. The three routes are not exclusive, and mixing them per service is normal.

Two Google accounts is where the decision gets made

Google allows several accounts to be signed in at once inside one browser, and the account index in the URL decides which mailbox appears. Work might be 0 and personal 1.

This makes it look like the Chrome route handles multiple accounts fine. Open the URL for each index, install each one, and two icons appear in the Dock. The catch is how those numbers are assigned. They follow the order accounts were signed in. Sign out of everything and back in, or add a third account, and the mapping can shift. The app labeled Work then opens personal mail, and there is no setting inside the app to correct it.

Routes that give each app its own cookie store avoid the problem entirely, because the app holds its own login instead of reading an index from a shared session. If two or more Google accounts are in daily use, pick a route with separate storage before building anything. Rebuilding later is cheap, but a month of opening the wrong inbox is not.

Notifications and offline access differ by route

Half the reason to package a mail client is to get notifications without keeping a browser in front. This is where the routes separate again.

An app made through Safari appears on its own line under System Settings, Notifications. It can be allowed or silenced independently of Safari and independently of every other web app. Mail can be noisy while a calendar app stays quiet, and all of it is controlled from the same place as native apps.

An app made through Chrome inherits the site permission already recorded in Chrome. If notifications were denied for Gmail in the browser, the app is silent too, and the fix is in the browser settings rather than anywhere in the app.

Offline access has a harder split. Gmail can make recent mail readable without a connection, and Google's own documentation limits that feature to the Chrome browser. An app built with Add to Dock will not have it. For anyone who reads mail on a train, that single line decides the route for Gmail even if every other service goes elsewhere.

The small settings that decide whether the app gets used

Most abandoned web apps are abandoned for one of three reasons, and all three are set at creation time in under a minute.

The first is the starting URL. Whatever page is open when the app is created becomes the page it opens on, every launch. Creating a Gmail app from a search results view, or from a single thread, produces an app that reopens that view days later. The address to build from is the plain inbox URL, and for a multi account setup it is the one carrying the correct account index.

The second is the name. Default names come from the page title, which for Gmail is often the address of the signed in account plus an unread count. That string is too long for the Dock and reads as noise in Command Tab. Two words is the right size, and something like Mail Work beats Gmail when a second account app is sitting next to it.

The third is the icon. Favicons are small, and a container that scales one up produces a blurry square that the eye slides past. An app that cannot be recognized at Dock size will not get clicked, no matter how correct the rest of the setup is. Replacing the image takes a minute for one app, which is why preset catalogs exist for people building more than a handful.

One more detail is worth checking for mail specifically. Clicking a mailto link elsewhere on the Mac opens whatever application is registered as the default mail handler, and that registration belongs to the browser or to Mail, not to a packaged app. Setting Gmail as the handler is done in Chrome's settings, and it keeps working independently of whether a Gmail app exists. Anyone expecting the new icon to catch mailto links by itself will be disappointed, and there is nothing inside the app to change about it.

Which Google services are worth packaging

Packaging everything is a waste of an afternoon. The useful filter is how often a service gets returned to from another task, not how often it is open.

• Gmail and Google Calendar: interrupted work, checked, left again. High return count, so the Dock icon earns its place.
• Google Drive and Docs: opening a file spawns more windows, and a separate app makes that sprawl more visible rather than less.
• YouTube: useful as a standalone window when audio plays in the background, awkward when the session is search and compare.
• Google Ads, Analytics, Search Console: dashboards that get glanced at. No address bar needed, so they package cleanly.

Volume matters too. Three apps are easy to name and icon by hand. Twenty five means an afternoon of hunting favicons, which is the point where preset driven tools stop being a luxury. The catalog on a Supported services page is a fast way to see whether the services in daily use are already covered, and what a given tool is designed around.

Cost, and what free leaves empty

Both native routes cost nothing, and for two or three apps they are usually enough. Paid tools earn their price on the rows the free routes leave blank: per app sessions with extensions still working, per app notification control, menu bar or sidebar residency, custom icons and window rules, and a maintainer who ships an update when macOS or Chrome changes underneath.

That last one is not decorative. Chrome updates every few weeks, and containers tied to a browser installation can lose an icon or fail to launch after a major update. With three apps that is a minor repair. With twenty five it becomes a recurring task, and how much of it is handled automatically varies by tool. What a given tool can control is listed under Features, and the split between a free tier and a one time purchase is on the Pricing page.

What to change first

Build Gmail today on whichever route is already installed, and give it the correct starting URL and a real name. If the second Google account or a missing notification turns out to be the blocker within the first week, that is the point to compare what a tool like Kagemusha handles differently, rather than trying to decide it in advance.