Taking Fitbit out of the browser: checking the numbers without the phone

Searching for a Fitbit desktop app from a Mac runs into two separate facts at once. No macOS application was ever published, and the web dashboard that people used instead is no longer there. Anyone arriving at this search after finding an old bookmark broken is not misremembering. The useful version of the question is narrower: which Fitbit pages a browser can still reach today, and which of them are worth pulling out of the browser.

What fitbit.com shows today

The dashboard address still resolves, and what it serves is a notice rather than a dashboard. The page says to find the health dashboard in the Fitbit app, lists what the app offers instead, and points to a help article about the change. Its navigation has been reduced to three items: Dashboard, Community, and Login.

The domain root behaves differently again. Opening fitbit.com now lands on the Google Store's watches and trackers section, where the devices are sold alongside Pixel Watch models and the companion software is presented as the Google Health app rather than as the Fitbit app.

Signing in reflects the same move. Requesting a Fitbit settings page redirects through a Google sign in flow, because the account itself now lives as a Google Account. The service has moved from being a website with a companion app to an app with a few remaining web pages. That is the sentence to carry into every decision below, because it changes what a window can usefully contain.

None of this is discovered by searching the Mac App Store. A store search is a poor instrument for this question: on Apple silicon Macs, iPhone apps appear in their own part of the results when the publisher allows it, and unrelated third party clients rank alongside the real thing. Opening the vendor's own pages, as above, answers it directly.

Where the features went instead

The notice on the dashboard page is not only a redirect, it is also a summary of what replaced it. Three things are listed as what the app provides: tracking goals and progress, curated workout and mindfulness content, and deeper insights into health and wellness trends. Two of those three are content features rather than charts, which explains the direction of travel. The browser dashboard was a read out of numbers. The app is being built as a coaching product.

The store pages continue the same line. The companion software is named the Google Health app, a subscription called Google Health Premium is sold alongside it, and the coaching is described as working through Gemini to suggest workouts, sleep targets and adjustments when circumstances change. A trainer that asks questions and proposes a plan is not a thing that ports neatly to a web page, and no web version of it is offered.

For someone whose reason to open a computer was to read charts on a large screen, that is a real loss and it is worth naming rather than talking around. The data still exists and can still be extracted, which is the subject of the next two sections. What is gone is the convenience of a page that drew the charts without any work.

This also settles a question people ask in the wrong order. There is no point waiting for a macOS build of an app whose newest features are being designed around a phone, a subscription, and a coach that talks. The productive move is to decide how to get the data onto the Mac in a form that can be read.

Which pages a browser can still reach

Four surfaces remain, and they differ in how often anyone needs them.

The settings pages are the first. Profile details, units, password changes and, importantly, the data export controls are reached from the Fitbit settings area after signing in. This is where the browser still does something the phone does not.

The export flow is the second, and it is documented as a website task rather than an app task. For an account that has moved to a Google Account, the route is the standard Google data download with Google Health selected. For an account still using the original Fitbit login, the steps are to open the Fitbit settings page, sign in, choose Data Export, and then either request a full archive or export a selection.

The community forum is the third, now hosted under Google's help centre rather than on the old Fitbit community domain. The old address still redirects, so an ancient bookmark lands in the right place, but the surrounding help content is organised as Google Health rather than as Fitbit. That matters when searching for an answer, because the terms used in the newer articles are the app's terms and a search for older Fitbit wording returns forum threads instead of current documentation.

The developer site is the fourth, and it carries a warning that matters to anyone relying on a third party dashboard. It states that the Fitbit Web APIs are moving to new infrastructure and that the legacy Fitbit Web API is being deprecated in September 2026, with migration guides published on the Google Health API developer site. Any third party web dashboard reading Fitbit data through the old interface is on a clock.

Getting the numbers onto a Mac screen

Three routes exist, and the right one depends on whether the goal is a look or a record.

The full archive is the thorough option. After requesting it from the export controls and confirming by email, the archive becomes available for download. The documentation warns that a large amount of data can take up to a few days to generate, so this is not a way to check yesterday's sleep.

A selective export is the practical daily option. From the same Data Export screen, choosing to export a selection allows a time period, a data type, and a file format to be picked before downloading. That produces a file a spreadsheet can open, which is how most people end up looking at their own numbers on a large screen.

GPS workouts are the exception that stays on the phone. Those are exported to a Training Center XML file from the app's Fitness tab by selecting an activity, choosing More, then Export.

Goal	Route	Where it happens
Look at today's numbers	The app on a phone	Phone only
Keep a record on the Mac	Selective export, then a spreadsheet	Browser
Archive everything	Full data request	Browser, can take days
A single GPS workout	Export to TCX	Phone app
A live chart on the Mac	A third party or self built dashboard using the API	Browser

The last row is where the original question gets a real answer. The way to see current numbers on a Mac is a page that reads the data through the API and draws it, whether that is a third party service or something built for one person's own use. That page is a web page, and a web page is exactly what benefits from a window of its own.

Which of these deserves a window

Building a window for every page produces a Dock nobody can read. Two tests sort the candidates.

Frequency is the first. A dashboard opened every morning repays a fixed entry point. Export controls visited once a quarter do not, and a bookmark is the honest answer there. Most Fitbit related pages fall on the bookmark side, which is worth saying plainly rather than selling a window for all of them.

A stable URL is the second. If the screen that matters can be reached at one address that will still work next month, that address can be saved into a window and become the opening view. A page that requires selecting a date range from a menu each time can only deliver a reader to the doorstep.

Applying both tests to this service usually leaves one candidate: whichever dashboard actually displays the numbers. The settings and export pages stay in the browser, where their once in a while use belongs.

Building the window, and what it changes

macOS has two built in routes, both free, neither requiring an administrator password.

Safari, from macOS Sonoma 14 or later, offers File then Add to Dock. Apple's documentation describes the result precisely: a web app that functions independently of Safari, sharing no browsing history, cookies, website data, or settings with it, saved into the Applications folder of the home folder. Notifications work once permission is granted inside the web app rather than in Safari, and unread counts then appear as a red badge on the Dock icon.

Chrome's route is More, then Cast, save, and share, then Install page as app, as the Chrome help pages describe. The window belongs to the Chrome profile that created it and inherits that profile's session, which is the quicker option when a sign in already exists there.

For a health dashboard, the choice usually comes down to the account. If the page signs in with a Google Account that is already active in Chrome, the Chrome route avoids a second sign in. If the aim is to keep health data isolated from a browser shared with work, the Safari route creates a container that shares nothing with it.

Behaviour	A browser tab	A window built from the site
Steps to open	Raise the browser, find the tab	One click in the Dock
Session sharing	Shared with every tab in the profile	Isolated on the Safari route
Survives a tab cleanup	No	Closing it is a deliberate act
Opening view	Wherever the tab was left	The URL saved when building it
Links from mail or chat	Open here	Open in the default browser

What a window does not do is add data. It cannot restore a dashboard the service has retired, and it cannot make a phone only screen appear on a Mac. It shortens and isolates the route to a page that already exists.

Where a dedicated tool fits

One window takes about a minute with the built in routes, and for a single dashboard that is the whole job. A site to app tool starts to earn its place at the fourth or fifth window, when several tools each need an icon that is recognisable in the Dock, when sessions have to stay separate, and when the set should be rebuildable on a new machine without remembering how each one was made. What such windows can and cannot do is set out in the feature list, the steps for building one are in the guide, and the services that behave well this way follow patterns visible in the list of supported services.

What to change first

Stop looking for a Fitbit application for macOS, because the answer to that search is settled. Instead, decide which single page is the one being opened daily, whether that is a selective export routine or a dashboard reading the API, and give that page a window with its exact URL saved. Keep everything occasional as a bookmark. If several such windows need keeping in order, the plans are on Kagemusha.