Fluid: what it does and where it breaks down

In physics, a fluid is any substance that flows, such as a liquid or a gas. This page is about the other Fluid: the Mac app at fluidapp.com, which turns a single website into a small application with its own Dock icon and window. It was created by Todd Ditchendorf, it is free to download, and an optional $5 license adds a few features. As of October 18, 2026, the download is version 2.1.2, built in October 2018, compiled for Intel Macs only, and still accepted by macOS as notarized software. That combination explains both why people still find it and why it needs a careful look before it becomes part of a daily routine.

This site is published by the developer of a site to app tool, which is mentioned once near the end as one of the current alternatives.

Fluid in one paragraph

Fluid describes itself as a creator of site specific browsers. A site specific browser is a browser that only goes to one place. Instead of opening a browser and hunting for the right tab, the user opens "the calendar" or "the support desk" as if it were any other application. The Fluid about page puts its aim this way:

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

The same page credits Mozilla Prism and Adobe AIR as the inspiration, and notes that the author once worked on Dashboard and Dashboard Widgets at Apple. That background shows. A Fluid app is a native Cocoa window around one web page, with a menu bar, a Dock icon, and a small JavaScript bridge between the two.

What this category offers is speed of finding, not new capability. The page inside is the same page the browser shows. It does not get faster or gain features. It gains a fixed place in the Dock and in Cmd+Tab, and it keeps running when the browser is closed.

What happens when Create is clicked

The Fluid home page describes the workflow: enter a URL, give it a name, optionally choose an icon, and click Create. Within seconds an application appears.

Opening the downloaded bundle without running it shows how that works. Inside the Resources folder of Fluid.app sits a second, complete application named FluidApp.app. Creating an app copies that template and writes the URL, name, and icon into it. Nothing is compiled. That is why creation takes seconds, and also why every app made with Fluid has the same properties as the template underneath.

Those properties, read from the 2.1.2 bundle on October 18, 2026:

Property	Fluid 2.1.2
Version of the creator and the template	2.1.2
Minimum macOS stated by the template	10.12
Processor architecture	x86_64 only, for both
Rendering engine	The WebKit framework built into macOS
Localization resources	Base only
Signature	Developer ID, timestamped October 20, 2018
Gatekeeper result today	Accepted, as a notarized Developer ID app

The rendering engine is the important line. The template links to the WebKit framework that ships with macOS, so pages are drawn by the system's own engine at whatever version that Mac runs. The shell stopped changing in 2018. The engine drawing the page did not. When a site looks wrong in a Fluid app, the cause is rarely an old engine.

How Fluid decides what stays inside the window

Each Fluid app holds a whitelist of URL patterns it treats as its own. Links outside the list are passed to the default browser. This one rule explains most of the behavior that first time users find surprising, such as a sign in page suddenly opening in Safari or Chrome.

The 2.1.2 bundle includes a file of default whitelists with 43 entries for well known sites, many of them Google services. The entry for calendar.google.com, for example, lists not only the calendar address but also patterns for accounts.google.com. Whoever wrote those entries had already run into the problem that signing in sends the user through a second hostname, and a wrapper that only knows the first one ejects the user halfway through logging in.

For a site with no default entry, the whitelist starts small and has to be extended by hand. The Fluid changelog records two details that matter here. Version 1.7 added regular expressions anywhere a wildcard pattern is accepted, written between forward slashes. Version 1.8.4 stopped whitelisting Google's search URLs by default.

For business tools where each customer has a different subdomain, a regular expression is usually shorter and safer than a list of wildcards. The trade is that a whitelist is a manual job. Sign in flows that bounce through an identity provider need that provider's hostname added before the app behaves.

Free features, the $5 license, and the JavaScript bridge

According to the about page, the basic version of Fluid is free, and apps can be created without a limit. A $5 Fluid License unlocks three features:

1. Pinning a Fluid app to the menu bar, from the Fluid app menu, Pin to Status Bar.
2. Userscripts and userstyles, managed under Window, then Userscripts or Userstyles.
3. Full screen mode, under View, then Enter Full Screen.

The developer page describes the extension points. Bookmarklets work from a bookmark bar. Userscripts and userstyles are built in, and the page states that no plug-ins of any kind are used or required. A JavaScript API is added to every window, with calls such as window.fluid.dockBadge to set a number on the Dock icon, addDockMenuItem to add an item to the Dock menu, and showUserNotification to post a notification. Some calls, including hide, activate, terminate, and including a local script file, are limited to local userscripts.

The bridge only works if something calls it. A site that has never heard of Fluid will not set a Dock badge by itself. A userscript can, which is where the paid license earns its price for people who want, for example, an unread count on the icon of a web inbox.

The 2.0 rewrite and what came back afterwards

The changelog has an unusual shape. Version 2.0 is described as a significant rewrite onto Apple's newer WebKit2 API with process separation. Rewrites tend to drop features, and the entries that follow read mostly as a list of returns.

Version 2.0.1 brought back the global keyboard shortcut, window level settings, behavior across Spaces, browser side panels, persistent zoom per tab, opening URLs sent from other applications, and menu items for the Web Inspector and Console. Version 2.0.2 restored the setting for links sent to other applications to open in the background. Version 2.1 added Mojave Dark Mode and the option to hide the window instead of closing it when the last window is closed. Version 2.1.1 brought back the "Open Link in Default Browser" menu item and support for local HTML files. Version 2.1.2 fixed bookmarks bar links so they open in the current tab.

The update feed the app checks lists 2.1.2 as its newest entry, dated October 19, 2018. The practical lesson is about research. An old review may describe a feature that 2.0 removed, or complain about a gap that 2.0.1 closed. The changelog is the reliable record.

Where it breaks down today

None of the following is a bug. Each is a consequence of a 2018 build meeting a 2026 Mac.

The architecture is Intel only. Both the creator and the template are x86_64. On a Mac with Apple silicon, they run through Rosetta. Apple's support page on using Intel-based apps on a Mac with Apple silicon states that Rosetta is available on macOS 27 or earlier, and that starting with macOS 28, Rosetta will be available only for certain older, unmaintained games that rely on Intel-based frameworks. Fluid apps are not games, so the next major macOS release is the practical end date for Fluid on Apple silicon.

The stated requirements do not agree. The home page says Mac OS 10.12 or later. The FAQ on the about page says Mac OS X 10.6 Snow Leopard or later and Intel Macs only. The creator's own bundle declares 10.6, while the template it copies declares 10.12. The template value is the one that decides whether a generated app opens. The same FAQ also states that Fluid does not run on PowerPC Macs or on Macs with 32-bit processors, which matches the single x86_64 architecture found in the bundle. For anyone reading an old forum thread, these are the figures to trust, in that order: the template, then the home page.

The interface has only a Base localization. The bundle contains no other language resources, so preferences and menus are in English. The page inside the window is unaffected.

Nothing new will arrive through the updater. Check for Updates works and reports that the app is current, because the feed has not changed since 2018.

Two more limits come from the category rather than the age. Settings live inside each generated app, so a whitelist tuned on one Mac has to be rebuilt on another. And the about page FAQ asks users not to redistribute apps they create, suggesting each person builds their own.

Who Fluid still fits, and the alternatives

On an Intel Mac, for a site that already has a default whitelist, Fluid still does what it describes, for free. For a short lived internal tool that will be replaced within a year, the 2018 shell is irrelevant. The case gets weaker when the window is meant to last, because a daily tool has to survive a hardware change and the Rosetta deadline above.

The current alternatives each cover part of the same ground.

Safari's Add to Dock, described in Apple's article on Safari web apps, requires macOS Sonoma 14 or later, runs natively on Apple silicon, and keeps cookies and website data separate from Safari. Chrome's Install page as app, under More, then Cast, save, and share, gives a window that can use the extensions of the Chrome profile it came from, and shares that profile's sign in. A site to app tool built on an installed Chromium browser runs on both Apple silicon and Intel Macs, gives each app its own browser profile, and fills in the URL, name, and icon from presets listed on its supported services page.

What none of them reproduce exactly is Fluid's whitelist model and its JavaScript bridge. Anyone who depends on a userscript that sets Dock badges should test that workflow first.

What to change first

Check the processor in About This Mac. On Apple silicon, plan to move each Fluid app before macOS 28, starting with the one opened most often. If Safari is the main browser, Add to Dock is the shortest path. If Chrome extensions or separate sign ins per app matter, Kagemusha is one tool built for that.