An Intercom desktop app: support conversations in one window

Searching for an Intercom desktop app usually starts the same way. The Inbox lives in a browser tab, that tab sits beside fifteen others, and a conversation goes unanswered because the tab was closed during a cleanup. The question behind the search is rarely about how software is distributed. It is about whether support work can have a window of its own on a Mac, with its own icon and its own notification settings, separated from everything else happening in the browser.

What Intercom actually publishes

Intercom publishes one mobile app on the App Store, called Intercom Conversations, under the seller name Intercom, Incorporated. The listing states the compatibility plainly: iPhone requires iOS 15.1 or later, and iPad requires iPadOS 15.1 or later. There is no macOS entry. The app is free, the listed language is English, the download is roughly 53 MB, and version 5.0.18 shipped in September 2026. At the time of writing the listing shows 171 ratings averaging 2.1 out of 5.

The app describes its own scope in one sentence: it lets teammates access all their Intercom conversations and customers from an iPhone or iPad. That is a companion for time away from a desk, not a replacement for the full Inbox.

For a Mac, that leaves the browser. The Inbox is a web application, and on macOS it runs in Chrome, Safari, Edge, Brave or whichever browser a team already uses. Apple silicon Macs can run some iPhone apps, but only when the developer opts in, and this listing does not show macOS. Running an unlisted mobile build to handle customer conversations trades a known setup for an unknown one.

So the honest framing of the search is this. There is no desktop binary to install, and there does not need to be. What is missing is not an application. What is missing is a window that belongs to support work alone, and macOS has two built in ways to create one.

Where the mobile app still fits

The mobile app is worth keeping even once a desktop window exists, because the two cover different moments. The listing describes it as a way for teammates to reach conversations and customers from an iPhone or iPad, and that is a fair description of what it is for: seeing that a queue is growing while away from a desk, answering something short, and checking who is assigned to what before a handover.

What it does not replace is the working session. The low average rating on the listing, 2.1 across 171 ratings, mostly reflects reviewers asking it to do desk work on a phone screen. Reviews on the page complain about the handling of saved replies, about copying a fragment of a conversation rather than the whole body, and about missing keyboard shortcuts on an external keyboard. Those are all desk tasks. Read that way, the ratings are less a verdict on the app than a signal about which device each job belongs on.

The practical split is therefore clear. Phone for awareness and short replies during a commute or an evening on call. Mac for the shift itself, in a window that stays open, holds the right session, and raises a badge when something arrives. Deciding this deliberately also settles a question teams argue about: whether notifications should reach personal phones outside working hours. With a separated Mac window carrying the alerts during a shift, the phone can be left silent without anything going unseen.

Why a browser tab is the wrong container for an Inbox

A support Inbox has properties that make it a bad neighbour for ordinary tabs. Three of them cause most of the friction.

The first is lifetime. Tabs are disposable by design. People close them in batches, restart the browser after an update, and reopen a session without noticing which tab did not come back. An Inbox is the opposite: it should be open for the whole working day. Putting a long lived thing inside a disposable container guarantees it will be thrown away by accident.

The second is identity. A tab has no separate presence in the Dock, no separate entry in the app switcher, and no separate notification settings. macOS treats every notification from every site in that browser as coming from the browser. Turning off noise from one site means digging through browser settings rather than system settings, and there is no way to give a support queue louder treatment than a marketing dashboard.

The third is session boundaries. Support agents frequently hold more than one identity: a staff account in the workspace, a test account used to see the Messenger as a customer sees it, and sometimes a second workspace for a different product. In one browser profile these share cookies, so the second login evicts the first. The workaround is a private window, which forgets everything the moment it closes.

None of these are Intercom's doing. They are properties of tabs. A window that is not a tab fixes all three at once.

Two built in ways to give the Inbox its own window

macOS ships two mechanisms, and both take under a minute. Neither requires buying anything.

Safari has carried the feature since macOS Sonoma 14. Open the Inbox in Safari, choose File then Add to Dock from the menu bar, type a name, and click Add. Apple's documentation describes the result directly: a web app functions independently of Safari, sharing no browsing history, cookies, website data or settings with it. The app lands in the Applications folder inside the home folder and opens from the Dock or Spotlight. Its settings panel exposes an Application Name field, an Application URL field with a Set to Current Page button, an icon picker, and a toggle for the navigation controls in the toolbar.

Chrome has an equivalent. From the menu at the top right, open Cast, save, and share, then choose the option to install the page as an app. On some sites an install icon also appears at the right of the address bar. The resulting window is backed by the Chrome profile it was created from, which matters for the account separation discussed below.

The two differ in ways that decide which one fits a given team.

	Safari web app	Chrome installed app
Requires	macOS Sonoma 14 or later	Chrome on any supported macOS
Engine	WebKit	Chromium
Cookies and history	Separate from Safari	Shared with the Chrome profile used
Extensions	Safari extensions only	Chrome extensions from the profile
Set a fixed start URL	Yes, via Application URL	Via the installed app's start URL
Dock badge for unread items	Yes, when notifications are granted in the web app	Through Chrome notification permissions

Teams that depend on Chrome extensions for their support stack, such as a clipboard manager, a translation tool or a screen recorder, generally want the Chrome route. Teams that want the Inbox walled off from every other logged in session generally want the Safari route, because the separation is the default rather than something to configure.

Keeping workspaces and test accounts apart

The account problem deserves its own treatment, because it is the one that quietly costs the most time.

With the Safari route, the separation is automatic. The web app keeps its own cookies and website data, so Safari itself can stay logged in as a customer test account while the web app stays logged in as staff. Viewing the Messenger from the customer side no longer means logging out of the Inbox. For a third identity, add a Safari profile and create a second web app from inside it.

With the Chrome route, the order of operations matters. Create the Chrome profile first, sign into the workspace inside that profile, and only then install the page as an app. An app created from the wrong profile will keep pointing at the wrong session, and the fix is to remove it and install it again from the right one. Naming the profiles after the workspace rather than after a person avoids most mistakes here.

Two more details prevent avoidable errors. Give each window a distinct icon, because two identical icons in the Dock is how a reply intended for an internal test lands in front of a customer. And set each window's start URL to the view actually used, such as a specific Inbox view rather than the workspace home, so that launching the app lands on the right queue instead of somewhere one click away.

Deciding what the window is allowed to interrupt

Once the Inbox is an app, notifications become a per app decision instead of a per browser one. Apple's documentation notes that a web app's Dock icon can show the number of unread notifications as a red badge, and that this works when the permission prompt is answered inside the web app rather than in Safari. The app then appears in System Settings under Notifications, listed by the name given to it rather than by a URL, where banners, sounds and Notification Center behaviour can be set individually.

The useful part is that the decision can now differ per window. A first response queue with a target response time earns banners and a sound. A secondary workspace checked twice a day earns a badge and nothing else. A window opened only for reporting earns nothing at all. Inside a single browser this distinction cannot be expressed, which is why so many teams end up either drowning in alerts or turning them all off.

Apple's documentation also covers adding a web app as a login item so that it opens automatically at sign in. For a queue that is meant to be staffed from the start of a shift, that removes the step where somebody forgets to open it.

Which windows are worth creating

The pattern generalises beyond Intercom, and the test is simple: how many times a day does the page get reopened. A tool opened five or more times a day, kept open for hours, and rarely useful beside another tab is a candidate. A tool opened once a week is fine as a bookmark.

Support work usually produces two or three candidates rather than one. The Inbox itself, the help centre editor used to write and update articles, and the reporting view checked at the end of a shift all meet the test on a busy team. A list of services that people most often split out this way shows the same shape repeating across email, chat, calendars and dashboards: long lived, frequently reopened, and better off with their own notification settings. The feature overview covers what a separated window can be configured to do, including fixed start URLs, per app extensions and tab visibility, and the setup guide walks through creating the first one.

One caution worth stating. Creating a window for every tool recreates the original problem in the Dock instead of the tab bar. Three to five separated windows is where most people settle. Everything else stays in the browser, where it belongs.

What to change first

Start with one window for the Inbox, pointed at the view actually worked from, with notifications granted inside that window and a distinct icon in the Dock. Run it for a week before separating anything else, because a week is long enough to see whether the interruptions landed in the right place. If the setup earns its keep and a second or third window starts to look worthwhile, Kagemusha covers the case where more than a handful are needed.