Arcの代わり: the setup order that holds up

Most replacement searches begin with a list of browsers and end three weeks later with two browsers installed and neither one finished. The list is rarely the problem. Arc was doing four separate jobs inside one application, those four jobs land in different places once it is gone, and the order in which they get moved determines whether the migration completes or quietly stalls. This is about that order.

Arc still opens, and that is what makes this hard

Nothing is broken today, so nothing forces a decision. The official site is direct about the state of things:

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

Downloads for macOS and Windows are still on that page, and the feature descriptions for Spaces, Profiles, Split View and Themes are still there too. The wording is not a shutdown notice. It is a statement about what kind of updates arrive.

Two events sit behind it. On 27 May 2025 The Browser Company said it was stopping active development of Arc to concentrate on Dia. On 4 September 2025 Atlassian announced its acquisition of The Browser Company, and the browser named in that announcement as the thing being built for knowledge work is Dia.

What that adds up to is a slope rather than a deadline. Extension compatibility, new macOS releases, new web platform features: those are the places where an unmaintained browser degrades, and they degrade slowly enough that there is never an obvious day to act. So the useful question is not when to delete Arc. It is which part to move first.

Four jobs Arc was doing at once

Before comparing anything, write down what Arc was actually doing on a normal Tuesday. Skipping this step is how people end up choosing a product on the strength of a feature they never used. Arc combined four unrelated things in one window:

• Login separation (Profiles). Keeping a work Google account and a personal Google account apart at the cookie level.
• Task separation (Spaces). Switching between bundles of tabs without changing who is signed in.
• Screen layout (Split View, the sidebar). Seeing two or more pages at once.
• Tab lifespan (automatic archiving). Letting untouched tabs disappear after a set time.

In a replacement these four do not stay together. Login separation belongs to browser profiles or to per-app session isolation. Task separation belongs to workspaces or tab groups. Screen layout can often be handed back to the operating system. Tab lifespan sometimes stops being a problem at all, because the thing generating hundreds of tabs was the single-window design.

Written out, the list usually shows that only two of the four were load bearing. The other two were pleasant. Weighting them equally is how a migration ends up optimised for the feature that mattered least.

There is a quick test for which two are load bearing. For each of the four, describe what the working day looks like without it. Losing login separation means signing out and back in several times a day, which is a measurable cost. Losing automatic tab archiving means a longer list that nobody reads, which costs nothing. Anything that produces a shrug under that test does not belong in the requirements.

Step one: settle the boundary

The first decision is what divides the day, and there are only two answers.

The boundary can be the account: an employer account, a client-issued account, a personal account. This boundary is not negotiable. It is set by somebody else's security policy and it survives until an offboarding process changes it. Crossing it is itself the failure.

Or the boundary can be the work: same account throughout, writing in the morning, calls in the afternoon, research at night. That boundary is self-imposed and can be redrawn tomorrow.

The two require different machinery. An account boundary needs cookies and storage genuinely held apart. A task boundary needs nothing more than a way to change what is on screen. Migrations fail here more than anywhere else, because a tool that only changes what is on screen looks identical to a tool that separates sessions until the day two accounts are needed at the same time.

One question settles it. Does staying signed in to two accounts of the same service, simultaneously, need to work? If yes, the account boundary is primary and a product that keeps each app in its own workspace with its own session is the shortlist. If no, almost anything will do and the decision is about taste.

Step two: move the logins before the tabs

Once the boundary is known, the next thing to move is authentication. Not bookmarks, not tabs. Logins.

A session lives in a cookie and a cookie belongs to a browser profile, not to a tab. Chrome's help page states the scope plainly:

With profiles, you can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings. Source: support.google.com

The same page adds that anyone holding the device can switch to any other profile on it. Profiles are an organising boundary, not a security boundary. On a Mac shared with another person, the correct separation is macOS user accounts, and no browser setting substitutes for that.

Practically, take the three or four accounts used most often, sign in to each one in the new environment on the same afternoon, and clear two factor authentication at the same sitting. Register the authenticator, check that recovery codes are where they are supposed to be, and finish. Discovering a missing recovery code six weeks later, on a day with a deadline, costs the whole day.

Anyone running several Google accounts should also know how the default account behaves. Google documents that the default is usually whichever account signed in first, and that when several accounts are signed in at once, settings from the default may apply, naming Web and App Activity and Ads Personalization. If order of sign-in changes behaviour, then order of sign-in is a configuration decision, not an accident.

Step three: decide where an outside link lands

The third decision covers links that arrive from outside the browser: mail clients, chat apps, calendar reminders, links inside PDFs. Which window and which session answers that click has more effect on daily friction than any feature comparison.

Arc users generally never made this decision, because Arc was the default browser and it resolved the profile internally. A replacement built around several windows or several profiles breaks that assumption immediately. Opening a client document and landing in a personal account is the standard version of this failure.

Three things need settling:

• Which application is the macOS default browser.
• For each route that carries work links, mail and chat in particular, where those links should open.
• What the recovery move is when a link opens in the wrong place.

The third is the one that gets skipped, and it is the expensive one. Without a defined recovery move, the answer becomes copying the URL and pasting it into the correct window, several times a day, each time breaking concentration for the few seconds it takes plus however long it takes to get back. Deciding which services get a permanent window of their own is the same decision as deciding how links get routed, which is why the two are worth settling together. The shape of that choice is described in Features.

Step four: notifications go last

Notifications are the last thing to restore, and doing them early is actively counterproductive. During a transition both environments are signed in, so every message arrives twice and neither copy can be trusted.

The sequence that works: silence Arc completely before starting, run the new setup without notifications until it feels stable, then open only the ones where a slow reply costs somebody else time. Direct messages in chat and calendar alerts immediately before an event usually cover it. Mail and task-tracker notifications can stay off for a week as an experiment, and quite often stay off afterwards.

There is a mechanical reason for the ordering too. Web notification permissions are stored per browser profile. Rebuild a profile and the grants are gone, so configuring them before the profile layout is final means doing the work twice.

Badge counts deserve separate treatment from alerts. A red number on an icon is not an interruption in the way a banner is, and for most services it carries enough information on its own. Leaving badges on while leaving banners off is usually the setting that survives, because it answers the question that drives the habitual check without taking attention at a moment somebody else chose.

A checkpoint before going further

At this point the migration is either finished or visibly incomplete, and the difference is worth confirming rather than assuming. Three signs indicate it is finished: every account signs in without a detour, a link arriving from mail opens where it should on the first try, and nothing arrives twice. If any of the three fails, the failure names the step that was skipped, and going back one step is faster than working around it for a month.

What the published pages say right now

Product facts move in this category, so the check is worth doing directly rather than from memory. As of September 2026, taken from each vendor's own pages:

Product	Free tier	Paid	Status observed
Wavebox	Basic: 2 groups, 2 apps each, 1 extension	Pro $8.33 per month billed annually; Teams $12.50 per user per month	7 day trial, no card required
Shift	Free: 5 Spaces, 10 apps per Space	Advanced $199.99 per year	tryshift.com now redirects to shift.com
Rambox	Basic: unlimited apps, up to 2 instances per app	Pro $7 per month or $70 per year; Teams $14 per user per month, 5 user minimum	30 day Pro trial on new accounts
Ferdium	Community built, free, usable without an account	None	Distributed from the project site

Two things are visible in that table. First, the free tiers are cut along completely different axes: one counts apps, one counts bundles, one counts how many instances of the same app can run. Anyone whose actual requirement is two accounts of the same service will find that only the third axis matters, and price comparisons that ignore it compare nothing. The per-feature differences are laid out in Compared with Wavebox and Compared with Rambox.

Second, availability itself is a variable here. Sidekick was sunset on 3 August 2025 and meetsidekick.com now redirects to comet.perplexity.ai. Shift's original domain redirects to a new one. Before committing, open the vendor's own pricing page and confirm three things beyond the number: that the product is still shipping, that ownership has not changed, and that new signups are still open. That checklist is applied in Compared with Sidekick.

What to change first

Write down which of the four jobs Arc was doing for you, then answer the single question about two accounts of the same service at the same time. That answer eliminates most of the shortlist before any trial is installed. If the answer is yes, the thing to evaluate is whether sessions are genuinely separated per window, and SpaceDeck is built on macOS around that separation.