Arcの代わり: how to decide what you need

A shortlist is easy to produce and hard to finish. Ten names, all plausible, all with screenshots that look calm and organised, and no obvious way to rank them. Reviews do not help much either, because each one was written by a person with a different daily shape of work. What settles this is not more reading. It is a set of filters applied in a fixed order, where each filter removes candidates for a stated reason, and the order matters because the cheap filters go first.

Name the unit before naming the product

Every tool in this category separates things. They differ in what they separate by, and that single decision eliminates more candidates than any feature comparison.

There are four common units.

By account. Two Google accounts, two Slack workspaces, a client's Notion and your own. The requirement here is separate cookie jars that stay signed in at the same time.

By project or client. Everything for one engagement in one place, regardless of which service it lives in. The requirement is grouping across services, plus fast switching between groups.

By mode. Work and personal, nothing finer. The requirement is small, and the built-in profile support in a mainstream browser usually satisfies it completely.

By app. One window per service, always in the same place, treated like a native application. The requirement is a persistent window per app and a way to reach each one directly.

These are not interchangeable. A tool built around account separation handles projects awkwardly, and a tool built around per-app windows handles a person with only one Google account as overkill. Writing the unit down in one sentence before opening any download page is the highest leverage minute in the whole process, because the rest of the filters are only meaningful once the unit is fixed.

The way to find the unit is to look at the last interruption. When the day was last derailed by tooling, was the cause a wrong account, a hunt for something belonging to one client, or a window that was buried? The answer names the unit.

Filter one: who maintains it, and how that gets checked

This filter goes first because it is fast and because it removes candidates permanently rather than by preference.

Three checks take about ten minutes total.

Look for release notes with dates on them, and see how far apart the last three are. A gap of months in a Chromium based product is worth noticing, because the security work in that family arrives through the engine and has to be picked up by each downstream build. The Chromium project publishes its release and security process openly at chromium.org, which makes it possible to see how the pipeline works rather than guessing.

Check who owns the project now. Ownership changes are normal and are not by themselves a warning, but they do predict where attention goes. The relevant recent example is directly on point for this search: The Browser Company, which makes Arc, was acquired by Atlassian in a deal announced on 4 September 2025 and completed on 21 October 2025, and its front page now directs people wanting active security patches to its newer browser instead. Arc still runs and still receives Chromium updates, which its own site states plainly.

Check whether the project has a way to be paid. Free with no business model is not a flaw, but for open source projects it means the schedule depends on volunteers, and for commercial products with no visible pricing it usually means a change is coming. Neither is disqualifying. Both are things to know before importing years of bookmarks.

Filter two: the engine underneath decides the small annoyances

Three engines are in play, and the choice sets the boundaries of what can be fixed later by configuration.

Engine	Examples in this category	What follows from it
Chromium	Wavebox, Shift, Vivaldi, most app aggregation browsers, Arc itself	Chrome extensions work, corporate web apps are usually tested against it, memory use per window is the usual complaint
WebKit	Orion by Kagi	Uses the same engine family as Safari, supports extensions from several stores, battery behavior on Apple silicon tends to be favorable
Gecko	Zen, Floorp, Firefox itself	Firefox extensions work, a genuinely independent codebase, occasional sites that only test against Chrome

The practical consequence is narrow but real. Enterprise single sign-on portals, video conferencing, banking and payroll sites, and internal tools built by a small team are frequently tested against Chrome and Safari only. Anyone whose paycheck depends on a site like that should test it on day one rather than on the day it matters. Firefox publishes its own compatibility and troubleshooting material at support.mozilla.org, and Chrome does the same at support.google.com/chrome, which is enough to check a specific complaint quickly.

Extensions deserve one line of their own. A password manager, an ad blocker and a work required extension are the three that most people cannot give up. Confirming those three exist for the engine, before anything else, avoids a common late stage reversal.

Filter three: how it is paid for, and what the free tier keeps

Price is the filter people apply first and should apply third, because it only becomes meaningful after the unit and the engine have narrowed the field. The models in this category differ more than the numbers do.

Model	What it looks like in practice	Examples with published prices
Free and open source	No account required, community maintained, features arrive irregularly	Ferdium, Zen
Free with a paid optional tier	Full browser at no cost, extras behind a subscription	Orion by Kagi, Vivaldi is free outright
Free tier with hard limits	Usable forever, capped on the axis that matters	Shift, which publishes a free plan capped at 5 spaces and 10 apps per space, with Advanced at 199.99 dollars per year
Subscription with a small free tier	Trial first, then a monthly or annual charge	Wavebox, which publishes a free Basic plan and Pro at 8.33 dollars per month paid annually, plus Teams at 12.50 dollars per user
Free browser, paid AI layer	The browser itself costs nothing, the assistant is the product	Dia, which publishes a free plan plus 20 dollars and 100 dollars per month tiers

Two things are worth reading out of that table. First, a free tier with hard limits is only free if the limits sit above actual usage, so the number of accounts and services counted during the inventory decides whether it is genuinely free. Second, an annual only plan and a monthly plan are different risks, not different prices: one is cheaper per month and costs more to abandon.

The comparison worth making is against zero. Browser profiles are free and already installed on every Mac. A paid tool in this category needs to justify itself against that baseline, not against the other paid tools. Looking at a published Pricing page next to what profiles already do is the honest version of that comparison.

Filter four: what leaves with you

The last filter is about the exit, and it is the one most people skip.

Bookmarks and history should export to a standard file. Passwords should already live in a password manager or in the system keychain rather than in the browser, which makes this question moot and is worth doing regardless.

Sessions do not export. Moving to a new tool means signing in to every service again, which is an afternoon, and it means any service using hardware keys or authenticator apps needs those to hand. This is the real cost of a switch and it is paid once per switch, which is an argument for making fewer, better considered switches.

Settings never export across products. Pinned sets, groupings and shortcut layouts get rebuilt by hand. That is not a reason to stay anywhere, but it is a reason to rebuild deliberately rather than recreating a layout that had already grown past usefulness.

Two conditions that get remembered too late

Two requirements rarely make it onto the shortlist criteria, and both tend to surface in week two, after the migration work is already done.

The first is the machine. Keeping eight services signed in at once means eight rendering contexts, and on a Chromium base that is memory. A Mac with 8 GB runs this fine with six or seven light services and starts swapping with fifteen heavy ones, particularly when a video call and a large spreadsheet are among them. Tools in this category differ on how they handle the idle ones: some put unused services to sleep and reload them on click, which trades a second of wait for a large reduction in memory. Anyone on a smaller machine should treat that behavior as a hard requirement rather than a nice extra, and should check it by opening everything at once and watching Activity Monitor for ten minutes.

The second is the second device. A setup that only exists on one Mac is fine right up until a Windows machine at a client site, a shared computer, or a phone enters the picture. Some candidates are macOS only. Some ship on Windows and Linux as well. Very few have a phone app, and for most people that is acceptable because the phone is already handling accounts its own way through native apps. What matters is knowing which of these is true before the setup becomes load bearing, not after. If a second platform is genuinely required, that single condition cuts the candidate list faster than any other filter here, which is an argument for asking it early rather than treating it as a detail.

The one week test that settles it

Two candidates survive the filters in most cases. A week of real work separates them, provided the test has marks rather than impressions.

Day one, set up only the services used daily. Not everything, only the ones opened before lunch. If the setup takes more than 30 minutes, that is a result worth recording.

Day one also, run three checks in this order: the work single sign-on portal, a video call, and the three must-have extensions. A failure here ends the trial early and saves the rest of the week.

Days two to four, count two numbers only. How many times a link opened under the wrong identity, and how many times something had to be hunted for. Both should drop compared with the previous setup. If they did not, the unit was probably named wrong, and going back to the first filter beats trying a third product.

Day five, restart the Mac. Check what came back: the same windows, the same order, still signed in. A tool that loses its arrangement on restart will lose it every week.

Anything that fails the day one checks, or that scores worse on day four counts, is finished. What remains is the answer, and the fact that it survived a week of real work is a stronger signal than any review.

What to change first

Name the unit in one sentence today, then apply the maintenance filter to the list already collected, which usually cuts it in half in ten minutes. If the unit turned out to be per app rather than per account or per project, that is the shape SpaceDeck is built around, and the Features page is the fastest way to see whether the shape matches before installing anything.