Why Coherence X leans on a Chrome extension

Anyone who opens the Extensions window inside a Coherence app finds something unexpected: the app that was supposed to remove the browser has a browser extension running inside it. That looks like a contradiction, and it is the most informative thing about how this category of tool works. The extension is not an add on. It is where most of the behaviour that makes a wrapped site feel like a Mac application actually lives.

A wrapper on someone else's browser has no other way in

Coherence X does not ship a browser engine. Each app it creates runs on a Chromium based browser that is already installed, with Chrome, Brave, Edge and Chromium including the ungoogled build listed as supported engines. That decision buys rendering that matches the browser exactly, which is why internal portals tested only against Chrome behave correctly inside the app.

It also means the tool cannot reach into the running window the way a self built Electron application could. An Electron app owns its own process and can intercept navigation, window creation and link handling in its own code. A tool that borrows Chrome has none of that. The only supported interface into a running Chromium window is the extension API. So the behaviour that separates an app from a bare browser window gets implemented as an extension, and the tool installs it into every app it builds.

Coherence apps are based on third-party browsers, so the Coherence extension enables additional functionality that would not otherwise be possible. The extension is lightweight, offline, and private. Source: help.bzgapps.com

Read that as an architectural statement rather than a marketing line. Everything the extension does is something the borrowed browser does not do on its own, and everything it cannot do is a limit of the extension API.

What the extension is actually doing

The settings for it live inside each app, under the Window menu, in the Extensions entry. Three jobs account for most of its usefulness.

Deciding which links stay inside the app

The majority of the interface is given over to what the developer calls Intelligent Whitelisting. The rules decide which addresses belong to this app. Anything that does not match is handed to the default browser instead of loading in the app window.

This is the behaviour that keeps a wrapped app from decaying back into a browser. A chat app without link rules becomes a general purpose browser the first time somebody posts a news article, and after a week the window contains a support ticket, a spreadsheet and three articles nobody meant to open. With rules in place, the app window only ever holds the service it was built for, and everything else lands where links normally land.

It is worth setting the rules slightly wider than the bare domain. Sign in flows, file previews and payment screens frequently sit on adjacent hosts, and a rule that is too tight will bounce a login redirect out to the default browser in the middle of authenticating.

Making the Dock icon behave

Without the extension, closing the window of a Chrome based app and clicking its Dock icon opens a generic new browser window. The extension remembers the last visited state and brings it back instead. The developer calls this Quick Resume, and it is joined by window handling that distinguishes a window the reader opened from a popup the engine raised, which is what keeps sign in dialogs and file pickers from being treated as new app windows.

This sounds minor and is not. The Dock icon is the entire reason for building the app. An icon that reliably returns to where the reader left off is an application. An icon that sometimes produces an empty browser window is a shortcut with extra steps.

Getting past Google sign in

Google refuses sign in attempts from browser frames it does not recognise, which is the wall most hand rolled wrappers hit first. The extension switches the user agent to Firefox when a Google sign in occurs, and the setting can be switched back once the account is authenticated. That is a workaround for someone else's policy rather than a feature, and it is a good example of the kind of maintenance a wrapper carries on behalf of the reader.

What actually breaks if it is switched off

The extension is included automatically, and it can be excluded. In Coherence Preferences, deselecting "Automatically include Coherence extension" stops it being added to new apps.

Turning it off leaves a window that renders the site correctly and does very little else. Link rules stop applying, so every link opens in the app. The Dock icon stops restoring the previous session. The Google sign in path loses its workaround. What remains is roughly what Chrome's own install as app command already provides for free, which makes the extension the practical answer to why a paid tool exists next to a built in one.

The reasonable case for switching it off is a strict environment where the extension inventory of every app has to be justified, or a site that conflicts with the injected behaviour. Outside those, leaving it on is the default for a reason.

Adding other extensions to one app and not the rest

The second half of the extension story is the one most people are searching for. Because each app runs its own isolated instance of the browser, extensions from the Chrome Web Store install into a single app rather than across the whole browser.

That granularity is genuinely useful.

A password manager can live inside the two apps that need it and be absent from the rest, which shrinks the surface where credentials are reachable. An ad blocker can run inside a news reader without touching an internal admin console, where blockers routinely break layouts. A grammar checker can sit inside the writing app and nowhere else, so it never sees a payroll screen.

The cost is inventory. Extensions installed per app have to be updated and reviewed per app. Five apps carrying the same password manager is five installations to keep track of. The workable habit is to keep the per app extension list short and deliberate, and to treat anything needed in every app as a sign that the browser is the right place for it.

Writing link rules that hold up

Link rules are the setting most people configure once, get slightly wrong, and then blame the tool for. Four situations account for nearly all of the trouble.

Sign in almost never happens on the same host as the service. A Google based login moves through accounts.google.com, a Microsoft one through login.microsoftonline.com, and a corporate single sign on through whatever the identity provider uses. A rule limited to the service's own domain will eject the reader to the default browser at the exact moment the redirect fires, and the session that finishes there is the wrong session. Add the identity host before adding anything else.

File previews and downloads are the second case. Attachments, exported reports and generated documents are frequently served from a separate storage host or a signed URL on a content network. If those bounce out, the app looks broken in a way that has nothing to do with the site.

Payment and billing screens are the third. They often sit on a processor's domain, and a reader who is sent to the default browser mid checkout will usually start over rather than continue.

The fourth is the opposite failure: rules that are too generous. Allowing an entire top level domain because one subdomain was needed puts the whole company's web presence back inside the app window, which is the situation the rules existed to prevent.

A workable habit is to start with the service host plus its identity host, use the app for a week, and add hosts only when something concrete bounces out. Rules built that way stay short, and short rules are the ones that still make sense a year later.

Where the work happens in each route

Behaviour	Safari, Add to Dock	Chrome, install as app	Coherence X
Isolated session	Handled by macOS	No, shares the profile	Per app instance
Link sent to default browser	Built in	No	Extension rules
Dock click restores state	Built in	Generic window	Extension
Custom icon	App settings	Taken from the site	App settings
Extensions inside the app	Safari extensions, per app	Profile extensions	Chrome Web Store, per app
Google sign in workaround	Not needed	Not needed	Extension user agent switch
Requirement	macOS Sonoma 14 or later	Any current Chrome	macOS 13.5 or later, plus a Chromium browser
Cost	Free	Free	From 39.99 USD, 14 day trial

The pattern in the right hand column is consistent. Where Safari gets a behaviour from the operating system, a Chromium wrapper has to get it from an extension. That is neither better nor worse on its own. It decides what to check before committing to a tool.

What this tells you about picking any wrapper

The useful question when comparing tools in this category is not the length of the feature list. It is where each feature is implemented, because that determines what happens when something underneath changes.

A behaviour provided by macOS keeps working until Apple changes it. A behaviour provided by an extension keeps working until the extension platform changes, and Chromium's extension platform has changed substantially in recent years. A behaviour provided by a bundled engine keeps working until the bundle is rebuilt, which is why abandoned wrappers keep rendering old pages long after they stopped being safe to use.

The second question is the cost of leaving. A tool that can recreate a full set of apps from a list in a couple of minutes carries almost no lock in, and pairing it with the free built in routes costs nothing. A tool that took twenty minutes of manual configuration per app carries a great deal. Checking a Supported services list is the quickest way to see how much of the setup is already done for common sites, and a Features page shows whether link rules, isolated sessions and icons are covered or whether the tool only opens a window. The Pricing page is worth reading against what the free routes already deliver, because for two or three sites they usually deliver enough.

What to change first

Open the Extensions window inside one existing app and write the link rules for that single site before adding another app. The rules are what stop the window from turning back into a browser, and they take about a minute. If the rules hold for a week and the Dock icon reliably returns to the right place, Kagemusha and the other paid tools are worth pricing against the free routes for the rest of the list.