Running Google Slides as a standalone app on macOS: not closing a draft by accident

Google answers the Google Slides for mac question on its own product page, though not in the words people search for. The Slides page offers the app in two places, the App Store and Google Play, and describes it as a way to view, present or collaborate on a phone or tablet. Google's help pages for the Docs editors are equally consistent: every instruction that begins with the word computer continues with opening a web address. There is no macOS installer, and there is no plan that unlocks one.

What that leaves is a decision about the window. A deck under construction is not a page to read, it is a workspace that stays open for hours, gets presented from, and gets returned to after every piece of feedback. Keeping it in the eleventh tab of a browser window is the reason people lose their place in it, and it is the reason a stray Command and W feels like a small disaster even when nothing was actually lost.

What Google ships for a Mac

Google's distribution for the Docs editors is unusually simple. There is the web version, which is the product, and there are phone and tablet apps that mirror it. Google Drive for desktop syncs files to the Finder, but it does not turn a presentation into a local application: opening a Slides file still hands it to the browser.

This is worth stating plainly because the absence of an installer is often read as something missing. It is not. The editor, the collaboration, the comment threads and the version history all live on the server, and the browser is the client. Nothing about a standalone window changes that architecture. What a standalone window changes is which keystrokes reach the deck, how much of the screen the deck gets, and how quickly it can be found again.

Google also documents the offline story in detail, and that detail is the one place where the choice of route has real consequences. More on that below, because it decides which of the two built-in options is actually available.

The accidental close, and what is really lost

Google records edits continuously. Hovering over Last edit at the top right of a presentation shows who changed it and when, and clicking it opens version history, where earlier versions can be browsed and restored. Browsing those earlier versions requires edit permission on the file, which matters on a deck someone else owns and shared for comments only.

So the content survives a mistaken close. What does not survive is everything around the content: which slide was selected, the object that was half positioned, the speaker notes window, the second tab with the source data, the comment thread that was open at the right place. Reopening the file gets the deck back and throws the working state away. That is the actual cost of Command and W, and it is why a separate window is worth the two minutes it takes to set up.

There is a second, quieter version of the same problem. In a window of many tabs, a deck that is open is functionally closed, because finding it takes a scan. A Dock icon turns that scan into a click, and Command and Tab reaches it without breaking eye contact during a call.

The keyboard makes it worse than it needs to be. In a presentation, Command and W closes the tab, Command and S is the habit trained by every other application, and Slides does not need Command and S at all because it saves continuously. So the reflex that protects work in other tools does nothing here, while the key beside it removes the window. On top of that, a browser keeps Command and L for the address bar and Command and 1 through 9 for switching tabs, which are keys a slide editor could otherwise use. A standalone window hands most of that keyboard back to the deck.

One more thing changes with the window rather than the file. A deck shared for comments only cannot be rolled back by the person reading it, because version history needs edit permission. When feedback arrives as a suggestion to try three different layouts, the safe move is to duplicate the deck first and experiment in the copy. That is a habit, not a setting, and it is independent of which window the deck is open in.

Two built-in ways to give Slides its own window

macOS has offered one route since Sonoma 14, and Chrome has offered the other for years.

In Safari, open the presentation list or a specific deck, click the share control in the toolbar, and choose Add to Dock. Apple's documentation is specific about the result: an icon is added to the Dock and to Spotlight Applications, an existing sign-in carries over in most cases with the same user name and password, the window gets a simplified toolbar, and the web app can post notifications like any other app. It is adjustable afterwards as well. From the web app's own menu bar, Settings and then General offers the application name, the application URL, the Dock icon, whether the Back, Forward and Share buttons appear, and whether the title bar shows the site's colour.

In Chrome, the route is in the three dot menu under Cast, save and share, as Install page as app. Google's help pages note that installed web apps appear at chrome://apps, that some of them gain extra capabilities such as more offline storage, notifications, file system access and icon badges, and that uninstalling offers to delete the app's data from Chrome at the same time.

Route	Available on	Offline editing	Account separation
Safari, Add to Dock	macOS Sonoma 14 and later	Not supported by Google	One session per Mac user
Chrome, Install page as app	Any current Chrome	Supported, with the extension	Per Chrome profile
A site to app tool	Any current macOS	Depends on the engine used	Per app, by design

The third row exists because the built-in routes stop at the window's contents. A tool that turns a website into a standalone Mac app treats the window as something to configure: the size it opens at, a global shortcut that brings it forward from any other application, the same site built twice under two names for two accounts, and a preset instead of a blank URL field. The Features page sets out which of those are adjustable, and the Supported services list shows which sites already have presets.

Offline is where the route stops being a matter of taste

Google's page for the Docs editors says that Slides can be created, viewed and edited without an internet connection. The requirements for that are listed just underneath, and they are strict.

Offline access requires the Google Chrome or Microsoft Edge browser. It requires the Google Docs Offline extension to be installed and turned on. It must not be used in private browsing. The switch itself lives in Google Drive under Settings, as the Offline setting, and turning it on for Drive, Docs, Sheets or Slides turns it on for the rest. Recent files are saved automatically when there is space, and a specific file can be marked Available offline from the More menu on the file card.

Read that list next to the two built-in routes and the conclusion is unavoidable. A Safari web app is not Chrome or Edge, so a deck inside it is a deck that needs a connection. If the reason for wanting a standalone window is a train, a plane or a venue with hostile wifi, the Chrome route is the one that works, because an installed Chrome app is still Chrome and still carries the extension.

Google adds one more line that is easy to skip and expensive to ignore: to use offline access with another Google account, be signed in to the right Chrome or Edge profile. Offline access is a property of a profile, not of a person.

Chrome's own help page about web apps carries a matching caution, which is that although web apps work offline, some may not work completely without a connection. Before relying on it, turn on offline access, mark the deck available offline, then switch off wifi and open the deck once. Five minutes of testing at a desk is worth more than a plan.

Two Google accounts, two windows

Most people who present for a living have more than one Google account, and the Docs editors follow whichever one the window is signed in to. The failure mode is familiar: a deck created under the wrong account, shared with the wrong domain, and then discovered by someone who cannot open it.

Chrome profiles fix this at the level where the mistake happens. Two profiles, one Slides app installed from each, and each Dock icon opens a session that belongs to exactly one account. Google's offline instructions point at the same mechanism, since offline access is granted per profile.

A dedicated site to app tool takes a different path to the same place, by building the same site twice as two separate apps with two names and two icons. The advantage is legibility: the Dock shows which account is open before anything is typed, rather than after something has been saved to the wrong place.

Presenting from a window instead of a tab

Presenting is the moment when a browser's furniture becomes visible to other people. Full screen hides most of it, but the transition into and out of presentation mode is where the tab strip, the bookmarks bar and whatever else was open get a moment on the projector.

A standalone window narrows that exposure, because there is nothing else in it. Apple's simplified toolbar means less to reveal, and the window contains one site rather than a session's worth of browsing. For anyone who shares a screen during a call rather than presenting to a room, the same argument applies with more force: the audience sees the window, and the window is the deck.

Notifications deserve a decision at the same time. Apple states that a web app can post notifications like any other app, which is useful for comment replies and unwelcome mid-presentation. Turning them off for the Slides web app in System Settings, while leaving them on for mail and calendar, takes less than a minute and is the difference between a clean presentation and a visible comment from a colleague.

What to change first

Pick the route by the offline answer, not by preference. If a deck ever needs editing without a connection, install Slides as an app from Chrome, turn on the Offline setting in Drive, and test it once with wifi switched off. If offline is irrelevant and the goal is simply that a deck stops hiding among tabs, Add to Dock in Safari is two minutes of work with no configuration. If what is wanted after that is a fixed window size, a global shortcut, or two icons for two accounts, that is when a tool such as Kagemusha earns its place.