A Hugging Face Mac app: models and spaces in a single window

Searching for a Hugging Face Mac app produces a strange mix of results: one App Store listing that turns out to be an image generator, an archived GitHub repository, a catalogue site offering a desktop wrapper, and a pile of tutorials about installing Python packages on Apple silicon. None of them is the thing being looked for, which is an application that puts the Hub on the Mac the way a mail client puts mail there. That application does not exist, and understanding why makes the next decision easy rather than disappointing.

What Hugging Face actually publishes for macOS

Two native applications carry the company's name, and neither is a client for the Hub.

Diffusers is a real Mac application, listed on the Mac App Store by Hugging Face, Inc. It costs nothing, requires macOS 13.1 or later, and the current version is 1.5. It generates images from text using Core ML converted models pulled from the Hub, and the download itself is tiny because the models arrive on demand and are cached on disk afterwards. The release notes for that version mention support for Stable Diffusion 3 Medium along with quantized and palettized variants. Worth noting before installing: that version shipped in June 2024, so it is a working tool rather than an actively moving one.

HuggingSnap is the other, and it runs on iPhone rather than a Mac. It is free, requires iOS 18.0 or later, and the current version is 1.2, released in March 2025. It is a camera application that describes what it sees using an on device model.

Search the Mac App Store for anything else under that developer name and nothing comes back. There is no disk image on the website, no .pkg, and no page in the documentation offering a desktop client for browsing models, managing repositories or running Spaces. The product surface on a computer is a website plus a command line, and that split is deliberate.

The Mac app that existed, and what happened to it

There was a real one. HuggingChat for macOS was a native Swift application that put the company's chat interface in the menu bar, and it collected close to two thousand stars on GitHub. It is worth knowing its current state before spending an evening building it.

The repository is archived. The last release is v0.7.0, published in December 2024, and the last commit landed in February 2025. Archived on GitHub means read only: issues are not being answered and pull requests are not being merged. The licence is Apache 2.0, so the code can be forked and compiled by anyone willing to maintain it, but nobody is shipping updates.

The service it pointed at is still running. HuggingChat is live on the website, it now routes requests through a model picker described as Omni that selects a model for each request, and the interface lists well over a hundred models to choose from directly. So the chat is available; only the native shell around it went away.

This is the pattern behind most of the confusing search results. A native application gets built, usually by one or two people, it works well for a year, and then attention moves. Downloading an unmaintained build that was last touched in 2024 to sit permanently in a menu bar, holding an access token, is a decision worth making on purpose rather than by accident.

The parts of the Hub that only exist on the web

Everything that makes the Hub useful for browsing is a page. Model cards, the files and versions tab, the dataset viewer, the community tab, Spaces, leaderboards and organisation settings are all rendered server side and have no local equivalent.

Spaces deserve particular attention, because they are the reason the browser stays open for hours. A Space is a hosted demo, often a Gradio interface, and using one means loading a page and waiting while something runs. The free tier is a CPU Basic instance with 2 vCPU and 16 GB of memory, and ZeroGPU is also listed at no cost. Paid hardware starts at $0.03 an hour for a CPU upgrade and runs up through the GPU tiers. A Space being demonstrated to someone else is a page that has to stay reachable and signed in.

Account tiers are also web side. A PRO account is $9 a month, Team is $20 a month per user, and Enterprise is $50 a month per user. Storage is priced per terabyte, starting at $12 for public repositories on the base tier. None of that changes with a desktop application, and none of it is gated behind one.

Local work is a command line, not an application

The part that does run locally has a name, and it is not an app. The Hub CLI is installed with a single command on macOS and Linux, and once installed, hf --help lists the main commands: auth for signing in, download for pulling files, cache for managing the local cache directory, models and datasets for interacting with repositories, repos for managing them, and jobs for running work on the Hub.

That covers the operations a desktop client would offer, and it covers them better. Downloading a 40 GB checkpoint is a background job with a progress bar, not a window that has to stay open. Clearing a cache that has quietly eaten a disk is one command. Signing in stores a token that the Python libraries then use without further ceremony.

What the command line does not do is browsing. Deciding between two models means reading their cards, checking their licences, looking at the community tab for the issue everyone hit, and opening a Space to try the thing before committing. That is reading work, it happens in a browser, and it takes a long time. The gap between the two halves is exactly where the request for an application comes from.

Comparing the routes to a Hugging Face window

Stated as a window rather than an app, the choices are short.

Route	Setup	Reachable from the switcher	Separate login per window	Fits
Browser tab	None	No	No	Occasional lookups
Pinned tab	One click	No	No	One account, light use
Safari, Add to Dock	Two clicks	Yes	Yes	One account, nothing to install
Chrome, install page as app	A few clicks	Yes	Follows the Chrome profile	Already living in Chrome
Unmaintained native build	Compile it	Yes	Yes	Only with a reason to maintain it
Site to app tool	Pick the URL, build once	Yes	Yes, per app	Two accounts, or several Spaces

Apple documents the route that needs nothing installed, and the mechanism is the reason it is useful here.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

The steps require macOS Sonoma 14 or later. Open the page in Safari, choose File then Add to Dock from the menu bar, type a name and click Add. The result lands in the Applications folder inside the home folder, so Spotlight and the Dock both find it. The settings behind the app's own name in the menu bar are worth a visit: Application Name changes what Spotlight matches, Application URL can be set to the current page so the window opens on the Hub rather than the marketing home page, and turning off navigation controls widens the view. The general shape of what a dedicated window covers is set out on the Features page.

Where separate windows actually earn their place

One window for the Hub is a convenience. Two or more is where the mechanism starts solving a real problem.

The first case is a personal account alongside an organisation seat. Anyone with a PRO account of their own and a Team seat at work has been signed out of one by logging into the other. Two windows with separate cookie stores end that, and the Dock icons can be named after the accounts rather than the site.

The second is Spaces. A demo that is being shown to other people, a leaderboard that is being watched, and general browsing of models are three different jobs. Keeping the demo in its own window means it survives closing the browser, and it cannot be accidentally reloaded while someone is looking at it.

The third is simply protecting long reading. Comparing model cards across eight candidates involves a lot of tabs, and mixing them into a browser that also holds mail and documentation is how the comparison gets lost. Step by step instructions for each route live in the Guide, and the services that people most often promote this way are listed under Supported services.

What to check in the first week

A window that looks correct on the first day can still be the wrong choice by Friday, and four checks settle it before the browser tab is closed for good.

Whether the login survives a restart is the one that matters most. Restart the Mac, apply any pending system update, and see whether the window is still signed in. A route that drops the session every few days is worse than the tab it replaced, and this is the single most common way a wrapper disappoints.

Whether a Space behaves inside the window is the second check. Gradio interfaces use file pickers, drag and drop, audio capture and streaming output, and those are exactly the features that differ between a real browser engine and a thin frame. Load a Space that uploads something and confirm the file dialog opens.

Whether two windows really stay separate is the third, for anyone running a personal account alongside an organisation seat. Sign into both, use them for several days, then confirm that neither has quietly adopted the other's session.

Whether the window survives a redirect is the fourth. A sign in flow that bounces through an identity provider, or a link that jumps from a model page to a Space on a different subdomain, is where a window with a locked down URL scope can strand itself on a blank page.

What a window will not fix

A window is a container, so its limits are worth stating plainly. It does not run models locally. Inference, quantisation and conversion happen through Python, the command line, or a separate application built for that purpose, and wrapping a web page changes none of it.

It does not work offline. Model cards, dataset viewers and Spaces are served, so a window with no network shows nothing, exactly as a tab would. It does not speed up a Space, because that depends on the hardware tier the Space runs on. It does not replace the command line for downloads, and it should not: a browser is the wrong tool for moving tens of gigabytes.

And it does not revive the archived native application. Anyone specifically wanting a menu bar chat interface has to either compile the old code and maintain it, or accept the browser as the route.

What to change first

Install the command line tool for anything that touches files, and stop expecting an application to appear for the browsing half. Then open the Hub in Safari, use File and Add to Dock, name the window after the account rather than the site, and give it a fixed Dock position. When a personal account and an organisation seat both have to stay signed in, a separate Kagemusha window for each is the step that ends the sign out loop.