Arc browser on a Mac, and the habits it leaves behind

Arc still opens on a Mac, still restores every Space, and still feels faster to move around than a window full of tabs. That is exactly what makes the current situation awkward. Nothing is broken, so there is no forcing event, and yet the product's own front page tells visitors something that changes the calculation. The useful question is not whether Arc is dead. It is which of the habits built inside Arc are worth carrying somewhere else, and which ones were specific to that one application.

What the front page actually says

Before reading anyone's opinion, read the notice the product publishes about itself.

FYI: Arc receives Chromium updates only. For active security patches and enterprise-grade protection, download Dia instead.

That sentence appears on arc.net alongside working download buttons for both Mac and Windows. Two facts sit inside it. Arc continues to inherit the security work that flows down from the Chromium project, which is the engine underneath Chrome, Edge, Brave, Vivaldi and most of this category. And the people who build Arc are pointing anyone who wants active patching at a different product.

The background is ownership. The Browser Company, which builds both Arc and Dia, entered an agreement to be acquired by Atlassian, announced on 4 September 2025 on the Atlassian blog. The stated plan in that post is to make Dia the browser for knowledge workers, with security, compliance and admin controls built in. Nothing in it promises new Arc features.

So the honest reading is narrow. Arc is not abandoned in the sense of an app that no longer launches. It is in a state where bugs specific to Arc, rather than to Chromium, are unlikely to attract engineering attention. For a browser that holds session cookies for email, banking and client systems all day, that distinction matters more than it would for a note-taking app. The way Chromium ships security fixes downstream is documented publicly at chromium.org, which makes it possible to understand what Arc does and does not still receive rather than guessing.

Which Arc habits were really about Arc

People who like Arc rarely describe a feature list. They describe a way of working. Separating those two things is what makes a move possible, because most of the habits turn out to be available elsewhere under different names.

Spaces. Grouping sites by context, switching between them with one gesture, and never scrolling a tab strip again. This is the habit that carries best. Almost every tool in this category has a version of it.

The command bar. One keystroke, type a few letters, land on the right place. Chrome, Edge, Vivaldi, Raycast and most app-focused browsers all offer something close.

Tabs that clean themselves up. Arc archives tabs on a timer, so the sidebar does not accumulate. Few other products do this by default, and for some people it is the single hardest thing to replace.

Split view inside one window. Two or three sites side by side, saved as part of the layout rather than arranged by hand each morning.

Write down which of these four actually shaped the day. A person whose answer is Spaces and split view has a wide field of candidates. A person whose answer is automatic tab archiving has a narrow one, and should test that specific behaviour before moving anything else.

Spaces separate context, not accounts

This is the point most comparisons skip, and it decides whether a replacement will feel right or subtly wrong.

Arc's Spaces separate context. Arc's Profiles separate identity. Two Spaces attached to the same profile share one cookie jar, so opening Gmail in both shows the same signed-in account. Getting a second Google account requires a second profile, and moving between profiles is a heavier action than switching Spaces.

That design is fine for a person with one work identity who wants to group by subject. It gets tiring for anyone holding three client Gmail accounts, two Slack workspaces and a personal calendar, because the separation people actually need is per app and per account, not per topic.

What is being separated	Arc's mechanism	What it costs
Topic or project	Spaces	Cheap, one keystroke, sessions shared
Identity or account	Profiles	Heavier switch, full session separation
A single site kept always open	Pinned tab in a Space	Shares the session of that profile

A browser built around per-app containers inverts this. Each app gets its own cookie jar by default, so three Gmail accounts stay signed in at once and a link lands in the account that owns it. The trade is that grouping by topic becomes a second-order feature rather than the main idea. Neither model is better in the abstract. The right one is whichever matches the sentence that describes the last time tooling derailed an afternoon. If that sentence contains an account name, containers matter more than Spaces. The way per-app separation is arranged is set out on Workspaces.

What to check before moving anything

Four checks, in this order, because each one is cheaper than the one after it.

Engine. Chromium keeps the extensions and the enterprise web app compatibility. WebKit and Gecko alternatives exist and are worth considering, but changing engine and changing tool at the same time produces two variables and no way to tell which one caused a problem.

The three extensions that cannot be missing. Usually a password manager, a content blocker, and one thing specific to the job. Confirm all three exist for the candidate before importing anything.

Sessions that survive a restart. Sign into every account, quit, reopen. Anything that asks for a password again will ask again every week, and that is the failure that sends people back.

The way out. Bookmarks export to HTML, passwords export to CSV or live in a separate manager, and the list of apps can be rebuilt from URLs. A tool that cannot hand data back is a tool that has to be trusted permanently, which is a large thing to promise after the last few years in this category.

Running these four on a Saturday costs about an hour and removes most of the risk of the move. Which everyday services are already covered can be checked on Supported apps, and how candidates in this category differ on account handling and pricing is laid out in the comparison with Wavebox.

Staying on Arc on purpose

Leaving is not the only defensible answer. Continuing to use Arc is reasonable under stated conditions, and stating them is what turns drift into a decision.

It holds up well for browsing that does not carry credentials: reading, research, personal use, a machine that is not the one handling payroll or client systems. It holds up less well as the only browser on a work machine where every login lives, because Arc-specific problems now have no clear owner.

A common middle position is to keep Arc for the reading half of the day and move the accounts half into something with per-app separation. That costs a little context switching and buys a clean boundary. It also has a practical benefit: the new tool gets tested with real work for a few weeks while nothing critical depends on the switch being perfect.

Whatever the choice, set a review date rather than leaving it open. Three months is a reasonable interval. The things to look at then are whether the download page still exists, whether the underlying Chromium version has fallen behind the current stable release, and whether anything in daily use has started to break. Pricing models in this category also change, so the cost side is worth rechecking at the same time on Pricing.

The tab archiving habit, and what replaces it

Of the four habits, automatic archiving is the one people underestimate until it is gone. Arc clears tabs on a timer, so the sidebar returns to a short list every day without anyone deciding what to close. Remove that and a familiar pattern comes back within a fortnight: forty open tabs, none of them closable, because each one might still be needed.

There are three ways this gets solved elsewhere, and they suit different temperaments.

The first is to keep only permanent things in the sidebar. Sites that get opened every single day become fixed entries, and everything else opens in ordinary tabs that can be closed without thought. This works when the daily set is genuinely stable, which for most desk work it is: mail, chat, calendar, one or two documents tools, one or two client systems.

The second is to move the archive out of the browser entirely. Anything worth keeping goes to a read-later service or a notes tool in one keystroke, and the tab closes. The browser stops being storage, which is what it was never good at.

The third is to schedule the cleanup rather than automate it. A recurring reminder once a week, five minutes, close everything that is not a fixed entry. Less elegant than a timer, and it survives any change of tool.

Choosing one of these before the move matters more than it sounds, because the habit was doing real work. Replacing the tool without replacing the habit is how people conclude that a perfectly capable alternative feels cluttered.

Rebuilding the layout so the first week is not painful

Most failed migrations fail in week one, and usually for the same reason: everything gets imported at once, the new window looks like a worse version of the old one, and the comparison is made against three years of accumulated tuning.

A better sequence is to rebuild rather than import. Start with the five or six things opened every day and nothing else. Put them in a fixed order and learn that order. Add the next thing only when its absence is actually felt, which for a surprising number of pinned sites never happens.

Bookmarks can come across in bulk, since they sit in a folder tree and cost nothing until they are searched. Extensions should not. Install the three that were identified as necessary, then wait. Extensions carried over out of habit are a common source of the vague slowness that gets blamed on a new browser.

Keyboard shortcuts deserve fifteen minutes of deliberate attention on day one. The muscle memory built in Arc will fire constantly, and every miss is a small irritation that accumulates into a verdict. Finding the equivalent for switching, for the command bar, and for jumping to a specific app removes most of that friction before it forms an opinion.

Give the trial a fixed length, ideally two weeks, and write down in advance what would count as failure. Without that, the decision gets made by whichever day happened to go badly.

What to change first

Name the unit of separation in one sentence, by topic or by account, because that single choice removes most candidates. Then run the four checks above on one candidate for a week with real work, not a demo. If the unit turns out to be account or app rather than topic, start with SpaceDeck and see whether per-app containers remove the friction that Spaces could not.