Putting NotebookLM in the Dock, out of the browser

Anyone searching for a NotebookLM desktop app right now runs into two problems at once. The first is that Google does not publish one for macOS. The second is newer and stranger: the product has been renamed, the website has moved to a different address, and most of the pages ranking for this question were written before that happened. Getting a notebook into the Dock is still a five minute job, but it is worth knowing which address to build it from, because the obvious one is no longer the real one.

The name changed, and so did the address

The site that used to answer at notebooklm.google now serves a page titled Gemini Notebook, and the navigation, the feature descriptions, and the help documentation all use that name. The product page describes it as a research and thinking partner grounded in information the user trusts, built with the latest Gemini models, and the community links it offers point at a subreddit and a discussion server named for Gemini Notebook rather than for NotebookLM.

The working address moved with it. A request to notebooklm.google.com now ends up at notebook.google.com, passing through a Google sign in along the way. Google's support content for the product has moved too, sitting under a gemininotebook path in the help centre rather than the old one.

What that means in practice

Nothing that was saved is lost, and the redirect works, so existing bookmarks continue to function. Two things are worth doing anyway.

Build any new window on notebook.google.com rather than on the old address. A window built on a redirecting URL works, but it makes an extra hop on every launch, and if the redirect is ever retired the window built on it stops at an error page while a window built on the destination keeps working.

Expect written guides to be out of date for a while. Instructions that refer to menus and buttons by their old labels are describing the same product under a previous name, which is usually harmless, but it does mean a guide's age cannot be judged by whether its screenshots look familiar.

Name the window for whichever label is actually in use day to day. A Dock icon is read at a glance, and a person who still thinks of the product by its previous name will find a differently labelled icon slower every single time. There is no requirement to match the vendor's branding, and matching the habit is the better choice.

What Google actually ships

The download page for the product offers exactly two things: a listing on Google Play and a listing on the App Store. There is no macOS entry, no Windows entry, and no disk image.

The App Store listing is published by Google LLC and states compatibility as iPhone requiring iOS 17.0 or later and iPad requiring iPadOS 17.0 or later. Mac is not named. On Apple silicon a Mac can run an iPad application only when the developer has allowed it, and this one is not offered that way. A search of the Mac App Store returns note taking utilities from independent developers, none of them published by Google.

So the desktop product is the website. That is not a gap waiting to be filled by an official release, it is the current shape of the thing, and the question becomes how to give a website the properties of an application.

The one thing the phone app has that a Mac cannot copy

Google's download page lists what the mobile apps are for, and most of the items describe the same things the website does: creating and viewing notebooks, uploading sources such as PDFs, websites, and videos, joining audio discussions, and asking questions that come back with in line citations. One item is different. The phone apps can receive sources sent from anywhere else on the device, which is the operating system's share sheet doing the work.

That capability has no equivalent on the Mac for this product, because there is no macOS application to receive a share. Adding a source on a Mac means getting to the notebook and putting it there. Which is precisely the argument for the window: if adding a source requires finding the right tab in the right browser profile first, sources stop being added. A Dock icon removes the step that was causing the omission.

Why a Windows result keeps appearing

Searches for this turn up a community project that wraps the site for Windows, along with catalogue sites that list the web product alongside downloadable software. Those are real pages doing real work for their own audiences, and they explain why the search results look like a desktop version exists somewhere. For a Mac reader they are a detour. The routes below start from what is already installed.

Three ways to give it a window

Route	Where it is saved	Account handling	Icon and name
Safari, File then Add to Dock	Applications folder in the home folder	Its own session	Both editable
Chrome, Install page as app	Tied to the Chrome profile	Inherits the profile	Limited
A site to app tool	A standalone app bundle	Its own session per app	Full control

Apple's documentation sets out the Safari route. From macOS Sonoma 14 onward, opening a page and choosing File then Add to Dock, or the Add to Dock item under the Share button, saves it as a web app. That web app functions independently of Safari and shares no browsing history, cookies, website data, or settings with it. It lands in the Applications folder of the home folder, which is a per user location, so nothing is installed system wide and no administrator password is requested. Its settings panel exposes the name, the icon, and the Application URL, each editable after the fact.

Chrome's route, documented in its help pages, runs through More, then Cast, save, and share, then Install page as app. The resulting app belongs to the Chrome profile that made it and uses that profile's Google session, which is the fastest path for a single account and the wrong one for keeping two apart.

A dedicated tool produces the same kind of standalone window with more control over the result, which starts to matter once more than one of these exists.

What actually improves for this product

Three things about the way notebooks get used make a separate window more useful here than it is for an ordinary website.

Work that runs while attention is elsewhere

Generating an audio overview from a set of sources is not instant, and neither is processing a long document that was just uploaded. Work that runs in the background is work that gets lost in a tab strip, because the tab has no way to raise its hand. An application in the Dock can be switched to directly, and a notification, if permitted, has somewhere to land. Apple's documentation notes that for websites that send notifications, a web app's Dock icon can show the number of unread notifications, with permission granted inside that window rather than inherited from the browser.

One window per notebook

A notebook is a project. Research for a thesis chapter, a competitor review, and a set of interview transcripts are not one workspace that happens to have three tabs, they are three jobs. Each notebook has its own URL, and a window can be built on any of them, so the Dock can hold the specific notebook that a particular block of work belongs to rather than a product home screen that needs navigating every time.

Keeping personal and work accounts apart

This is the one that sends most people looking. Google products resolve to whichever account the browser session is signed into, so a personal account and an organisation account in the same browser are a constant source of opening the wrong thing. Separate storage solves it properly, because each window holds its own session permanently. Two windows, two accounts, two icons, no switching. The Guide covers how those separate windows are set up and kept apart.

What a window does not change

Setting expectations here prevents disappointment on day two.

The window renders the same website, so nothing about the product itself is different inside it. That cuts both ways, and mostly in a useful direction. There is no version to update, no build lagging behind the web release, and no waiting for a desktop client to catch up. A capability that appears on the website appears in the window the next time it loads. For a product changing as quickly as this one, that is worth more than a native client that ships on its own schedule.

It also means anything requiring a connection still requires one. A window in the Dock is not an offline copy of the sources inside it, and treating it as though the research is now stored locally is a misreading of what was built.

The last one is link routing. A notebook URL clicked in a mail message or a chat opens in the default browser, not in the window, because macOS routes links by default browser rather than by which application displays that domain. An installed client written by the vendor can claim its own links. A window built from a website cannot. Expect the browser to stay in the picture, and keep it signed into the account the window uses, or the occasional link will land in the wrong account and cause a moment of confusion.

Choosing between the routes

Pick Safari when account separation is the point. The isolation Apple describes is not a limitation to work around, it is the mechanism that keeps a work notebook and a personal one from colliding. The first launch will ask for a sign in, and that is the system working.

Pick Chrome when there is one account, the Google session is already live in a profile, and extensions used while reading sources need to stay active. Extensions do not follow into a Safari web app unless enabled for it, and anyone who clips sources with an extension will notice immediately.

Pick a dedicated tool when several notebooks or several accounts deserve their own icons. The browser routes handle one window well and become repetitive at five, and the differences that show up at that scale are practical ones: which window opens at login, what each is called, and whether the icons can be told apart in the Dock at their actual size. Supported services shows the sites that most often end up managed this way.

What to change first

Open notebook.google.com in Safari, choose Add to Dock, and sign in inside the new window. If the notebook that matters most deserves its own icon, build a second window on that notebook's URL and name it after the project, then consider a tool such as Kagemusha once there is a third.