Fluid: the setup order that holds up

Most people who look up Fluid tsukaikata already know the three steps on the creation screen. Type a URL, type a name, press Create. That part takes twenty seconds and it works. The trouble shows up four days later, when the app throws you out to Safari every time you sign in, or when the second account turns out to be signed into the same session as the first. Almost none of that is a defect in the tool. It is the order the setup was done in. The fields on the creation screen are the last decisions to make, not the first.

What the creation screen actually locks in

Fluid's own description of the process is three fields and a button. The published wording is "Enter the website's URL, provide a name, and optionally choose an icon," after which pressing Create produces a standalone application in seconds. What is worth knowing is which of those three is expensive to change later.

The URL becomes the home URL of the finished app. Every launch returns to it, and the whitelist rules described further down are generated from it. Getting this one wrong is the single most common cause of an app that behaves oddly from day one.

The name becomes the application name on disk, the label under the Dock icon, and the entry in the Command Tab switcher. Renaming the file later renames the icon label but does not rewrite what the app reports about itself internally, so the Command Tab entry can drift out of sync with the Dock.

The icon is genuinely optional and genuinely cheap to change. Dragging a new image onto the Get Info window of the finished app replaces it at any point. Spending time on the icon before the URL is backwards, and that is the order most walkthroughs teach.

Fluid is free to download, with no cap on how many apps get created. A $5 license adds three things, covered below. Version 2.1.2 is the current published build, the download is listed at 6.3 MB, and the stated requirement is Mac OS 10.12 or later.

Decide the account before the URL

This decision sits above everything else, and it is the one that cannot be fixed by editing preferences afterwards.

A wrapper app holds a login session. If the same service is used for work and for personal things, the question is whether those two sessions need to exist at the same time. If the answer is yes, the setup is not one app with settings. It is two apps, each built separately, each signed in once, and each given a name that makes clear which is which at a glance in the Dock.

The rule that decides this is where the cookies live. Apple states the behavior for its own web apps plainly:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

Chrome's Install page as app route behaves the opposite way, inheriting the cookies of the Chrome profile it was created from, which is why two accounts cannot be held open side by side that way. Fluid's public page says nothing about cookie storage in either direction. Where a vendor does not document the behavior, the honest move is to test it before building eight apps on the assumption.

The whitelist screen is where setups actually break

The complaint that turns up most often is an app that keeps kicking the user out to the default browser. That is the whitelist working exactly as designed, on patterns that do not match the site.

Fluid's preferences include a Whitelist section with two modes. One allows browsing to any URL. The other allows browsing only to URLs matching a list of patterns, where the asterisk means match anything at this position. The default is the pattern list, built from the home URL entered at creation time.

The failure looks like this. The home URL is https://example.com/app, the sign in flow bounces through https://accounts.example.net/, that host does not match the pattern, and the login lands in Safari instead. The app is left sitting on a signed out page.

The diagnosis is mechanical. Watch which URL is the first one to appear in the default browser. That is the address Fluid has decided is not part of the site. Add a pattern that matches it, then repeat the sign in. Identity providers usually need one extra pattern, sometimes two.

For well known web apps, Fluid ships preset pattern sets, because those services redirect to hosts that no simple rule derived from the home URL would ever match. Checking whether a preset exists for the target site before hand writing patterns saves the whole exercise.

There is a shortcut that looks tempting and usually is not. Switching the setting to allow browsing to any URL makes every symptom disappear at once, because nothing is ever rejected. It also removes the only thing separating the app from a browser window with the chrome hidden. A tool built to keep one site in one window, then configured to accept every site, has been turned back into the problem it was meant to solve. Use the permissive mode to confirm that a whitelist rule is the cause, then switch back and fix the pattern.

Decide what should leave the window

The opposite problem is an app that swallows links it has no business opening. A chat tool is the clearest case. Messages are full of external addresses, and an outbound article opened inside a window with no address bar and no tabs is worse than useless.

Fluid handles this in two places. The context menu on a link includes Open Link in Default Browser, which the changelog records as restored in version 2.1.1 after the 2.0 rewrite. Separately, version 2.0.2 restored the setting that sends links to other applications in the background, so the browser does not steal focus mid conversation.

The order that holds up is to set the whitelist narrow first, then widen it only for the hosts the sign in flow genuinely needs. Starting with allow any URL and narrowing later means never finding out which hosts matter, and the app slowly turns back into a browser.

The license changes the shape of the setup, so settle it early

The published license features are exactly three: pinning apps to the status bar, using userscripts or userstyles, and full screen mode. The price is $5.

Status bar pinning matters more than it sounds, because it changes what the setup is for. A pinned app has no permanent Dock presence and drops down from the menu bar instead. That is a different daily habit from a Dock icon, and picking one after building six apps means rebuilding the habit, not just the apps.

Userscripts and userstyles are the one thing on this list that does not transfer. URLs, names and icons can be recreated anywhere in minutes. A stylesheet that hides three panels of a cluttered internal tool is work, and it is written against this specific container. Anyone who intends to rely on that should know it before the rest of the setup is built around it.

Decision	Where it is made	Cost to change later
Which account signs in	Before creation, by choosing how many apps to build	High. Requires a separate app and a fresh sign in
The exact home URL	Creation screen, first field	Medium. Preferences hold the home URL, but whitelist patterns were derived from it
The app name	Creation screen, second field	Medium. The Dock label and the internal name can end up disagreeing
The icon	Creation screen, third field, optional	Low. Replaceable from Get Info at any time
Whitelist patterns	Preferences, after creation	Low. Editable freely, and the usual place a fix belongs
Status bar or Dock	License purchase, then per app	Medium. Changes the habit, not just the setting
Userscripts and userstyles	After the license, per app	High. Nothing carries to another tool

What to check during the first week

Four things separate a setup that survives from one that gets abandoned.

Sign in once, quit the app completely, and reopen it. If the session is gone, the container is not holding cookies the way the setup assumed, and every other decision needs revisiting.

Trigger something that should produce a notification. Fluid's changelog records WebKit Notifications and Notification Center support arriving in version 1.7, but the shipping build dates from 2018 and modern web push arrived on macOS long after that. Treat notifications as unverified until seen, rather than as a listed feature.

Open Command Tab and confirm the app appears as its own entry rather than folding into a browser. That separation is the actual reason for doing any of this.

Finally, click three or four links that lead off the site and watch where they open. If they open inside, the whitelist is too wide. If sign in leaves the app, it is too narrow. Those two symptoms have the same cause and opposite fixes.

Running the same order on a current tool

Nothing in this sequence is specific to one product, which is what makes it worth keeping. Decide the account split, pin down the exact URL including the path that survives a redirect, set what stays inside, set what leaves, then decide whether the thing lives in the Dock or the menu bar. Any wrapper worth using exposes all five.

What differs between tools is how much of that comes preset. Some wrappers ask for a URL and nothing else. Others arrive with the sign in hosts, the icon and the link rules already filled in for common services, which removes the whitelist step entirely for those sites. The Supported services list is the fastest way to tell whether a given site is in that category or needs hand configuration, and the Features page shows which of the five decisions a tool actually exposes as settings rather than baking in.

Two practical notes on evaluating a replacement. Check whether the licensing is one time or recurring and which macOS versions are covered on the Pricing page, since a wrapper that stops being updated turns into a deadline rather than a tool. And read the Guide before migrating more than one app, because the order that works for the first app is the order that will be repeated seven more times.

What to change first

Before rebuilding anything, write down which sites genuinely need separate sign in sessions. That single list decides how many apps exist, and every other setting follows from it. Once the count is settled, Kagemusha or any other current wrapper can be evaluated against the same five decisions rather than against a feature list.