Shift browser: the setup order that holds up

Most setups of this kind fail in the same way. The application gets installed on a quiet afternoon, every service that comes to mind gets added over the next twenty minutes, and two weeks later the result is the same undifferentiated pile of things that prompted the search in the first place, except now it lives in a new window. Nothing went wrong technically. The order was wrong. What follows is a sequence that produces a setup still worth having after a month, with the specific menu locations for each step as published in the product documentation.

Start with identities, not with apps

The first step happens before the installer runs, on paper or in a note.

List the identities that must never be confused with each other. Not projects, not tools: identities. The employed self with a company mailbox, the personal self, the freelance self billing two clients, the studying self. Most people produce three or four. Anyone producing eight is listing projects, and projects belong inside an identity rather than beside it.

This matters because the container in this product, the Space, is an isolation boundary. Two accounts of the same service can stay signed in at once because their sessions are separated, which is the one thing the tool does that rearranging tabs cannot reproduce. Spending that boundary on a project that shares credentials with another project wastes it.

Then, under each identity, write only the services that need to be reachable without being opened. Something checked ten times a day qualifies. Something opened twice a month does not, and should stay an ordinary tab or a bookmark. This second list is usually shorter than expected, which is the point: it is also the list that decides whether the free ceiling of five Spaces with ten apps each is a constraint or an irrelevance.

Keep both lists visible during the build. Every later decision refers back to them.

Settle the version question before building anything

Two builds currently answer to the same name, and building on the wrong one means building twice.

Launch the application, open the menu bar, and choose About Shift. A version number beginning with 9 is the older build. The documentation states that no further major product updates are planned for v9, and that the rebuilt browser is what receives development.

For anyone already on v9 with a working configuration, the documented path is to wait. The rebuilt version reaches existing users automatically over a period of months, and the migration carries Spaces, apps and bookmarks across. Downloading the new build manually before that happens is allowed and starts from a clean slate with nothing brought over, which means rebuilding by hand. Paying users who move early are told to sign in with the primary account email so the paid entitlement follows.

For anyone starting fresh, take the rebuilt version and ignore every guide written for v9. The differences are not cosmetic: the older build tied each Space to an email account, and the rebuilt one does not, which changes how the container list gets drawn in the next step.

Manual update checks live under Quick Settings, then Advanced Settings, then About Shift, where a Relaunch button appears beside the version number when an update is waiting.

Build one Space completely, then stop

The temptation after installing is to create every container at once. Resist it for a specific reason: the first Space teaches how much belongs in a Space, and that lesson is cheaper to learn once than four times.

Pick the identity used most hours per day, usually work. Create one Space for it. Add apps from the library using either of the two documented entry points: the app icon showing three squares with a plus, or the plus sign that sits by default on the Spaces and apps bar, where selecting Add App opens the list.

Add only the services from the paper list. When something not on the list seems worth adding, leave it out and note it instead. After a week, most of those notes stay unclaimed, which is the evidence that the list was right.

Then use that one Space exclusively for two or three working days before creating the second. Two things surface during that period that no amount of planning predicts: which service should sit closest to the eye, and which two services are always used together and therefore belong adjacent. Both are cheap to fix in one container and tedious to fix across four.

Only after that should the remaining identities get their containers, each built the same way from its own list.

The layout pass, and the one control worth keeping

Layout comes after the contents, not before. Arranging an empty window is guesswork; arranging a window with a week of use behind it is editing.

Starting from a template is the lower risk route. The published arrangements include one that pins apps and Spaces to a sidebar for fast context switching, and adjusting a working structure takes less time than designing one. From there, bars, apps and controls move by dragging.

One specific caution belongs in every setup guide for this product, because the documentation devotes an entry to it. The Quick Settings control can be dragged out of the layout during customisation, and removing it takes the settings drawer with it. The recovery is a keyboard shortcut: on a Mac, hold Command and press the comma key, which opens Quick Settings regardless of whether its button is present. From there, Customize Layout puts the button back.

Colour themes are worth treating as function rather than decoration. Eight themes are available across light and dark, and assigning a distinctly different one to each Space gives peripheral vision something to read. Knowing which identity is on screen without focusing on a label is what prevents messages typed into the wrong account, which is the specific mistake this entire category exists to prevent.

Settings that earn their place in the first week

Four settings are worth visiting once the containers exist. All four sit behind Quick Settings, then Advanced Settings, in the left side panel.

Account and sync. Creating an account is what makes the layout, Spaces, apps and bookmarks reproducible on a second machine, and it doubles as a backup. Three documented routes reach the same place: the Shift Account section and its Sign in control, the Sync Shift section and its Sync now control, or the upgrade flow. Sign up with an email and password, or through a Google, Apple or Microsoft account. On the second machine, turn on sync rather than rebuilding.

Startup behaviour. The OnStartup tab holds two separate switches, one for opening on login and one for opening on wake. A tool that holds every work account should not necessarily appear on a weekend morning, and these are the switches that decide.

Search engine. The Search Engine tab allows changing the default between Google, Bing, Yahoo and StartPage through a Change control followed by Set as Default.

Default browser handling. This one is not a setting inside the application but a decision about macOS. A link clicked inside a mail client or a chat app goes to whichever browser the system treats as the default. If that is a different browser, links keep opening in the wrong session no matter how carefully the Spaces are arranged. Deciding deliberately, in either direction, is what closes the most common remaining failure.

Extensions, and the services that are missing from the library

Extensions transfer, because the base is Chromium and the documentation states that almost every extension in the Chrome extension library is supported. The sequence that avoids waste is to add them per Space rather than everywhere: a password manager belongs in all of them, while a client specific tool belongs in one.

Services absent from the app library have a documented route as well. A request mechanism exists for adding apps to the directory, which is more useful than the headline count, published inconsistently as over 4,500 on the directory page and over 1,500 in the help centre. For anything regional or niche, the request is the path rather than the number.

Password handling needs one decision during this phase. Credentials are encrypted and stored locally with autofill available, and a checkup flags duplicates and weak entries. Running that checkup once, at the point where several accounts have just been signed into in quick succession, catches the reused passwords that the sign in marathon exposes.

The test that tells whether the order worked

A setup gets judged on the worst day of the month, not on the afternoon it was built. Three checks, run after roughly a week, give the answer.

Check whether any Space has been opened fewer than three times. If so, that identity did not need a container and the list was aspirational rather than real. Removing it is not a loss.

Check where links from outside the window end up. If they arrive in the wrong account, the default browser decision has not been made, and no amount of further arranging will fix it.

Check the ceiling against the real count, not the planned one. Apps accumulate quietly, and the point of hitting a limit is almost always a busy day, which is the worst possible moment to be evaluating whether to pay for anything.

The same sequence, laid out against a week

Spread over calendar time, the order stops competing with the working day. Nothing below takes longer than half an hour, which is deliberate: a setup that demands an uninterrupted afternoon gets done badly on the one afternoon that was available.

When	Step	Why it sits here
Before installing	Write the identity list and the per identity service list	Decisions made with an empty window open turn into decisions about the window
Day zero	Check the version, install, create one Space, add only listed services	The version determines whether anything built now survives
Days one to three	Use that single Space for real work, note what is missing	Usage reveals adjacency and priority that planning cannot
Day four	Adjust that layout, then clone the pattern into the remaining identities	Editing a proven arrangement beats designing a new one
Day five	Account, sync, startup switches, search engine, default browser decision	These matter only once containers exist and carry real sessions
Week two	Remove containers used fewer than three times, count apps against the ceiling	The unused container is the clearest signal that the list was aspirational

The one step people skip is the third, because using a half built setup feels premature. It is the step that makes the rest cheap. Three days of ordinary work answer questions that no amount of planning resolves: which service deserves the position nearest the eye, which pair is always used together, and which identity turned out not to need separating at all.

What to change first

Do the identity list before installing anything, and build exactly one container before building the rest. That single change in order is what separates a setup that survives a month from one that has to be rebuilt, and it applies to every tool in this category rather than to one product. If, after a week, the containers hold but switching between them still costs attention, the missing piece is window level separation rather than in window separation, which is the design described on Features and on Workspaces. A point by point comparison with the product covered here is on Compared with Shift, and SpaceDeck lists the services that can be dropped in without configuration.