Fluid alternatives: what you can drop

Most people searching for Fluid alternatives are not stuck yet. The apps still open, the sites still load, and nothing is broken this morning. What changed is the expectation that this will hold. That makes it a good moment to do the work in the right order, which means taking an inventory of what a Fluid app is actually doing before looking at anything that might replace it. Half of the features usually turn out to be unused, and the replacement question gets much smaller once that half is removed from the list.

Start from the shipping build, not the reputation

The download page states the facts plainly. The current build is version 2.1.2, the archive is roughly 6.3 MB, and the stated requirement is macOS 10.12 or later. The update feed that the app itself checks was last built on 19 October 2018, and the code signature on the downloaded bundle carries a timestamp from the following day. The bundle is notarized, so it opens on a current Mac without a Gatekeeper block.

Pricing is also stated directly rather than being buried in a comparison chart.

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 three paid features are pinning an app to the status bar, userscripts and userstyles, and full screen mode. Nothing on the site announces an end of life, the download still serves, and the developer named in the code signature is the same one credited on the site. No price change has been posted.

One fact does push toward a decision. Both the creator app and the template it copies to build each app contain Intel instructions only. On an Apple Silicon Mac they run through translation, and Apple has published the horizon for that. Rosetta remains available through macOS 27, and from macOS 28 it is kept only for certain older games that depend on Intel frameworks. That is a schedule, not an outage, which is why the useful response is an inventory rather than a rushed rebuild.

Break "Fluid" into the seven things it actually does

A single app built with Fluid is doing several unrelated jobs at once, and they do not all move together. Listed separately:

• A dedicated Dock icon that appears in the app switcher
• A window with no tab bar and no address bar
• A cookie jar and login session separate from the everyday browser
• A restriction on where the window may navigate, sending anything outside the allowed patterns to the default browser
• Userscripts and userstyles that rewrite the page on load
• Residence in the menu bar, summoned by a single key
• A user agent string that can be swapped so the site sees a different browser

The first three are commodity features on a current Mac and cost nothing to replicate. The last four are not, and they are where migrations go wrong. Someone who checks only the first three, finds three free options, moves everything over, and then discovers on day four that a userscript was quietly fixing an internal admin page has done the work twice.

The fastest way to find out which group applies is to open the preferences of an existing app and see which panes have been touched. A Fluid app carries panes for General, Tabs, Security, Shortcuts, Handlers, Whitelist, and four browser side panels. Panes left at their defaults represent features that were never in use. For a large share of setups, nothing outside General has ever been opened, and the honest answer is that only the Dock icon and the tab free window were ever needed.

What the built-in routes already cover

Before any tool enters the picture, check whether the service ships an official Mac app. If it does, the wrapper question disappears. When it does not, two routes are already installed.

Safari can add the open page to the Dock. The result is a window without tabs or an address bar, a Dock icon, and a session kept apart from ordinary Safari browsing. Chrome and Edge both offer installing the current page as an app, which produces the same shape with rendering identical to that browser, since it is that browser underneath.

Either route costs nothing and neither depends on translation, so the Rosetta schedule does not apply. Between them they cover the first three items on the inventory completely.

They do not cover the other four. There is no field for navigation patterns, no place to inject a script, no menu bar residence, and no user agent override. Icons follow whatever the site publishes, which becomes a practical problem the moment two apps are built from the same service for two different accounts and end up looking identical in the Dock.

Account separation deserves a note of its own, because it is the thing people most often assume will carry over unchanged. A Fluid app keeps its own cookies, which is what allows a personal account and a work account on the same service to stay signed in at once. The built-in routes preserve that separation, but they express it differently. Chrome ties an installed app to the profile it was installed from, so two accounts means two profiles rather than two apps built from the same window. Safari keeps each added web app apart on its own. Either way the outcome is achievable, but the setup steps are not the same ones, and copying the old mental model across is what produces an afternoon of confusing sign in loops.

When a dedicated tool is the answer, compare conditions

If one of those four features is load bearing, the comparison begins. The useful axis is not feature count, it is operating requirements and maintenance state, because those decide how long the setup survives untouched.

What to check	Fluid 2.1.2	Unite Pro	Coherence X6
Price	Free, 5 dollars for extras	From 39.99 dollars	From 39.99 dollars
macOS required	10.12 or later	15 or later	13.5 or later
Apple Silicon	Intel build only	Supported	Supported
Rendering engine	System WebKit	Its own native app	A Chromium browser already installed
Last release	October 2018	Current	Current

The figures come from each vendor's own page. Coherence is also distributed through Setapp, a monthly subscription that bundles it with a large catalogue of other Mac apps, which changes the arithmetic for anyone already paying for that. The vendor page cites 9.99 dollars, while Setapp's own pricing page lists the Mac plan at 14.99 dollars, so check the figure at the source before budgeting.

Read the table for prerequisites rather than price. The macOS floor is the line that removes options outright: a Mac that cannot run macOS 15 cannot run Unite Pro at all, regardless of what it costs. The engine row matters for a different reason. A tool built on an installed Chromium browser inherits that browser's behaviour exactly, which is useful for an internal console only ever tested against Chrome, and it also inherits the dependency, so moving or removing that browser affects every app built on it. Fluid borrows the system WebKit, which is why rendering inside an app from 2018 still tracks whatever Safari currently ships even though the app itself has not changed.

Anyone at the stage of matching features one by one will find them listed on Features, with the cost side set out on Pricing.

The features most likely to be dead weight

Usage frequency settles this faster than any specification sheet. A setting untouched for a month will not be missed.

User agent switching is the clearest candidate for removal. The presets that ship with Fluid are Safari 12, iOS Safari 12 for iPhone and iPad, Chrome 70, Firefox 62, and Internet Explorer 11, all of them from 2018. Presenting a current site with a seven year old browser string now causes more refusals than it avoids. The default option, which builds its string from the running system, ages better than every preset next to it. Browser side panels and the plug-in toggle belong in the same category, as does Java, which ships disabled.

The features worth protecting are narrower, and there are three of them.

Menu bar residence is the first. Replacing a single key summon with a Dock click adds steps to something done dozens of times a day, and no built-in route offers it.

Userscripts are the second. If a script is patching an internal tool, the replacement has to accept scripts or accept browser extensions, and that requirement alone eliminates most of the free routes.

Navigation restriction is the third. A setup that deliberately hands off links to the default browser depends on rules that the built-in routes do not expose, so it needs a tool with configurable link handling.

Sequence the migration so failures stay visible

Rebuilding everything in one sitting makes it impossible to tell which change caused which problem. Order the work instead.

Begin with the simplest daily app: one whose sign in does not pass through an external identity provider and which depends on no extensions. Rebuild that one through a built-in route and then use it untouched for a week. If nothing is missing, the remainder of the simple cases will behave the same way, and the job is mostly done.

Move next to anything that authenticates through a company account or an identity provider. The check here is narrow and worth doing immediately after rebuilding: confirm that the full sign in round trip completes inside the new window rather than stranding a callback in a browser tab.

Leave the script dependent and extension dependent apps for last, and treat a paid tool for that group alone as a legitimate outcome. There is no requirement to standardise on one tool. Mixed setups, with built-in routes for most apps and something dedicated for two or three, are common and perfectly stable. Per-service notes on what needs configuring before wrapping are collected on Supported services.

Running the same check on the next tool

The reason to write this down is that the next tool can end up in the same position. Four checks answer it, and all four can be done before paying anything.

The first is the date of the last release, visible on a changelog or in the code signature timestamp of the downloaded bundle. The second is architecture: select the app in the Finder, press Command+I, and read the Kind field, which will say Intel, Universal, or Apple Silicon. The third is whether new purchases are still being taken, which means confirming the buy path actually completes rather than trusting a price on a page. The fourth is whether the vendor has changed, which usually shows up in site copy or an announcement.

Those four predict remaining lifespan better than a feature comparison does. A price that has not moved says nothing about whether the foundation has shifted underneath it, and a tool that is actively maintained with a current architecture avoids a rebuild that a cheaper one will eventually force.

What to change first

Open the preferences of the Fluid app used most often and note which panes differ from their defaults. If only General has been touched, rebuild that app through a built-in route today and leave the rest alone until it has proved itself for a week. If the Whitelist or the userscript pane has real content in it, that app belongs on a maintained tool such as Kagemusha, and the rest can still go the free route.