Unite: the setup order that holds up

Building one app with this tool takes about thirty seconds, which is why most people build the wrong one first. The creation sheet asks for a URL, an icon, a mode, and a handful of toggles, all in a single pass, and it gives no signal about which of those answers is expensive to revise and which is free. Getting the order right is the difference between a library that stays useful for a year and a set of half configured windows that get deleted in a month. What follows is a working sequence, with the reason each step sits where it does.

Which settings are cheap to change, and which are not

Order matters only because reversibility is uneven. Sorting the settings by that criterion first makes the rest of the sequence obvious.

Setting	Cost of changing later
Icon, name, appearance, zoom	Free, takes seconds
Mode (normal, sidebar, menu bar)	Cheap, the app rebuilds in a few seconds
Ad blocking, launch at login, download folder	Free, a toggle
Which site the app points at	Expensive: session, permissions, and habits reset
Which account is signed in	Expensive: the whole point of isolation is undone
How many apps exist	Expensive once past the free tier, since a licence is involved

Everything in the top half can be treated casually. Everything in the bottom half deserves thinking about before the first build, because unwinding it means signing in again, granting permissions again, and retraining a habit that was starting to form.

Step 1: build the shortlist away from the tool

Decide which sites qualify before the creation sheet is open, because the sheet invites building whatever comes to mind.

A site earns an app when at least two of these are true: it stays open for hours, it gets lost among tabs and costs a search each time, it sends notifications worth seeing, or a second account on it is needed alongside the first. Sites that fail all four are fine as tabs, and converting them adds icons without adding anything else.

A useful cross check is to look at what people commonly convert. The Supported services list groups the usual candidates by category, and comparing a personal shortlist against it tends to produce two corrections: something obvious was forgotten, and something on the list was never going to be used daily. Most people land on three to five apps. Anyone whose list reaches fifteen is rebuilding a browser in slow motion.

Step 2: one app, one account

Draw account boundaries before touching anything else, because every app keeps its own cookies and session, and that isolation is the feature doing the heaviest work.

Two accounts on the same service means two apps, named differently, with visibly different icons. Naming them after the account rather than the service is the detail that pays off later, since the Dock and the app switcher both show that name. A work inbox and a personal inbox that look identical in the Dock will be clicked wrongly for as long as they exist.

This is also the moment to accept a one time cost: signing in happens again inside the app, including any two factor step, even for services already signed in elsewhere on the Mac. That is isolation working as intended, not a fault.

Step 3: choose the mode, then let the icon be automatic

The mode decides how the app behaves every day, and the icon decides nothing. Deal with them in that order, and give the mode the thirty seconds of thought that the icon does not deserve.

Normal mode gives a full window with tabs and a toolbar, and it suits anything worked in for long stretches. Sidebar mode puts a resizable list of tabs down the left and suits sites with many sections visited in rotation. Menu bar mode removes the app from the Dock entirely and drops a small window from the menu bar, which suits tools opened for twenty seconds at a time.

The rule that holds up in practice is about duration rather than category. Long sessions want a window. Short repeated visits want the menu bar. A site checked ten times a day for five seconds each does not belong in the Dock at all.

The icon is generated from the site's own favicon, with a shape and background colour that can be adjusted, or replaced with a custom image. Doing it later costs nothing, so it should not hold up the build.

Step 4: decide where links go before the first real use

Link handling is the setting most often discovered by accident, usually after an app has swallowed a link that should have opened in the browser, or thrown one out that should have stayed inside.

Two patterns cover almost everything. A focused app, such as a mail client or an AI assistant, should forward external links to the default browser and keep only its own domain inside. A hub app, such as a project tool that links constantly to its own subpages and to a documentation site, should keep a small set of related domains inside and forward the rest.

Two details are worth knowing. Whitelist patterns accept wildcards, so an internal range or a whole domain can be matched with one rule, and a fix in the 26 July 2026 update addressed patterns that were not matching as expected. Forwarding to the default browser now follows whichever browser is currently set as the system default, rather than remembering the one that was default when the setting was first enabled. Anyone who switched browsers at some point should confirm that behaviour rather than assume it.

Step 5: grant permissions on first real use, not in advance

Permissions are set per site, covering notifications, camera, microphone, screen sharing, and location, each of which can be set to allow, deny, or ask. Cookie policy is also per app.

Resist configuring these during the build. Use the app normally for a day and answer the prompts as they appear, because a prompt arriving in context makes clear why the site wants the permission. Pre approving everything defeats the main advantage of app level isolation, which is that a video conferencing app can hold camera and microphone access while nothing else on the Mac does.

Notifications are the exception worth verifying deliberately. If the reason for building the app was to stop missing messages, send a test message and confirm two separate things: that the alert reaches Notification Center and that an unread count appears on the Dock icon. Both can be true, one can be true, and the difference matters.

Step 6: enable only the enhancements the site supports

For recognised services, native integrations appear as toggles during creation and are enabled by default when detected: Dock badges, meeting notifications from Google Calendar and Outlook, a menu bar overlay for AI chat services, and playback speed controls on video sites.

Leaving all of them on is harmless but noisy. Dock badges on a service that generates fifty low value notifications a day will train the reader to ignore the Dock, which is worse than having no badge. Turn on the ones that reflect something requiring action, and leave the rest off.

A newer option belongs here too. Since the 30 August 2026 update, an app built for Gmail or Outlook can be set as the Mac's default mail client, so mailto links anywhere on the system open a pre filled compose window in that app. It is the sort of setting that makes the app feel native, and it is easy to miss because it lives outside the creation flow.

Step 7: startup tabs, save location, and login behaviour

Three smaller decisions close out the build.

Startup tabs let an app open with several pages ready, each with its own address and title. This is genuinely useful for a dashboard opened every morning and a trap everywhere else, since the point of the exercise was fewer tabs.

Save location defaults to the Applications folder and can be changed. Keeping work apps in a subfolder is a reasonable habit, with one caveat covered in the next step.

Launch at login should be reserved for apps that are actually wanted at every login. Five apps launching at startup reproduces the browser with fifteen tabs, one icon at a time.

Ad blocking is on by default and uses a built in list, so it needs no attention unless a site breaks, in which case turning it off for that one app is the first thing to test.

Step 8: export a backup once the library reaches three apps

Exporting apps as configuration files is a licensed feature, and it is also the documented route to a new Mac: export each app, move the files across, install the tool on the new machine, release the licence from the old Mac, activate on the new one, and import.

Three apps is a sensible threshold for starting to keep exports, because rebuilding one app by hand costs under a minute while rebuilding ten with all their link rules and permissions costs an afternoon. Exports also protect against the smaller accident of deleting an app while tidying the Applications folder.

One detail connects back to step 7. Apps saved outside the Applications folder may not be found automatically by scans that look for existing apps, so a custom location is worth noting somewhere rather than discovering later.

For the exact sequence of screens each of these settings appears on, the Guide walks through the creation flow in order, which is the fastest way to see which panel holds which toggle before starting.

What to leave alone on day one

Three capabilities exist that should not be touched during the first build, because reaching for them early usually means the earlier steps were skipped.

User scripts and user styles can reshape a site inside a single app: hiding an element, tightening a layout, changing a colour. That is genuinely powerful, and it is also the fastest way to create something only one person can maintain. Use the site as shipped for a week first. Most of the irritations that seem to need a script turn out to be a mode chosen badly.

A custom user agent string is a repair tool, not a setup step. It belongs in the toolbox for the specific case where a site serves a cut down page to anything it does not recognise. Setting one pre emptively invites the opposite problem, where a site serves a layout intended for different software entirely.

Per site zoom is the third. It is worth having when a site renders small in a narrow sidebar, and it is not worth deciding before the window has ever been resized. The pattern across all three is the same: configure in response to something observed, not in anticipation of something imagined.

What to change first

Build one app today, for the single site that is hardest to find when it is buried, and set only the mode and the link behaviour before using it normally for a week. Leave permissions to answer themselves in context and leave the icon until last, then use what that week teaches to build the next two. Tools of this kind are best compared on that basis rather than on feature lists, which is also the quickest way to read a page like Kagemusha with a specific workflow already in mind.