Fluid on a modern Mac: what still works

The search for a Fluid app on a Mac usually starts from a memory rather than a need. Somebody remembers a small utility that took a URL, asked for a name, and produced a real application bundle that lived in the Dock. That memory is accurate. The utility still exists, it still downloads, and on most Macs it still runs. What has changed is everything around it. The current build predates the Apple silicon transition, the download page carries a 2019 copyright and still says "Mac OS X", and Apple has already published the release after which Intel-only applications stop launching at all. That is the shape of the decision: not whether the tool works today, but how much longer today lasts.

What the tool actually does

The concept is unchanged since 2008. Enter a website's address, give it a name, optionally point it at an icon file, and click Create. Seconds later there is an application bundle sitting in the Applications folder that opens that one site in its own window, with its own Dock icon and its own entry in Command Tab. Nothing is compiled, nothing is downloaded from the site beyond what a normal visit downloads, and the page inside is still rendered by the system's web engine. The bundle is a container, not a rewrite.

The engine matters more than most comparisons admit. Version 2 was rebuilt on Apple's WebKit2 API with process separation, which means the actual rendering is done by the copy of WebKit that ships with macOS and gets patched every time macOS is patched. An unmaintained wrapper does not mean an unmaintained browser engine. The pages inside are as current as the operating system. The risk sits in the shell, not in the renderer, and that distinction decides which of the concerns below are real.

Pricing has never been the obstacle. The download is free and the number of apps it can create is unlimited. A five dollar license unlocks a short list of extras, and the page states it plainly.

Fluid is free. You can download Fluid for free and create as many Fluid Apps as you like. However, for $5, you can purchase a Fluid License which unlocks a few extra features. Source: fluidapp.com

The extras are named on the same page and there are three of them: pinning an app to the status bar, using userscripts or userstyles inside an app, and full screen mode. That is the entire paid list, and it is worth reading carefully, because what is absent from that list is also absent from the product.

The dates on the download page are the real specification

The download page reports a 6.3 MB download, version 2.1, requiring "Mac OS 10.12 or later", under a copyright notice dated 2019. The interface language on the same page refers to the Mac OS X Status Bar and to OS X desktop apps, phrasing Apple retired in 2016. Version 2.1.2 was released in October 2018. There has been no release since.

That gap has one consequence that outranks all the others. A third-party compatibility index that checks application binaries recorded Fluid as x86 only, with no Apple silicon build, when it last inspected version 2.1.2 in March 2021. Apple finished moving the entire Mac lineup to Apple silicon in 2023, so a Mac bought in the last few years is certain to be one. On those machines the app does not run natively. It runs through Rosetta 2, the translation layer, which is fast enough that the difference is rarely visible in a web wrapper. The problem is not speed. The problem is that Rosetta has a published end date.

Rosetta puts a date on the decision

Apple has stated the timeline rather than leaving it to be inferred. The first stage is already in effect on current systems.

macOS 26.4 or later: Users may receive a system notification when launching apps that rely on Rosetta, alerting them to update to an Apple silicon native version. Source: developer.apple.com

The same announcement names macOS 27 as the final release to support Rosetta, after which Intel-only apps no longer run on Macs with Apple silicon. The one carve-out is for older, unmaintained gaming titles that rely on Intel-based frameworks, which is not a category a web wrapper falls into.

For a tool with no release since 2018 and no publicly announced maintainer activity, an Apple silicon build arriving before that deadline is not something to plan a workflow around. Anyone installing it now is installing something with a known expiry. That is not a reason to avoid it for a weekend experiment. It is a strong reason not to move eight daily-use sites onto it.

What still works, and what was never there

On a Mac running macOS 26 today, the core function works. The bundle builds, the icon appears in the Dock, the window has no tab strip and no address bar, and the app shows up as its own entry in Command Tab and Mission Control. For a single site that is opened constantly and does nothing complicated, that is genuinely the whole job.

The gaps are the things the download page never claimed. There is no ad blocker, no per-app permissions manager, no menu bar or sidebar layout mode, no user agent switcher, and no documented behaviour for web push notifications. Notification support in particular was added to macOS web wrappers years after this build shipped, and a page that still says "Mac OS X" is not a page that will tell anyone whether it was adopted. When a tool has no release notes and no support channel, anything not written down is not a feature. It is a gamble.

Icon handling is the other frequent surprise. The tool accepts a custom icon at creation time, which was a real advantage in 2010 when nothing else did. Every current route now offers some form of icon control, so that particular reason to reach for it has quietly expired.

Checking what is already installed

Anyone who built apps with this years ago has them sitting in the Applications folder right now, and there is no need to guess which ones are affected. macOS reports the architecture of every application in three places.

The fastest is Finder. Select the app, choose Get Info from the File menu, and read the Kind line at the top of the panel. An Intel-only build is labelled Application (Intel). A native one is labelled Application (Universal) or Application (Apple silicon).

The second is Activity Monitor, which is more useful when the app is running. Open it, and if the Kind column is not visible, right-click the column headers and switch it on. Every running process is listed as either Apple or Intel, which shows at a glance how much of the Dock is still going through translation.

The third is the command line, for anyone who wants to check a batch at once. Running lipo -archs against the executable inside an app bundle prints the architectures it contains. A result of x86_64 alone confirms there is no Apple silicon slice.

Doing this once is worth the two minutes, because the answer is rarely limited to one app. Old wrappers, old menu bar utilities, and old installers tend to have been collected in the same era, and macOS 27 will retire all of them together rather than one at a time.

Moving off it without losing anything

Migration is simpler than it looks because these apps hold almost nothing. There is no local database and no document format. What exists is a URL, a name, an icon, and a login session.

Write down the URL each app opens, which is visible in its preferences, and the name and icon file if either was customised. Rebuild each one with a current route. Sign in again inside the new app, because the session does not transfer between containers. Then delete the old bundle by dragging it to the Trash, exactly like any other application.

The one thing that does not survive is any userscript or userstyle attached to a paid licence. Those are the genuine lock-in, and anyone relying on them should check that the replacement route supports user scripts before deleting anything.

The four routes, side by side

	Fluid	Safari, Add to Dock	Chrome, Install as app	Current dedicated tool
Cost	Free, $5 license for three extras	Free	Free	Paid, one time licence or subscription bundle
Requirement	macOS 10.12 or later	macOS Sonoma 14 or later	Any current Chrome	Typically macOS 15 or later
Architecture	Intel only, runs via Rosetta	Native	Native	Native, Apple silicon and Intel
Last released	October 2018	Ships with macOS	Ships with Chrome	Actively updated
Login store	Not documented	Separate from Safari	Shared with the Chrome profile	Isolated per app
Notifications	Not documented	Yes, with a Dock badge	Yes, through Chrome	Yes, usually with a permissions manager
Custom icon	Yes, at creation	Yes, in the app's settings	No, taken from the site	Usually yes
Menu bar or sidebar mode	No	No	No	Common

The table answers the practical question faster than any argument. For a free route on a current Mac, Safari's Add to Dock does more than the 2018 build does, keeps its own cookie store so a second account of the same service can stay signed in, and cannot stop working when Rosetta goes away. Chrome's install option is the right pick only when the site depends on a Chrome extension or on a login that already lives in a specific Chrome profile. Paid tools earn their price on the rows the free routes leave empty: menu bar layouts, permission control per app, link routing between apps, and a maintainer who ships updates when macOS changes. A features list is the fastest way to check whether those rows matter for a given site, and the supported services directory shows which sites are already handled without any manual setup.

Which sites justify leaving the browser at all

The tool question is downstream of a selection question, and most people skip it. A site earns its own application when four things are true at once. It gets opened every working day. It has one purpose, so there is never a reason to navigate away from it. It sends something time-sensitive that must not be buried under thirty tabs. And losing it in a tab strip costs real seconds, several times a day.

Two or three sites usually clear that bar. Mail, a chat tool, a calendar, sometimes an admin dashboard for work. Anything opened twice a month fails the first test and belongs in a bookmark. Anything that is used for research, where following links outward is the point, fails the second test and is actively worse inside a window with no address bar.

The other filter is account separation. If the same service is used with a work account and a personal account, the route has to keep two cookie stores apart, and that single requirement eliminates the Chrome option outright, because installed Chrome apps follow the profile that created them. Working out that requirement first is what makes the tool comparison short. A setup guide is more useful once the list of sites is decided than before.

What to change first

Pick the one site that gets opened most and give it a window of its own this week, using whichever route is free on the current version of macOS. Only after living with that for a few days is it worth deciding whether the missing rows in the table above are worth paying for, and Kagemusha publishes its pricing openly for exactly that comparison.