Using HubSpot as a real Mac app

HubSpot is one of those tools that is open from the first coffee to the last email, and it still does not have a home on a Mac. It is a tab. It gets buried behind a spreadsheet and a Zoom window, the browser is restarted, and the tab comes back somewhere else in the row. A search for a HubSpot desktop app turns up product pages for the CRM, a knowledge base article about an Outlook add-in, and the mobile app listing, none of which is a Mac application.

There is no HubSpot binary to install on macOS. There is, however, one path most write ups miss entirely, and it appears in the App Store listing rather than anywhere on hubspot.com.

The Mac line hiding in the App Store listing

HubSpot publishes mobile apps for iPhone and iPad. On a Mac with Apple silicon, that iPad app can be installed and run directly, because HubSpot left that option switched on. The compatibility block on the App Store listing says so in plain language.

Requires iOS 17.0 or later. iPhone: Requires iOS 17.0 or later. iPad: Requires iPadOS 17.0 or later. Mac: Requires macOS 14.0 or later and a Mac with Apple M1 chip or later. Source: apps.apple.com

Two things follow from that line. The first is that an Apple silicon Mac can have a HubSpot icon in the Dock today, from the Mac App Store, with no third party software involved. The second is the catch: what installs is the iPad application, not the workspace at app.hubspot.com. It shows the mobile interface, sized for a tablet, and it stops where the mobile product stops.

The other catch is the hardware. The line specifies an M1 chip or later. An Intel Mac cannot install it at all, which rules the route out for a large number of machines still doing daily work. Checking takes a second: the Apple menu, then About This Mac.

Worth noting for contrast, since the absence is easy to misread as an oversight. A search of the Mac App Store for software published by HubSpot, Inc. returns nothing. There is no native Mac client, and the iPad build being available is a compatibility setting rather than a Mac product.

What the iPad build gives up

HubSpot's own guidance on browsers draws the line clearly. Its knowledge base states that a supported web browser on a computer is needed for full functionality, and that touch devices such as tablets and phones should use the fully supported iOS and Android apps. Those are two different recommendations for two different classes of device, and the iPad app running on a Mac sits awkwardly between them.

In practice that means the mobile app is excellent for the things it was designed for, which is reading a record, logging a call, checking a deal on the way to a meeting, and replying from the conversations inbox. The work that happens in a browser stays in a browser: building a workflow, laying out an email, editing a list, configuring properties, working through a report. Anyone whose day is the second kind of work will install the iPad app, use it for a week, and go back to the tab.

Which is why the question is not really "is there an app" but "how does app.hubspot.com get a window of its own". That part has answers.

Three routes to a HubSpot window, compared

Route	Setup	What opens	Notifications	Fits
iPad app from the Mac App Store	One install, Apple silicon only	The mobile interface	System notifications	Quick lookups, logging activity
Safari, Add to Dock	Two clicks, macOS Sonoma 14 or later	The full web workspace	System notifications, unread badge	Most work, one portal per app
Chrome, Install page as app	Two clicks in Chrome	The full web workspace	Through Chrome, which must be running	Anyone relying on browser calling or Chrome extensions
Site to app tool	A few minutes, one app per site	The full web workspace	System notifications per app	Several portals, or a shelf of work sites

The Safari route is documented by Apple and takes File then Add to Dock from the menu bar, or the Share button then Add to Dock. What makes it more than a bookmark is the isolation underneath.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. In this way, it keeps your browsing separate, similar to using a Safari profile. Source: support.apple.com

Chrome's version sits in the three dot menu under Cast, save, and share, then Install page as app. Google's help documents both the install and the removal, including the option to delete the app's data from Chrome when uninstalling. The difference that matters for a CRM is that a Chrome app inherits the profile it was created from, so it opens signed in as that profile and it needs Chrome running to deliver anything.

Browser calling is the detail that decides the route

For most websites the choice between the Safari route and the Chrome route is a matter of taste. For HubSpot it is a functional difference, because of calling.

HubSpot's knowledge base lists the supported browsers on a Mac as Google Chrome, Mozilla Firefox and Safari, and notes that Safari does not support inbound browser calling. A window created by Safari's Add to Dock is Safari, with a different frame around it, so the same limitation applies to it.

The consequence is easy to state. Anyone who takes calls inside HubSpot rather than on a phone should build the window from Chrome, or keep calling in a Chrome tab and use a Safari based window for everything else. Anyone who never uses browser calling can ignore the whole issue and take the route with the better isolation.

Extensions follow a similar split. The HubSpot Sales extension for Chrome lives in Chrome, so tracking and logging from Gmail stays a browser job regardless of what sits in the Dock. On the Safari side, Apple documents that a web app's toolbar carries buttons belonging to installed Safari extensions, so a Safari extension does travel into the window.

The desktop pieces HubSpot does ship

It is worth knowing what exists, because searching for a desktop app often surfaces these and they look like an answer until they are installed.

HubSpot's installation guide for its sales tools covers three integrations, and all three are about email rather than about the CRM. There is the HubSpot Sales extension for Chrome, which adds tracking, templates and logging inside Gmail. There is an Office 365 add-in, which does the equivalent inside Outlook on the web and in the desktop Outlook client. And there is an older Outlook desktop add-in, which the same guide marks as being in maintenance mode.

None of them opens a CRM window. They put HubSpot features inside a mail client that is already installed, which is genuinely useful for people who live in email and completely beside the point for people who live in deals, tickets and reports. Someone searching for a desktop app because the CRM keeps getting lost among tabs will install one of these, find that nothing changed about the CRM, and conclude that HubSpot simply has no answer.

The distinction is worth holding onto when reading search results. A page titled around a HubSpot desktop download is usually about one of the email integrations, about the mobile apps, or about the free CRM signup. The thing that is missing, a first party window onto app.hubspot.com, is the one thing the operating system can supply on its own.

What changes when the CRM has its own icon

It becomes an application to macOS. HubSpot appears in the Command and Tab switcher rather than inside a tab strip, which matters when the alternative is hunting through twenty tabs several times an hour. It can be assigned to a specific desktop space from its Dock menu, and it can be added as a login item so it is already open and already signed in at the start of the day.

Notifications arrive as system notifications. Apple's documentation adds one condition that is easy to miss on the first launch: the permission has to be answered inside the new window, because the web app keeps its own settings and inherits nothing from the browser. Granting it there is what enables the unread count on the Dock icon. After that, System Settings then Notifications lists the app under the name given to it, not the site URL, and Focus modes apply to it like any other app.

The window is simpler than a browser. Apple describes the web app toolbar as a streamlined one with back and forward buttons and the Share button, and the app's own settings pane allows the name, URL and icon to be changed later, with the navigation controls hidden entirely if preferred. A CRM record opened in a window with no tab strip, no bookmarks bar and no address bar is a noticeably calmer place to work.

Nothing has to be maintained. The window shows whatever HubSpot ships today. New releases arrive without an installer, and removal is dragging the app from the Applications folder inside the home folder to the Trash, which is where Apple documents that these apps are saved.

Two portals, two icons

Agencies, consultants and anyone with a sandbox alongside a production portal hit the same wall: one browser session holds one signed in identity at a time. HubSpot's account switcher covers the case where several portals sit under one login, and it does not cover the case where the client portal uses a different email address entirely. That is a sign out, a sign in, and a sign out again, several times a day.

Separate cookie stores solve it properly. Apple's comparison of a web app to a Safari profile is exactly the point: the browser can stay signed in to one account while the app in the Dock holds another. Beyond two identities, a tool that turns a website into a standalone Mac app is the dependable answer, since every app it builds keeps its own storage and its own icon, and the Dock itself becomes the switcher. The same argument applies once the list grows past HubSpot to the ticket system, the invoicing portal and the shared inbox, which is the situation described on the Features page and covered by the presets under Supported services.

What to change first

On an Apple silicon Mac, install the iPad app if quick lookups are most of the need, and stop there. If the day is spent in the workspace, open app.hubspot.com in Safari and use File then Add to Dock, unless browser calling is part of the job, in which case build the same window from Chrome instead. For a second portal under a different login, or for a row of work sites that all deserve the same treatment, build them as separate apps with Kagemusha so each one keeps its own sign in.