Aircall for Mac: the phone panel out of the browser

Most searches for a desktop version of a web service are answered with a yes or a no. This one is answered with a split. Aircall publishes a genuine Mac application for taking and making calls, and publishes nothing at all for the side of the product where numbers, users, routing and recordings are configured. So a team running Aircall on Macs ends up with one job in the Dock and the other job buried in a browser tab, which is a strange arrangement given that both are the same product. This covers where the official Mac build comes from, which half has no app, and what to do about the half that does not.

Where the official Mac app comes from

Aircall's download page lists the desktop product as Aircall Workspace for desktop, with separate Mac builds for Apple Silicon and for Intel, plus a Windows build. The page includes a warning that is easy to skim past and expensive to ignore: pick the correct Mac version, checked from the Apple menu and then About This Mac. Downloading the wrong architecture is the most common reason a first install goes badly.

The same page states the platform limit directly. The desktop app does not currently run on Linux or Chromebooks. For a support team on mixed hardware that single sentence decides the whole approach, because whatever route the Chromebook users take will end up being the route everyone is trained on.

The managed install has a higher floor

Aircall lists a second set of downloads under a heading for IT installs, meant for deploying across a company. Those are a .MSI for Windows 10 and later, and .PKG packages for Mac, one for Apple Silicon and one for Intel, requiring macOS 13 and later.

That is worth reading twice, because it is a higher requirement than the ordinary download implies. A Mac too old for macOS 13 may still be perfectly usable for calls, but it is outside the packaged deployment path, which puts it back on the browser. Anyone auditing a fleet before a rollout should check that floor against the oldest machine in it rather than against the newest.

Mobile is covered separately: iPhone from iOS 16.1 or later and Android from 9 or later, with CarPlay supported on iPhone. The web app, by contrast, is documented as not currently supported on iPad, so a tablet is either a phone app or nothing.

The half of Aircall with no Mac app

Aircall runs two distinct web surfaces. One is the Workspace, the agent side, where calls and messages happen. The other is the Dashboard, the administrative side. The Workspace is the thing the Mac app is built from. The Dashboard is not packaged for the desktop at all.

The distinction matters because the Dashboard is where the decisions with money attached get made. Each plan includes one local or toll-free number and additional numbers are priced at US$6 per month each, so the page listing numbers is a page with a running cost attached to it. Recording retention differs by plan as well, with the entry plan documented as up to one year by request and six months available in the dashboard, and the tier above it unlimited by request on the same six month window in the interface.

Seat minimums sit in the same place. Aircall's plan comparison lists a minimum of three users on its Essentials and Professional plans and twenty five on Enterprise, with Essentials at US$30 per license per month and Professional at US$50 per license per month when paying annually, which the pricing page notes saves twenty five percent over monthly billing. None of those numbers are visible from inside the Workspace app. Somebody has to open a browser.

The softphone is on every plan, the admin work is not optional

Aircall's plan comparison lists a softphone for desktop, Android and iOS as an included capability on every tier, which is why the calling app is the part that feels solved. The administrative surface is the part that quietly accumulates work. Unlimited inbound and internal calls are included across plans with toll-free excluded, and outbound rates are quoted rather than published, so anyone tracking spend is reading a page in a browser rather than a screen in an app. Analytics retention is capped at six months on the two lower tiers and unlimited on Enterprise, which means the person who exports reports has a recurring deadline and a recurring destination.

Who actually needs this

The person who lives in the Workspace all day should install the official app and stop reading. The people this affects are the ones who visit the Dashboard several times a week: an operations lead adjusting call routing, a team manager checking analytics, a finance owner reconciling numbers against invoices. For them the Dashboard is not an occasional detour, it is a recurring destination with no icon.

The three routes to a window

Route	Requirement	Session	Aircall's guidance
Official Mac app	Apple Silicon or Intel build, macOS 13 for the .PKG	Its own	Recommended for the Workspace
Safari, Add to Dock	macOS Sonoma 14 or later	Separate from Safari	Not the documented browser
Chrome, Install page as app	Any recent Chrome	Shared with the Chrome profile	Chrome is the recommended browser

Aircall's own note on the web app is short and specific: no install needed, Chrome recommended. That recommendation should carry weight for the Workspace, because a softphone leans on browser audio handling in ways a settings page does not. For the Dashboard, which is forms and tables and charts, the recommendation matters far less.

Apple documents the Safari route as available from macOS Sonoma 14 onward. File then Add to Dock, or the Share button then Add to Dock, saves the page as a web app into the Applications folder inside the home folder, openable from the Dock or Spotlight. Apple states that it functions independently of Safari and shares no browsing history, cookies, website data or settings with it.

Chrome's route, in its own help pages, is More, then Cast, save, and share, then Install page as app, with an Install button appearing in the address bar on some sites. The installed app belongs to the Chrome profile that made it, which means the Aircall session from that profile carries straight over. That removes a sign-in step. It also removes the separation, which matters as soon as a second account enters the picture.

Neither browser route was built for making several of these. A tool designed for the job sets the name, the icon and the starting address in one pass, and Supported services shows the kinds of business tools that most often end up treated this way.

Building the window on the right page

The Dashboard is not one page. Numbers, users, teams, routing rules, analytics and billing are separate sections, and the section someone opens is a function of their role rather than of the product.

Open the section first, then build the window from that page. An operations lead whose recurring task is call routing gets a window that lands on routing. A finance owner gets one that lands on billing. Naming it after the task rather than after the product is what makes the application switcher useful, because the switcher can then offer the actual job instead of offering Aircall twice.

Apple's settings panel makes a wrong choice cheap to fix. Opening the web app, clicking its name in the menu bar and choosing Settings exposes an Application Name field, an Application URL field with a Set to Current Page button, and an Icon picker that accepts any image. Navigate to the correct page, press Set to Current Page, done. The icon is worth setting deliberately, because the Workspace app and a Dashboard window are otherwise two identical logos sitting next to each other in the Dock.

What to check before trusting a call window

If the window being built is the Workspace rather than the Dashboard, three things deserve a test call before anyone relies on it.

Microphone permission is the first. Apple's documentation states that a Safari web app shares no settings with Safari, and permissions are settings. A microphone permission granted to the site in a browser earlier should not be assumed to apply inside a new window, so it is worth confirming that the prompt appears and that audio works both directions before a shift starts.

Notifications are the second, and Apple is precise about them. To get an unread count as a red badge on the Dock icon, the site's notification request has to be answered inside the web app, not in Safari. Answering it in the browser does not carry over. Once answered in the web app, it shows up in Notifications settings listed under the web app's name rather than under the website's address.

The Chrome extension is the third and it is the one people miss. Aircall publishes a separate Chrome extension whose stated purpose is click to dial and the Power Dialer. An extension lives in a browser, not in a standalone window, so a phone number sitting in a CRM page in Chrome is still dialled from Chrome. That is an argument for keeping the browser in the workflow rather than an argument against the window, and the same logic applies to Aircall's integrations with Salesforce, HubSpot, Zendesk and Front, which put the dialling action inside those tools.

Links behave the same way everywhere. An Aircall address arriving by email opens in whatever browser macOS is set to use, not in the new window. That is an operating system routing rule. The Guide covers how window behaviour is configured once more than one of these exists.

Two accounts at the same time

Consultants, agencies and anyone supporting a client's Aircall alongside their own hit a wall the official app does not solve. One installed application runs one session in one storage area, so a second company means signing out and back in.

Two separate windows, each holding its own session, keeps both alive. The Safari route gives that separation by default, since each web app is independent. The Chrome route gives it only with a second Chrome profile, because the app inherits whichever profile created it. A purpose built tool gives it per app without the profile bookkeeping. Which of the three is right depends on how many there will be: one is a menu command, four is a chore.

Naming them so the switcher stays useful

Two windows of the same service are worth naming for what distinguishes them, not for what they share. A client name, a company name, or the role being performed reads correctly in the application switcher at speed. Aircall alongside Aircall does not, and neither does Aircall and Aircall 2. The icon carries the same load: two identical logos in the Dock force a click to find out which is which, which is the exact cost the window was created to remove.

What to change first

Install the official Mac app for the Workspace, choosing the Apple Silicon or Intel build that matches the machine, and leave that part alone. Then build one window for the Dashboard section actually visited each week, named after that task rather than after the product. When the count passes two, a tool such as Kagemusha keeps them consistent instead of rebuilt by hand.