Miro for Mac: a board window that stays where you put it

Searching for Miro for Mac turns up a download page, an App Store listing, a help centre note, and half a dozen mirror sites repackaging the same installer. The download exists and it is worth having. The part that search results do not answer is what happens after it is installed, which is that one application opens on one dashboard under one signed in account, while the work itself lives on specific boards with specific URLs. That gap is the reason people keep searching after the app is already in the Dock. This covers where the real download lives, what installing it settles, and what to do about the part it leaves open.

Where the Mac download actually comes from

Miro lists every client in one place, on its apps page. The desktop section offers two separate Mac builds, one for Apple silicon and one for Intel, alongside a Windows 64 bit installer and an entry for the Microsoft Store. Both Mac builds are disk images served from desktop.miro.com, Miro's own host.

The two files are not the same size. The Apple silicon image is roughly 114 MB and the Intel image roughly 121 MB, and both were published on 4 August 2026. Those numbers matter for two reasons. The first is that picking the wrong one is a common way to end up with a slow running copy on a newer Mac, so it is worth checking the chip in About This Mac before clicking. The second is that a recent publication date answers the question people usually ask next, which is whether the desktop build is still maintained or quietly abandoned.

The App Store is not the source

The App Store listing that ranks for this query is a real Miro product, published by RealtimeBoard Inc., but its compatibility panel lists iOS 17.0 or later, iPadOS 17.0 or later, and visionOS 1.0 or later. Mac is not in that list. Apple silicon Macs can run many iPhone and iPad apps, but only when the developer opts in, and this listing shows no Mac entry.

The practical consequence is that the Mac app does not update through the App Store and is not tied to an Apple ID. Anyone who audits installed software by looking at a purchase history will not find it. The same goes for the third party download mirrors that rank well for this query. They repackage a file that Miro serves directly, and going to the source is the shorter path.

What installing it settles, and what it does not

The official app gives Miro a Dock icon, a place in the application switcher, and a window that can be closed without touching anything else in the browser. For most people that is the whole request behind the search, and the installer delivers it with no configuration.

It also gives Miro a session of its own. Signing into the desktop app is a separate step from being signed into miro.com in Safari or Chrome, and signing out of one does not sign out of the other. This surprises people who expect the app to inherit a browser session, and it is the same separation that makes the routes further down this page work.

What it does not settle is where the window opens. One installed application is one process with one storage area, which means one account at a time and one starting screen. Launching it lands on the dashboard, not on the board that a particular piece of work happens on.

One thing to check before installing

On a managed work Mac, dragging an application into the system Applications folder can prompt for an administrator password, and some configurations refuse installers that did not come from the App Store. If that is the situation, the browser built routes below avoid the question entirely, because Apple's documentation states that a Safari web app is saved to the Applications folder of the home folder rather than a system location. Nothing is installed machine wide and no password is requested.

The unit of work is a board, not the dashboard

Miro's useful unit is almost never the home screen. It is a specific board, and often a specific frame inside it, and every one of those is addressable by its own URL. A retro board, a customer journey map, and an architecture diagram are three different jobs that happen to be hosted by the same product.

This is where a single window starts to feel wrong. The application switcher can get a person as far as Miro, but not as far as the thing they were doing, so every return trip becomes launch, wait for the dashboard, scan a grid of thumbnails, click through. Done four or five times a day that is not a catastrophe, but it is friction that nothing requires.

The free plan sharpens the point. Miro's pricing page states that the Free tier keeps 3 editable boards, with the most recent three remaining editable, and includes 7,000 or more templates and 250 or more integrations. Someone on that plan is working on a very small number of specific boards, which is exactly the case where a dashboard is the least useful thing to open on. Paid tiers remove the board limit, at 8 US dollars per member per month for Starter and 20 US dollars per member per month for Business, both billed annually, with Enterprise quoted individually from 30 members. Removing the limit does not change the shape of the problem. It multiplies the thumbnails on the dashboard.

When one signed in session is not enough

Three situations come up often enough to name, and the official download does not address any of them.

The first is more than one account. Consultants and agency staff frequently hold a personal or company Miro alongside a client's workspace, and they need both alive at the same time rather than a switch between them. One installed app means signing out and back in.

The second is a facilitation session. Running a workshop while keeping a private planning board open is two windows of the same product, doing different jobs, where mixing them up in front of an audience is the failure mode.

The third is simple window discipline. A board that is a reference document and a board that is a live meeting surface should not be interchangeable in the switcher, because holding them apart is the whole point of having two of them.

Each of these is a request for more windows, not for a different application. A single desktop client cannot satisfy it, and recognising that saves a lot of time otherwise spent looking for a setting that does not exist.

The four routes compared

Route	Sessions	Opens on	Requirement
Official desktop app	One at a time	The dashboard	Install per machine
Safari, Add to Dock	Separate per app	Any URL chosen	macOS Sonoma 14 or later
Chrome, Install page as app	Shared with the profile	Any URL chosen	Chrome installed
A site to app tool	Separate per app	Any URL chosen	The tool installed

Both browser routes are documented by their makers. Apple's support note explains that from macOS Sonoma 14 onward, File then Add to Dock saves a webpage as a web app that functions independently of Safari, sharing no browsing history, cookies, website data, or settings with it. The settings panel of the resulting app exposes an Application Name field, an Application URL field with a Set to Current Page button, a custom icon, a toggle for navigation controls, and a Privacy tab for clearing that app's cookies and caches.

Chrome's route is described in its help pages as More, then Cast, save, and share, then Install page as app. The installed app belongs to the Chrome profile that created it, so the Miro session from that profile carries straight over. That removes a sign in step and removes the isolation a second account needs, which makes it the right choice for one account and the wrong one for two.

Building a window per board

The technique worth the effort is choosing the URL deliberately. Open the board that a particular job starts from, then build the window from that address rather than from miro.com. The result opens where the work is, every time, with no dashboard in between.

Naming matters more here than for a service with a single surface. Three windows all called Miro are three identical Dock icons and three identical switcher entries, which is worse than one window. Named after the job, such as Roadmap or Client Retro, they behave like separate applications, because functionally that is what they now are.

Which boards deserve one

Not every board does, and building windows for all of them recreates the dashboard problem in the Dock. Two questions filter the list quickly.

The first is frequency. A board opened several times a day earns a window. A board opened once a fortnight does not, and is better left to the dashboard or a bookmark. The threshold is roughly whether the path to it is being retyped or re-navigated from memory rather than clicked once.

The second is whether the board is the destination or a waypoint. A sprint board that a stand up starts from is a destination. A board that only ever gets reached by following a link from a ticket is a waypoint, and a window for it will sit unused while the link keeps being the faster route.

Three windows is a common landing point for one person: the board a daily ritual runs on, the board a current project lives on, and a general Miro window for everything else. Past about five, the switcher stops being an advantage, which is the same reason the dashboard stopped being one.

This is also where the browser routes show their seams. Safari builds one web app at a time through a menu, with the icon replaced by hand afterwards. Chrome ties each one to a profile, which is fine until two accounts are involved. For one window neither is a problem. For five windows across two accounts the repetition is the problem, and that is the shape of work a purpose built tool exists for. Supported services lists the sites most often treated this way, and the Guide covers how window behaviour and icons get set.

What does not follow the window

Three things reliably surprise people on the first day, and all three are cheap to test before a routine gets rebuilt.

Extensions do not come along automatically. A password manager or a clipper that was present in the browser is absent from a Safari web app until it is enabled in that app's Extensions tab. For Miro the password manager is the one that gets noticed, because the first sign in happens in a window that has never seen the vault.

Notifications are configured per window. Apple's note is specific that a web app appears in Notifications settings only after the site's permission prompt is answered inside the web app rather than in Safari, and that it is listed under the app's name rather than the site's URL. Answering the prompt in the wrong place is the usual reason a badge never appears.

Sign in state is genuinely separate on the Safari route, which is the point when two accounts are in play and an extra step when only one is. A window built from Chrome inherits the profile's session instead. Neither is better in the abstract. They are answers to different questions.

What to change first

Install the official build from Miro's own apps page, matched to the chip in the Mac, and use it as the general purpose window. Then pick the one or two boards that get opened several times a day and give each of them a window of its own, named after the job rather than the product. If that ends up being more than two windows, or spans two accounts, Kagemusha is built for exactly that repetition.