Fluid: how to decide what you need

Feature tables are a bad way to choose a tool that turns a website into a Mac app. Every option in the category produces the same visible result, which is an icon in the Dock and a window without a tab bar, so the columns end up looking interchangeable. What actually separates them is a short list of conditions that cannot be changed after the choice is made. This walks through which sites deserve an app in the first place, the five conditions worth comparing, how Fluid scores against each one, and how to price the risk of getting it wrong.

Narrow the target before looking at any tool

The first decision is not which tool. It is which browser tabs are worth converting. Skipping this step is how people end up paying for capabilities that none of their sites require.

Three questions settle it:

• Is the site opened three or more times a day
• Should it always start from the same screen
• Has it ever been lost in a row of tabs

A site needs all three. Something opened once a week gains nothing from a Dock icon, because the time cost was never in finding it. Something entered from a different page each time cannot be pinned to a starting screen, which removes the main benefit. In practice the list lands somewhere between three and six entries, and that count becomes the denominator for every cost calculation later.

Then check each survivor for an official Mac app. If the vendor ships one, the wrapper question is closed for that entry and the list gets shorter. Only what remains is worth comparing tools over.

Five conditions decide the outcome

A specification sheet in this category runs to dozens of rows. Five of them change the result.

The rendering engine is the first. A tool either bundles its own engine, borrows the WebKit that ships with macOS, or drives a Chromium browser already installed on the machine. An internal console that was only ever tested against Chrome argues for the third, because it will be Chrome underneath. The same choice creates a dependency, since moving or removing that browser affects every app built on it.

Session separation is the second. The question is whether two accounts on the same service need to be open at once. A design that gives each app its own cookie store answers this directly. A design that ties an app to a browser profile answers it too, but through profiles rather than apps, and the setup steps are different.

Link routing is the third. Some links should stay inside the window and some should be handed to the default browser. A service used entirely on its own never exercises this. Mail, issue trackers and anything that routes to external documents exercise it dozens of times a day.

Operating requirements are the fourth. The minimum macOS version and the supported processor architecture. These are not features, they are eligibility. Failing either one makes the rest of the sheet irrelevant.

Purchase model and maintenance are the fifth. One time, subscription, or free, plus the date of the most recent release. A one time price is only cheap if it never has to be paid again in rebuild time.

Everything outside those five, including icon handling, tab support, keyboard shortcuts and notification behaviour, can be adjusted afterwards. Comparison time is better spent on the five that cannot.

Fluid measured against the five

Running the same five conditions against Fluid produces a clear picture, using only what the official site and the shipped bundle state.

On rendering, Fluid carries no engine of its own and draws with the WebKit that macOS provides. This is why an app built years ago still renders modern pages. The description on the site has not changed since it was written.

Fluid lets you create a Real Mac App ( or "Fluid App" ) out of any website or web application, effectively turning your favorite web apps into OS X desktop apps. Source: fluidapp.com

The phrase "OS X desktop apps" is itself a data point about when the copy was last revised.

On session separation, each created app holds its own cookies, so two accounts on one service can sit side by side as two Dock icons.

On link routing, there are dedicated preference panes. A created app carries panes for General, Tabs, Security, Shortcuts, Handlers, Whitelist and four browser side panels. The Security pane holds the switch that controls whether the window may navigate anywhere, and the Whitelist pane holds the URL patterns that apply when it may not. The default state allows navigation anywhere, so the whitelist only takes effect once the restriction is deliberately switched on.

On operating requirements, the stated floor is macOS 10.12 or later, which is unusually low and makes Fluid viable on hardware that newer tools exclude outright. Architecture is the other side of that coin: both the creator and the app template contain Intel instructions only, so an Apple Silicon Mac runs them through translation.

On purchase model, the app is free and five dollars unlocks three extras, with the most recent release dated October 2018.

Read together, those five lines describe a specific fit rather than a verdict. An older Mac, a need for fine grained link rules, and a preference for spending nothing points one way. A new machine and a long horizon points somewhere else.

One detail from the same bundle is worth keeping in view while comparing, because it is easy to misread in either direction. The user agent presets that ship with Fluid are Safari 12, iOS Safari 12 for both iPhone and iPad, Chrome 70, Firefox 62 and Internet Explorer 11. All of them date from 2018, so choosing one now tells a current site that it is talking to a seven year old browser. The default option is different in kind, since it assembles its string from the running system rather than from a fixed list, which means it stays current without intervention. The lesson generalises beyond this one product. Any feature that hard codes a value about the outside world ages badly, while any feature that reads that value at run time does not, and that distinction is worth applying to whatever tool ends up on the shortlist.

Check whether the tool is still being sold

The condition most often skipped is the current commercial state of the product, because a price on a page keeps looking valid long after the situation behind it has changed. Four checks cover it:

• Has an end of life been announced
• Are new purchases still being accepted
• Has the company or developer behind it changed
• Has the pricing model changed

All four can be confirmed from official pages in a few minutes. For Fluid, none of them have moved. No end of life notice appears, the download still serves, the developer name in the code signature matches the site, and the price is still five dollars.

Applied to a shortlist of three candidates, the same four checks routinely produce a difference that no feature table shows. Products in this category have changed hands, and products have moved from a one time purchase to a subscription while the headline number stayed familiar. A price that has not changed says nothing about whether the thing behind it has. The cost breakdown for a tool that is actively sold is laid out on Pricing, and the questions that come up most often before committing are collected on FAQ.

Price the cost of choosing wrong

Comparing purchase prices alone makes the cheapest option look best. The real figure is the price plus the rebuild time it eventually triggers.

The arithmetic is simple. Four apps at roughly twenty minutes each to recreate and reconfigure is eighty minutes per migration, before counting the time spent verifying sign in round trips and debugging the one app that misbehaves. Whether that happens once or every three years matters more than a thirty dollar difference in sticker price.

Rebuilds have three causes. The first is falling outside the operating requirements, usually after a macOS upgrade. The second is the disappearance of whatever the tool was built on, which is what happens to browser dependent designs when the underlying browser is replaced. The third is the product ceasing to be available.

Only the first two are preventable at selection time. Preventing the first means comparing the tool's minimum macOS against any upgrade planned in the next two years, in both directions. A floor equal to the current release excludes older hardware. A floor that is extremely low often signals a long gap since the last update, in which case processor support becomes the binding constraint instead.

Preventing the second means naming the dependency out loud. Does the tool depend on an installed browser, on a system framework, or on nothing but itself. If there is a dependency, the question becomes whether that dependency is something likely to change. For anyone considering a switch of daily browser, that single question eliminates a whole design.

Decide whether a free route already qualifies

Before comparing paid tools at all, test whether a built-in route covers the requirement. One condition decides it: link routing, the third axis.

Adding a page to the Dock from Safari, or installing a page as an app from Chrome or Edge, satisfies rendering, session separation and operating requirements at no cost. Neither exposes link routing rules.

So a site used mostly on its own is finished at this point, with no purchase involved. A site that constantly sends the reader outward is where a paid tool earns its price.

Count rather than estimate. Roughly ten or more departures per day from inside an app to an external page is the threshold where routing rules stop being cosmetic. Mail and issue trackers clear it easily. Timesheets, expense forms and internal request screens often never leave their own domain at all. Most people have both kinds, which is why the test runs per app rather than per person, and why mixing a free route for most apps with a paid tool for two of them is a normal outcome rather than a compromise.

Put the target list and the conditions on one page

Turning all of this into something usable takes one small table. Paper or screen, it does not matter.

Column	What goes in it
Site	Opened three or more times a day
Official Mac app	Yes or no
Simultaneous accounts	How many are needed
External links	Rough count per day
macOS in use	Version number

Fill in three to six rows, then hold the candidate tools against them. Rows with an official app need no tool. Rows with a near empty link count are done with a free route. Only what is left justifies a purchase, and often that is one or two rows rather than the whole list.

Since the setup steps differ noticeably from service to service, checking Supported services once the shortlist is set will surface the configuration traps before they cost an afternoon.

What to change first

Build the table before opening another comparison page, because the rows will eliminate most of the candidates without any further reading. If everything on it has a low external link count, take the free route today. If two rows do not, put those two on a maintained tool such as Kagemusha and leave the rest alone.