The GitBook editor on a Mac: docs in a window of their own

Searching for a GitBook editor for the Mac lands in two eras at once. Some results describe a desktop application with a version number, a change log and an installer. Others describe a product that runs entirely in a browser and syncs with a Git repository. Both sets of pages are about something real. Only one of them is about software that is still maintained, and the results do not say which. Sorting that out first saves a download that leads nowhere.

Two different things go by the same name

The older meaning is a Mac application called GitBook Editor. It belonged to the original GitBook toolchain, the one built around a command line tool that turned Markdown files into a static book. The editor was a desktop front end for that workflow: local files, a preview pane, a build step, and publishing to the service afterwards.

The newer meaning is the editing surface inside the current product, which is a documentation platform rather than a book building toolchain. It runs in a browser, stores content on the service, publishes documentation sites, and connects to GitHub or GitLab for teams that prefer to write in a repository.

The queries look identical. The answers have nothing in common. A page offering an installer is answering the first question, and anyone whose documentation lives on the current platform will find that installer signs into nothing useful.

Where the old desktop editor went

The trail is short and consistent. The repository that hosted the editor's source under the vendor's GitHub organization no longer resolves; a request for it returns a not found response. Copies survive as forks, and the ones that still carry the original description of an editor for writing books have commit histories that stop in the middle of the last decade.

The command line tool the editor was built around tells the same story from a different angle. On the public npm registry, the package for that tool has a most recent release published in July 2017. Nothing has shipped since.

Meanwhile the vendor's own site has no download page at all. Its published sitemap lists pages for features, solutions, integrations, pricing and industries, and includes no page for a desktop application, an installer or a downloads section. For a company that sells a documentation product, the absence of a downloads page is not an oversight.

What remains are third party download mirrors, and they are why this query is confusing. Those sites keep old installers online indefinitely, complete with system requirements and a change log, which makes an abandoned application look like a current one. The listing is accurate as an archive. It is misleading as a recommendation.

Why this matters before installing anything

An old build of a publishing tool is not merely out of date. It expects a service shape that has since changed, an authentication flow that has since changed, and a project layout that the current platform does not use. On a modern Mac there is also the matter of whether an unmaintained binary is signed and notarized in the way current macOS expects. The safe assumption is that the installer will either refuse to open or open onto a sign in it cannot complete.

What the editor is today, on a Mac

The current editing experience is a browser application, and on a Mac that means whichever browser is already installed. There is no macOS client to install and no separate download to keep updated.

The documentation describes the surface in terms of content structure, formatting, blocks, reusable content, variables and expressions, API documentation and a style guide, with version control layered on top. Collaboration is built around change requests, merge rules, comments and live edits, which is a review flow rather than a save button. Publishing covers custom domains, redirects, PDF export and site permissions.

For a writer, that adds up to a page that is open for long stretches at a time. Documentation work is not a two minute errand. It is an hour in an editor with a reference tab, a repository, and a preview open beside it. Which is exactly the shape of work that a browser tab handles badly.

If the goal was editing locally

Part of what drew people to the old desktop editor was writing in local files. That has not disappeared from the product. It moved.

Git Sync is the documented route. The feature page describes a two way synchronization between the platform and a GitHub or GitLab repository, so that changes made in the visual editor and changes made in the repository update each other. The framing is explicit about who each side is for: developers edit Markdown in their own code editor, while writers work in the visual editor. Branches, reviews and merges work the way they do in a codebase, with a branch created on either side and merged when ready.

For anyone whose real objection to a browser editor is that they want their own text editor, that is the answer, and it is a better answer than an unmaintained desktop app. The local editor becomes any editor, the Mac keeps its own files, and the published result stays consistent.

There is also a current command line tool, documented as a separate thing from the abandoned one. It wraps the service's API as terminal commands for listing organizations, inspecting spaces and pages, and building or publishing integrations. The documentation states that it requires Node version 18 or later and installs globally from npm as a package under the vendor's own scope. Authentication happens once through the browser, with a token option for publishing workflows. It is a tool for scripting and for driving the service from an agent, not a replacement for the editor.

Want	Route	Where the text lives
A visual editor with review flow	The browser editor	On the service
Markdown in your own editor	Git Sync with GitHub or GitLab	In the repository, synced both ways
Scripted or automated changes	The current command line tool	Through the API
An installed Mac application	Not offered	Not applicable

Giving the browser editor a window

Once it is clear that the editor is a web page, the question becomes what kind of window that page gets. macOS has two built in routes and one category of third party tool.

Apple's WebKit team documented the built in Safari route when it arrived with Safari 17.0 on macOS Sonoma. The procedure is File then Add to Dock, adjusting the name and icon at creation. The result behaves like an application: Stage Manager, Mission Control and Command plus Tab all treat it as one, and it opens from the Dock, Launchpad or Spotlight.

Google documents the Chrome route in its help pages. From the More menu, choose Cast, save, and share, then Install page as app, or use the Install button that appears at the right of the address bar on some sites. The app inherits the Chrome profile that created it, so the existing sign in carries over. Chrome also notifies the user when an installed web app wants to change its own name or icon, which can be accepted, ignored or answered by uninstalling.

The third route is the category of tools built for making several such windows and managing them as a set. It matters here for a specific reason: documentation work rarely involves one page. A writer ends up with the editor, the published site, the repository and an issue tracker, and those four things are the working set for the whole afternoon. Making four windows through a browser menu one at a time is tedious, and the Supported services list of one such tool shows how much of that set is already covered by presets.

Open the window on the space, not the dashboard

A documentation account can hold several spaces, and the dashboard is a list of them rather than a place where writing happens. A window built on the dashboard costs one click every time it opens, and that click is always the same click. Built on the space actually being written, or on a specific page inside it, the window opens on work in progress. The same logic applies to the published site: the reason to have a second window pointed at the live documentation is to see what readers see, and that window belongs on the published address rather than on the editor. Keeping the two apart also prevents the most common documentation mistake, which is reading a draft and believing it is what has shipped.

Settings that matter for a writing window

Hide the tab strip and the address bar. An editor has its own toolbar, and stacking browser chrome above it costs vertical space that would otherwise hold text.

Give it its own session. A separate cookie store means the documentation account is signed in independently of general browsing, which is what makes a second account for a second organization possible without signing out.

Leave authentication popups allowed. Sign in dialogs are popups, and a blanket block breaks them while a middle setting permits them and blocks the rest.

Set the window size once. A writing window has an ideal width, and a window that remembers it removes a daily adjustment. The Guide for tools of this kind covers those switches in order.

What the plan changes

Pricing is published per documentation site rather than per person, which is unusual enough to check before planning a team's use. The Free plan is listed at zero per site per month and described as being for individuals. Premium is listed at $65 per site per month with additional team members at $12 per user per month, billed annually. Ultimate is listed at $249 per site per month, with the same $12 per user per month for team members. Enterprise pricing is quoted rather than listed, and a fourteen day free trial is offered on the paid tiers.

The features that move with the tiers are worth knowing before assuming an upgrade is needed. Inviting a team to collaborate, using a custom domain, advanced branding, analytics and site redirects begin at Premium. The AI assistant, the writing agent, adaptive content, authenticated access and content consolidation with sections and groups begin at Ultimate. The visual editor, GitHub and GitLab sync, API playgrounds and preview deployments are listed on the Free plan.

For one person documenting one project, the Free plan and a single well made window is the whole setup. The cost only starts once a team and a custom domain are involved.

What to change first

Stop looking for an installer. If the objection to a browser editor is the browser rather than the editor, set up Git Sync and write in the code editor already on the Mac. If the objection is that the editor has nowhere to live, build it one window with its own session and no browser furniture, and check the Pricing of the plan before adding people to it.