Putting Google Voice in the Dock: two accounts in two windows

A phone number that matters should not be living in a browser tab. That is the thought behind most searches for a Google Voice desktop app. A business line rings, the tab is buried behind a spreadsheet, and by the time it surfaces the call has gone to voicemail. For anyone with two numbers, a personal one and a work one, it is worse than that: only one account can be loaded at a time, so half the day the wrong line is on screen. Neither problem needs a download from Google, because Google does not offer one. Both are fixable on a Mac.

What Google supports on a computer

Google's setup documentation for Voice is unusually specific about platforms, and it is worth reading before hunting for an installer. The page states that Voice gives a number for calls, texts, and voicemails, and that "You can use this number to make domestic and international calls from your web browser and mobile devices."

Under what is needed to use it on a computer, the page lists supported operating systems as Chrome OS, macOS, and Microsoft Windows, with limited functionality possibly available on other platforms. It lists supported web browsers as Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari. Setup itself begins by going to voice.google.com and signing in.

So macOS is fully supported and Safari is fully supported. What is supported is the website. The Workspace product page for Voice reinforces this: it says a Voice line works on mobile devices, laptops, and supported desk phones, and that calls can be made and received directly in Gmail. Its only download buttons point to the App Store and Google Play.

The absence is not an oversight

Nothing in Google's documentation hints at a desktop client that has been delayed or retired. The design intent is that the browser is the computer client, with the mobile apps and desk phones covering the rest. Third party results promising a Google Voice desktop app for Mac are therefore wrapping the same website, which is exactly what the routes below do, with the difference that nobody else's code sits between the account and the page.

There is one small piece of official tooling worth knowing about. The same setup page documents adding a Voice shortcut to the Chrome app launcher, from voice.google.com, by opening the Google apps grid and choosing Add a shortcut under Voice. That puts Voice one click closer inside Chrome. It does not give it a window of its own.

Why two windows is the real request

The single account limit is the part people underestimate. A personal Google account with a free Voice number and a work account with a Voice line provisioned by an administrator are two different Google identities. A browser can switch between them, but switching is not the same as having both alive. The line that is not loaded is the line that does not ring.

This shows up constantly in a few shapes. A consultant with a client facing number and a private one. A small business where one person answers a shared line and also keeps a personal number on the same laptop. Anyone whose organisation runs Voice through the admin console while their own number predates the job.

Two signed in sessions at the same time is the requirement, and it is a storage problem rather than a feature request. A browser profile holds one set of Google cookies at a time. Anything that gives a window its own cookie store solves it.

What a standalone window gives

macOS has shipped a first party answer since Sonoma. Apple's support note on Safari web apps states that from macOS Sonoma 14 onward, "you can use Safari to save any webpage as a web app, so that you can use it independently of Safari." The path is File then Add to Dock in the menu bar, or the Share button then Add to Dock. The window it creates is saved to the Applications folder of the home folder.

That last detail matters on a work laptop. The home folder is a per user location, so nothing is installed system wide and no administrator password is requested. Anyone who has been told they cannot install software on a company Mac can still have a Dock icon for their work line.

The isolation is the part that solves the two account problem. Apple's documentation says a web app "shares no browsing history, cookies, website data, or settings with Safari." Two windows built the same way therefore hold two independent Voice sessions, and the browser can hold a third. No switching, no signing out, and no guessing which account is active.

Notifications need the permission granted in the window

This is the step that decides whether the arrangement actually catches calls, and it is easy to get wrong. Apple's note explains that a web app's Dock icon can show the number of unread notifications as a badge, and is explicit about how: "to use this feature, respond to the website's notifications request in the web app, not in Safari." Because the web app keeps its own website data, a permission granted in the browser is invisible to it. Once granted in the right place, the web app is listed in System Settings under Notifications by its own name rather than by a URL.

Practically, that means opening the new window, signing in there, and dealing with the notification prompt inside it before assuming anything will arrive. Doing it in the browser first and then building the window produces a window with no permission and no obvious sign that anything is wrong.

Test one call before retiring the old habit

A calling page is not a reading page. Placing one outgoing test call and receiving one incoming call in the new window is worth the two minutes, so that any permission prompt for the microphone gets dealt with at a calm moment rather than in the middle of something that matters. The same applies to the audio output device, since a window is a separate application to the system and the routing worth checking is the one that will be used on a real call.

The routes compared

Route	Session	Notification permission	Needs
Safari, Add to Dock	Separate per window	Granted inside the window	macOS Sonoma 14 or later
Chrome, Install page as app	Shared with the Chrome profile	Follows the profile	Chrome installed
Chrome app launcher shortcut	The current Chrome session	Follows the browser	Chrome installed
A site to app tool	Separate per window	Granted inside the window	The tool installed

Chrome's own help pages on web apps describe the route as More, then Cast, save, and share, then Install page as app, with an install icon appearing in the address bar on some sites instead. The installed app inherits the session of the profile that created it, which removes a sign in step for the first account and removes the isolation needed for the second. Two Chrome profiles restore it, at the cost of managing two profiles.

What the window does not replace

A Dock icon is not a phone system, and it helps to be clear about which parts of the problem it leaves untouched.

It does not change where the line rings. Voice delivers to the devices linked to the account, and the mobile apps exist precisely because a laptop is closed sometimes. A window makes the computer a reliable place to answer while someone is at the desk, which is the only claim worth making for it.

It does not change administration. Organisations running Voice through the admin console control number assignment, porting, ring groups, and routing there, and none of that is affected by how an individual arranges their windows. Someone whose calls are going to the wrong person is looking at a routing rule, not at a Dock icon.

It does not make the page work offline. The window loads the same site over the same connection. A dropped network stops a call in a web app exactly as it would in a tab.

What it does change is attention. A line that has its own icon, its own name, and its own place in the application switcher gets noticed. A line that shares a window with research, mail, and a spreadsheet does not, and no amount of notification configuration compensates for that.

Quitting, hiding, and login items

The last piece of durability is deciding that the window stays open. Apple's note mentions that a web app can be added as a login item so that it opens automatically at login, which removes the one failure mode that undoes all of this: nobody opened it this morning. Hiding the window instead of quitting it becomes natural once it is an application rather than a tab, because there is no tab bar inviting anyone to tidy up.

Choosing what each window opens on

With two accounts the naming is the whole game. Two windows both called Voice, both showing the same icon in the Dock, are worse than one, because every click becomes a guess about which number is about to place the call. Apple's settings panel for a web app exposes an Application Name field, an Application URL field with a button to set it to the current page, and an icon that can be replaced from a file, so both windows can be made unmistakable in about a minute each.

Naming them after the line rather than after the product is what makes the application switcher useful. An entry reading the client facing number, or the name of the business it belongs to, tells someone what will happen when they type. An entry reading Google does not.

The same idea extends past Voice itself. Because the Workspace product page notes that voicemails and SMS messages can arrive in Gmail, and that calls can be made and received directly in Gmail, a window built on the mail surface of the work account covers messages and calls together for people who already live there. Supported services lists the sites that most often end up handled this way, and the Guide covers how the window rules and icons get set.

What does not follow the window

Three things stay where they were, and knowing them in advance prevents a wasted afternoon.

Extensions do not come along. Apple's note describes an Extensions tab in the web app's settings panel, where Safari extensions are enabled per web app. Until something is enabled there, the window has no password manager, which is noticeable during the first sign in.

Links open in the default browser. A Voice URL clicked in a chat message goes to whatever browser macOS is set to use, not to the window built for that account. That is a system routing rule, so it is worth keeping the browser signed into one of the accounts deliberately rather than by accident.

Service limits are unchanged. A window does not alter what Voice charges, where it is available, or which numbers it can issue. Google's own documentation is the place for those, including the note that from the US almost all Voice calls to the US and Canada are free, with some specific numbers costing one cent per minute.

What to change first

Build one window for the line that matters most, sign in there, and grant the notification permission inside that window rather than in the browser. Then place one test call from it. If the second number needs the same treatment, Kagemusha is built for running several of these side by side.