A Google Forms desktop app: replies in a window of their own

A search for a Google Forms desktop app returns two kinds of result, and neither is what it looks like. Some are Google's own pages about using Forms in a browser. The rest are download listings on sites that package web pages as desktop applications, with names and icons close enough to Google's that the distinction is easy to miss. Behind both is the same fact: Forms is browser software, and Google does not publish a Forms application for macOS. That does not mean a Mac has to keep the form in a browser tab. It means the window has to be made rather than downloaded, and knowing which one to make is most of the work.

What Google actually publishes for a Mac desktop

Google is direct about where the editors run. Its documentation states that Docs, Sheets, Slides, Vids, Forms and Pics work with a compatible browser and operating system, that cookies and JavaScript have to be enabled, and that the best experience comes from running one of the two most recent versions of a supported browser. Other browsers may work, with the caveat that not all features will.

The one piece of Google desktop software in this area is Drive for desktop, and its requirements are published alongside. On a Mac it needs macOS Ventura 13.0 or higher. On Windows it needs the Microsoft WebView2 component. On Linux it does not exist, and Google's instruction there is to use Drive on the web.

Drive for desktop syncs files and makes them reachable in Finder. It is not an editor for Forms. A form is a Google Drive item, so it appears in the synced view, and opening it still hands the work to a browser. Nothing about installing Drive for desktop changes where a form gets built.

So the accurate way to state the situation is this. On a Mac, Forms has no application, and the browser is the application. Everything that follows is about giving that browser page a fixed place instead of a floating tab.

The download listings that rank for this search

Several results for a Google Forms desktop app are third-party catalogues offering an installer. These are worth understanding rather than dismissing, because what they provide is real and also narrow.

What they package is the same web page that a browser would load, wrapped so that it opens in its own window with its own icon. That is a legitimate thing to want, and it is exactly the thing macOS can do without an installer. The difference is who maintains the wrapper, where the session data lives, and what happens to the icon when the maintainer loses interest. A form containing other people's answers is not a good place to accept unnecessary uncertainty about any of those.

None of these listings is published by Google, and none adds a capability to Forms. A wrapped page has the same features as the page, because it is the page. Anyone comparing options is really comparing packaging, and packaging is available three ways: from Apple, from a third-party catalogue, or from a tool built for making several of them consistently.

Two jobs hide behind one product

Forms looks like one tool and behaves like two, which is why a single tab never feels right for it.

The first job is building. Google documents the starting point as forms.google.com, where a blank form is created, and the same result can be reached from Sheets through Tools then Create a new form, or from Drive through New then Google Forms. Google's limits for that job are published: up to 300 pieces of content in a form, counting questions, descriptions, images and videos, and up to 75 sections to organise them.

The second job is watching what comes back. That lives on the Responses tab, where a summary of answers appears, where responses can be downloaded as a CSV file through More then Download responses, and where More then Get email notifications for new responses switches on alerts. Google also points to a Form notifications add-on for more notification options and follow-up emails to respondents.

Those two jobs have different rhythms. Building happens in a burst and then stops. Watching happens for days or weeks afterwards, in glances. A window that is useful for the second job is a window opened on the Responses view of one specific form, not on the Forms home screen, and that is a decision no downloaded installer can make.

The account index in the address

One detail decides whether a window opens on the right account, and it is visible in the address. The shortcut forms.new resolves to a create URL under docs.google.com that carries an account index, written as a segment like u/0. That index means the first account signed in, not a particular person.

For anyone signed into a work account and a personal account at once, a window built without noticing the index opens whichever account happens to occupy that slot. The fix is not to memorise the rule. It is to give the window a session of its own, so the index in it means one thing forever.

Where the answers end up, which is often a third page

The two jobs above are the obvious ones. A third page tends to appear a week later, and planning for it prevents a fourth round of window building.

Google documents storing form responses in a Google Sheet, and describes creating a form from inside Sheets, in which case the responses are saved to a new sheet in that spreadsheet. Once that link exists, the spreadsheet is where filtering, sorting and anything resembling analysis actually happens, and the form's own Responses tab becomes a summary view rather than the working surface.

That changes what the useful window is. For a survey being read once, the Responses tab is enough. For a form feeding a process, such as an order sheet, a booking list or a sign-up that someone works through daily, the spreadsheet is the page that deserves the Dock icon, and the form itself can stay in a browser tab because it is only opened when a question needs editing.

There is also a one-off route that needs no window at all. Google documents downloading responses as a CSV file from More then Download responses on the Responses tab, which suits a form that closed last month and is being read for the last time. Choosing between a window and a download is really a question of how many more times the page will be opened.

Four ways to get a window, compared

Route	Who maintains it	Separate session	Own name and icon	Needs macOS Sonoma 14
Browser tab	The browser vendor	No	No	No
Safari, File then Add to Dock	Apple, built into macOS	Yes	Yes	Yes
Third-party download listing	The catalogue's publisher	Varies	Preset by the publisher	Varies
A site to app tool	The tool's maker	Yes	Set freely	Depends on the tool

Apple documents the second row and it costs nothing beyond the operating system it requires. In Safari, open the page to be used, then choose File then Add to Dock from the menu bar, or click the Share button and choose Add to Dock. Type the name to use, then click Add. The result is saved to the Applications folder inside the home folder rather than the system one, and it opens from the Dock or Spotlight like any other application.

The separation is the part that matters for anything involving a signed-in Google account. Apple describes a web app as keeping browsing separate in the manner of a Safari profile, with what happens inside the web app staying inside it. A window for a work form and a window for a personal form therefore hold different sessions, and neither inherits whatever the main browser is signed into.

The fourth row is for the case where this stops being one window. Two accounts, three live forms and a linked spreadsheet add up quickly, and each one built by hand needs its own naming and its own icon. Supported services lists the kinds of pages that most often end up handled that way.

Setting the window up so it stays useful

Each web app carries a settings panel, reached by opening it, clicking its name in the menu bar and choosing Settings. Apple documents the fields, and three of them earn their keep here.

Application URL takes a new address and comes with a Set to Current Page button. The practical method is to build the window roughly, navigate inside it to the exact Responses view that matters, then press that button. There is no penalty for guessing wrong the first time.

Application Name sets what appears in the Dock and the application switcher. A form's window named after the form, rather than after the product, is findable when three of them exist. The Icon field accepts any image, which is the only way two windows of the same site stay distinguishable at a glance.

Show navigation controls decides whether the toolbar appears with its back button, forward button, app name, Share button and buttons for installed Safari extensions. A Privacy tab clears that site's data, including cookies and caches, which is a clean way to sign a window out without touching Safari. An Extensions tab enables or disables Safari extensions for that window alone, and nothing carries over from the browser automatically. If bookmarks or tabs are needed for a moment, the Share button offers Open in Safari. Removing a window later is a Finder operation: open the home folder, open Applications, and drag the item to the Trash. The Guide covers how several of these behave once they coexist.

What the window does not change

Notifications deserve an honest description, because this is where expectations run ahead of the software. Google's documented way of being told about a new response is email, through Get email notifications for new responses on the Responses tab, with the Form notifications add-on offered for more options. That means replies land in a mailbox, not on a Dock icon, and a window will not change that.

Apple's badge feature applies to sites designed to send notifications: respond to the site's notification request inside the web app rather than in Safari, and the unread count appears as a red badge on the Dock icon, with the web app then listed in System Settings under Notifications by its name rather than the site's URL. Whether a given Google page offers that request is a question to answer by watching for the prompt, not by assuming.

Collection controls also stay where they are. Google documents turning off Accepting responses from the Published control on a form, and setting a close date or a response limit in the same place. Those are properties of the form and apply no matter which window is looking at it. Draft answers from respondents are autosaved by default, which is a responder-side behaviour and equally unaffected.

What to change first

Decide which of the two jobs the window is for. If it is watching a live form, build one window and point it at that form's Responses view rather than the Forms home screen, then name it after the form and give it its own icon. If a second account is involved, build a second window rather than switching accounts inside the first. Where several of these need to exist and stay consistent, a tool such as Kagemusha handles them together instead of one menu sequence at a time.