A Cronometer desktop app: daily entries in their own window

Logging a day of food is typing. Weights, portions, a recipe pasted from a URL, a biometric or two. Typing is faster with a keyboard and a large screen, which is why a cronometer desktop app search happens at all. The answer is not a download link, but it is also not a flat no. There are two genuine routes to a Cronometer window on a Mac, they behave very differently, and the search results mostly cover neither.

What Cronometer publishes

The platforms named on the Cronometer site are the web app, iOS, and Android, with Apple Watch as a companion. There is no Mac installer and no Windows installer to download.

A search of the Mac App Store for software published by Cronometer Software Inc returns nothing. Every Cronometer shaped result there belongs to a different developer, and several of them are unrelated utilities that happen to share a word in the name. This matters because some download sites list a Cronometer desktop app as though a native build existed, and a reader who follows one of those links is installing something Cronometer did not write.

Cronometer's own help centre refers to the browser version as the desktop web app, which is the clearest signal of intent available. The product for larger screens is the website. Cronometer Pro, the version aimed at nutritionists, dietitians, research institutions, schools, and hospitals, is described on the site as a web based platform as well.

So the honest starting position is this: the desktop product exists, it just arrives as a URL rather than as a package.

The route most results miss: the App Store build on Apple Silicon

The Cronometer app on the App Store is published by Cronometer Software Inc, is free with in-app purchases, sits in Health & Fitness, weighs 159.4 MB, and is listed in English. Version 4.59.1 is dated 14 September. The age rating is 13+, and the listing states that the app contains advertising.

The compatibility block is where it gets interesting. Alongside the expected iPhone, iPad, and iPod touch lines at iOS 15.5 or later, the listing carries one more entry: Mac, requires macOS 13.0.0 or later and a Mac with Apple M1 chip or later. Apple Vision at visionOS 1.0 and Apple Watch at watchOS 7.0 round out the list.

That single line is a genuine desktop route. On an Apple Silicon Mac, the iPad build installs from the Mac App Store, lands in the Applications folder, appears in Spotlight, and runs in its own window with no browser anywhere in the picture. It updates through the App Store like any other app.

The trade-offs are real, though, and they are the reason this is not simply the best answer. The interface is the iPad interface, laid out for touch and then driven with a pointer. Hover states and right click menus are not part of that design. A day of dense entry with a keyboard is not what the layout was built for. Intel Macs are excluded outright by the M1 requirement. And the accessibility features the developer declares on the listing are Larger Text and Dark Interface, which is a shorter list than a mature Mac app would carry.

There is also an integration boundary worth knowing. Cronometer's help centre states that the Google Fit and Apple Health integrations are available only when using the mobile app. Running the iPad build on a Mac does not put an iPhone's health data into it.

What the browser version does that the App Store build does not

The web app is the full product, and it is the one built for a keyboard.

Recipe entry is the clearest case. Gold includes a recipe importer that takes a pasted URL and builds a custom recipe with ingredients, measurements, and nutritional data. Pasting a URL is a desktop gesture. So is working through a week of custom charts, or reading historical data across months, or setting up custom biometrics for pain symptoms and test results.

The Gold feature list the site publishes runs to a dozen items: Photo Log, Voice Log, Crono Coach, Custom Charts, Nutrition Scores, Recipe Importer, Repeat Items, Macro Scheduler, Fasting Timer, Oracle Nutrient Search, Custom Biometrics, plus an ad-free experience, unlimited historical data, and partner offers. Several of those are read heavy rather than tap heavy, and read heavy features reward a large window.

Cronometer Pro is web only, so anyone using Cronometer professionally has no App Store route at all. For them the question is not whether to use the site. It is what the site should live inside.

Putting the site in a window of its own

macOS has two built in ways to turn a website into something that behaves like an app, and they suit this job differently.

Safari has it under the share control. Apple documents the route as going to the site, clicking the share control in the toolbar, choosing Add to Dock, then clicking Add. The icon lands in the Dock and in Spotlight Applications, the window carries a simplified toolbar, and notifications arrive the way they do from any app. Apple also notes that a site already signed in usually stays signed in inside the new web app, with the same user name and password.

A Safari web app then gets its own settings. Open it, click its name in the menu bar, choose Settings, then Privacy, and there are controls for camera and microphone access, screen access, location, clearing that app's website data, and how its notifications appear in Notification Center. Apple notes the Notifications option only appears once the site has asked for permission. For a food diary, the useful part of that panel is the data boundary: clearing website data there clears it for that app alone.

The Chromium route is supported by Google Chrome and Microsoft Edge on macOS, which show an install badge in the address bar when a site declares itself installable. One measured detail applies here: the Cronometer pages a browser loads, including the login page, do not link a web app manifest. There is no publisher supplied application name or icon for the browser to read, so no install badge will appear.

Installing is still possible. Chrome allows a page that does not meet its installability criteria to be installed anyway, and only the standalone and minimal-ui display modes exist on the desktop. The resulting window is a real one: it appears in Spotlight, it can carry a badge number on its icon, it can be set to open at login from about:apps, and it cannot be installed twice within the same browser. Safari's Add to Dock reads no manifest at all, which is exactly why it works on sites that were never designed to be installed.

Three containers, side by side

Container Interface Works on Intel Macs Gold recipe importer and charts Updates through
App Store build on Apple Silicon iPad layout, pointer driven No. M1 or later only Present but laid out for touch App Store
Safari Add to Dock Full web app Yes Yes The website
Chrome or Edge install Full web app Yes Yes The website

The pattern is consistent. The packaged route wins on feeling like an app and loses on layout and hardware. The two browser routes win on being the complete product and lose the App Store's update plumbing, which for a website is not much of a loss.

The habits a window changes, and the ones it does not

A food diary fails for boring reasons. It gets skipped at lunch, then skipped at dinner, then the day is a gap and the week stops being worth looking at. Most of the reasons are about friction at the moment of entry, which is why the container matters more here than it would for a site that gets opened once a week.

Three pieces of friction disappear when the diary stops being a tab. The first is finding it. An installed window appears in Spotlight under its own name, so it is summoned by typing rather than by scanning a row of favicons. The second is accidental closure. Command and W closes a tab without ceremony, while quitting an app is a different keystroke, and tools that build apps from an installed browser can put a confirmation on that keystroke per app. The third is reopening after a restart. From about:apps, a Chromium install can be set to start when signing in, so the diary is simply there in the morning.

Notifications are the fourth, and they cut both ways. A Safari web app gets its own row in Notification Center with its own quiet hours, which is genuinely useful for a fasting timer and genuinely annoying for everything else. Setting that per app rather than per browser is the point.

What a window does not change is the discipline. Entries still have to be typed, and the App Store build on an Apple Silicon Mac is arguably better at the two second entry while the site is better at the ten minute review. Running both is a legitimate answer, and it is the answer most weeks will end up with.

What the container does not change

The subscription is the clearest example. The in-app purchases on the App Store listing are Gold Monthly at $10.99 and Gold Annual at $59.99. Gold is attached to the Cronometer account, so signing in to a Safari web app, a Chrome install, or the iPad build on a Mac all show the same tier. Nothing about the window changes what the account is entitled to.

Advertising follows the same rule. The listing states that the app contains advertising, and the site describes an ad-free experience as a Gold feature. That is an account level switch, not a container level one. A site wrapped in a Dock icon shows exactly what the browser would show.

The food database, the nutrient calculations, and the historical data are all server side. Three containers pointed at the same account see identical numbers, which is worth knowing before spending an evening comparing them.

One thing does change with the route: extensions. A Safari web app runs Safari extensions, enabled per app from its own settings. A Chromium install inherits the extension set of the profile that created it. Tools that assign a browser profile per app let each window carry its own extensions, so a password manager can be present in the diary window without every other window inheriting the same list. The Guide covers what to decide when the same site is built more than once, and the Supported services list is a fair prompt for which other tabs deserve the same treatment.

What to change first

Check the Mac first. Apple Silicon and casual logging means the App Store build is the shortest path, and it takes two minutes. A keyboard heavy diary, an Intel Mac, or a Cronometer Pro account means the site is the product, and the only decision left is which window it lives in. The Kagemusha feature list describes the per app profile route for that second case.

Frequently asked questions

Is there a real Cronometer app for Mac?

Not as a download from Cronometer. The platforms the site names are the web app, iOS, and Android. On an Apple Silicon Mac the iPad build can be installed from the App Store, because the listing carries a Mac line reading: requires macOS 13.0.0 or later and a Mac with Apple M1 chip or later.

Can an Intel Mac run the App Store version?

No. The Mac requirement on the listing names an Apple M1 chip or later, so Intel machines are excluded. On those Macs the options are the site in a browser or the site inside a window built from a browser, both of which give the complete web app.

Does Gold cost more or less depending on where it is bought?

The prices shown on the App Store listing are Gold Monthly at $10.99 and Gold Annual at $59.99. Gold is attached to the account rather than to a device, so whichever container is signed in shows the same tier, and cancelling in one place cancels everywhere.

Will Chrome offer to install cronometer.com as an app?

The pages a browser loads, including the login page, do not link a web app manifest, so the install badge in the address bar has nothing to read. Chrome can still install a page that does not meet its installability criteria, and the resulting window behaves like any other installed desktop app.

Does the iPad build on a Mac read Apple Health data?

No. Cronometer's help centre states that the Apple Health and Google Fit integrations are available only when using the mobile app, so running the iPad build on a Mac does not bring an iPhone's health data along with it.

Back to all posts