Fluid: what it does and where it breaks down

Fluid is a tool that turns a single website into a small Mac application. It arrived in 2007, it is still being distributed, and the name keeps surfacing in search results whenever someone gets tired of hunting for the same tab twenty times a day. What is much less clear from the outside is what the tool actually produces, how it decides what belongs inside that window, and which parts of it have aged. This article takes those three questions in order, using the shipping build and the official pages as the source.

The category it belongs to

Fluid calls itself a site specific browser creator. The official about page states the goal directly.

Fluid's goal is to be the best, most native-feeling Site-Specific Browser Creator for Mac OS X. Source: fluidapp.com

A site specific browser is a browser that only ever goes to one place. The address bar is not the point. The point is that the destination is fixed, so the application becomes a noun rather than a verb: not "open the browser and find the tab" but "open the mail app". The same about page credits Mozilla Prism and Adobe AIR as the inspiration, and notes that the author previously worked on Dashboard at Apple, which explains the general shape of the thing. It is a container for one web page with a native menu bar bolted on.

What this category buys is retrieval time, not capability. The page inside the window is the same page the browser would show. Nothing about wrapping it makes the service faster or adds features to it. What changes is that the service now has a Dock icon, an entry in the application switcher, and a window that survives when the browser is closed. For a service opened three times a day that is noise. For a service opened forty times a day it is the whole point.

What gets created when you press Create

The workflow is three fields: a URL, a name, an optional icon. Press Create and an application appears in the Applications folder a few seconds later.

The mechanism behind those few seconds is worth knowing, because it explains most of the tool's behavior. Inside the downloaded Fluid bundle there is a complete second application sitting in the Resources folder. Creating an app is a copy of that template with the URL, the name and the icon written into it. No code is generated, and nothing is compiled.

That has a direct consequence: every app made this way inherits the template's properties. In the current build the template reports version 2.1.2, a minimum requirement of macOS 10.12, and a single supported architecture, x86_64. Whether the wrapped service is a chat tool or an internal admin panel, the container underneath is identical.

The second thing worth knowing is what is not in the bundle. There is no rendering engine inside it. The executable links against the WebKit framework that ships with macOS, so pages are drawn by the operating system's own engine, at whatever version that Mac is running. The shell stopped moving in 2018. The rendering did not. Keeping those two facts apart is what makes it possible to diagnose a layout problem later.

Who signs the thing you download

The download is small, 6.3 MB, and it is signed with a Developer ID belonging to the author, with a signing timestamp from October 2018. Gatekeeper accepts it as notarized software today. The notarization ticket is not stapled into the bundle, so the first launch involves an online check rather than a purely local one. That detail matters mainly on locked down corporate networks and on machines that are offline the first time the app is opened.

The whitelist is the design

Every app built with Fluid carries a list of URL patterns it considers its own. Anything outside that list gets handed to the default browser instead of opening in the window. This single mechanism explains behavior that otherwise looks arbitrary.

The shipping build includes presets for 43 well known sites. Reading them is instructive. The calendar preset does not just list the calendar domain, it also lists the account domains used for sign in. The document preset does the same. Whoever compiled that list had already hit the problem that single sign on sends users through a second hostname, and that a wrapper which only knows the first hostname will eject the user into the browser halfway through logging in.

A freshly created app starts with one pattern and a Google home page, which means any site without a preset begins life with an effectively empty territory. That is a design choice rather than an oversight: the tool asks the user to decide what counts as inside.

Patterns can be wildcards or regular expressions

Patterns are normally written with wildcards. Since version 1.7 a pattern wrapped in forward slashes is treated as a regular expression instead. For a business service where each customer gets a different subdomain, the regular expression form is usually shorter than enumerating wildcards. There are also settings to invert the whitelist and to allow navigation to any domain, so the strictness of the container is adjustable in both directions.

What the page can do to the window

Fluid exposes a small JavaScript API to the page it is displaying. The developer page documents it: set a badge number on the Dock icon, add items to the Dock menu, post a notification, hide the app, bring it to the front, quit it, or load a local script file.

Extension happens entirely through JavaScript. The developer page is explicit that userscripts and userstyles are built in and that no plug-in mechanism is used or required. Restyling a page, hiding a sidebar, or adding a keyboard shortcut the service never shipped are all script work. Those two features sit behind the paid license, which is covered separately on the Pricing page for current tools in this category.

The defaults are conservative in a way that reads as sensible today: JavaScript on, plug-ins off, Java off.

What wrapping a site does not do

Expectations about this category tend to run ahead of the mechanism, so it is worth stating the limits plainly.

Wrapping does not make a service work offline. Whatever the site does without a connection is exactly what the wrapped window does without a connection. Wrapping does not create notifications either. The JavaScript API exists, but the page has to call it, which means a service that never heard of Fluid will never post a Dock badge through it. Notifications that do appear come from the standard web notification mechanism, not from the wrapper.

Login state is not shared with the browser. The wrapped app keeps its own storage, so being signed in to a service in Chrome does not sign the user in inside the new window. That is usually desirable, because it is what makes a second account practical, but it surprises people on the first launch.

Settings do not sync between machines either. A whitelist carefully tuned on a work Mac has to be rebuilt on a home Mac, because the configuration lives inside the generated app rather than in an account. For a handful of apps that is a ten minute job. For twenty of them it is an afternoon, which is the point at which the preset list of whatever tool is being used starts to matter more than its feature table.

Features that vanished in the 2.0 rewrite, then came back

The changelog has an unusual shape that tells its own story. Version 2.0 was a significant rewrite onto Apple's newer WebKit API with process separation. Rewrites cost features, and this one did.

Everything after 2.0 is largely a recovery log. A global keyboard shortcut, window level settings, behavior across Spaces, side panels, per tab zoom persistence, receiving URLs from other applications, web inspector menu items, and the option to hide rather than quit when the last window closes were all restored across 2.0.1, 2.0.2 and 2.1. Dark mode support arrived at the end of that run.

The practical lesson is about research rather than features. An old review may describe a capability that a later build removed, or claim something is missing that came back two releases later. The changelog is the only reliable source for what the current build contains.

Where it breaks down today

Four things limit the tool now, and none of them is a bug.

The build stopped in 2018. The published version is 2.1.2. The update feed the app checks is still online and still answers, and the newest entry in it carries a build date of October 19, 2018. Checking for updates works perfectly and will always report that the app is current.

The architecture is Intel only. Both the creator and the apps it produces are x86_64. On Apple silicon they run through translation, and Apple has published an end date for that translation layer. Support continues through macOS 27, and from macOS 28 the translation environment survives only for certain older unmaintained games.

The interface is English only. The bundle contains a single language resource. The web page inside the window is unaffected, but every preference label is in English.

The published requirements disagree with themselves. The front page states macOS 10.12 or later. The about page still says 10.6 Snow Leopard or later. Both are live today.

Property	Current Fluid build
Version	2.1.2
Latest update feed entry	October 2018
Architecture	x86_64 only
Rendering engine	System WebKit, follows the OS
Interface languages	English
Paid features	Status bar pinning, userscripts and userstyles, full screen

Who it still fits

None of the above makes the tool useless, and saying so would be dishonest. On an Intel Mac, for a service with a preset already written, it does exactly what it says with no ongoing cost. For a short lived internal tool that will be replaced next year, the fact that the shell stopped moving is irrelevant.

The calculation changes when the window is meant to last. A service opened every working day for the next five years has to survive a hardware change, an architecture deadline, and whatever the service's own login flow does in the meantime. That is a different question from whether the tool works this afternoon, and it is worth answering separately. Current tools in this category publish what they support up front, which is why the Supported services list is usually the fastest thing to check before committing to any of them.

What to change first

Write down the services opened more than ten times a day. If there are fewer than three, the browser's own install feature is enough and no tool is needed. If there are more, check the architecture of the Mac first, then pick a wrapper whose preset list already covers those services, such as Kagemusha, so that no time goes into hand writing sign in domains.