Unite: what it does and where it breaks down

Searching the name usually means one of two things. Either the difference between this and a browser bookmark saved to the Dock is unclear, or the marketing page has been read and the limits are still missing. Product pages describe capabilities well and limits badly, which is the wrong way round for anyone deciding. What follows covers what the tool builds, what engine sits underneath it, the three shapes an app can take, and the four places where it stops being the right answer.

What actually gets built

Hand the tool a URL and it assembles a real application bundle, then saves it to the Applications folder or wherever else is chosen. The result behaves like software rather than like a shortcut: its own icon, its own place in the Dock and the app switcher, its own window, its own keyboard shortcuts. Building one takes roughly half a minute.

The structural difference from a bookmark is data isolation. Cookies, sessions, and site storage belong to that one app and are not shared with the browser or with any other app built this way. Two accounts on the same service can therefore stay signed in side by side, permanently, with no profile switching. For anyone juggling a work account and a personal account on the same platform, that single property is often the entire reason to bother.

The product changed generation on 9 March 2026, when the previous version, Unite 6, was replaced by the current one. The current series is 1.x, and updates have arrived at roughly monthly intervals: 18 June, 26 July, 9 August, and 30 August 2026. The product is still sold, still updated, and still run by the same company. No discontinuation, no pause on new licences, and no change of owner has been announced.

The engine decision, and what follows from it

This is not a repackaged copy of an existing browser. The vendor's own comparison page states that it runs on a custom browser built specifically for site specific browsers, powered by Apple's open source WebKit 2, which is the same engine family that Safari uses and that ships with macOS.

That choice produces one clear benefit and one clear cost.

The benefit is weight. The same vendor's Chrome based alternative produces apps of 200MB and up, while apps from this tool are listed at around 90MB. Running four or five of them all day makes that difference visible in memory and disk rather than only on a spec sheet.

The cost is extensions, covered below. It is worth naming early because it is not configurable. An engine choice is made once, by the developer, and no setting reverses it.

Three shapes, chosen per app

Every app runs in one of three modes, picked at creation and changeable afterwards at any time.

Mode	What it looks like	Suits
Normal	Standard window with toolbar, tabs, pinned tabs	Long sessions: mail, project tools, documents
Sidebar	Resizable panel on the left listing tabs, content on the right	Sites with many sections visited in rotation
Menu Bar	No Dock presence, a popover drops from the menu bar	Short repeated visits: assistants, dashboards, timers

Normal and Sidebar can additionally float above other windows, which is set in the appearance options. A Menu Bar app can be opened as a full window on demand without permanently changing its mode, so the choice is less final than it looks. The mode is still the most consequential setting, because it determines whether the app occupies Dock space and whether it stays visible while other work happens in front of it.

The parts that reach past the browser

For recognised services, native macOS integrations are detected automatically at build time and offered as toggles. Four exist today.

• Dock badges showing unread counts on the app icon
• Meeting notifications from Google Calendar and Outlook, delivered through Notification Center
• A menu bar overlay for AI chat services, callable from anywhere without switching apps
• Playback speed controls for video sites, via keyboard or on screen controls

The 30 August 2026 update added a further one: an app built for Gmail or Outlook can be set as the Mac's default mail client, so a mailto link anywhere in the system opens a pre filled compose window inside that app. These are the capabilities a browser shortcut cannot reach by definition, and they are the honest reason to pay for a wrapper rather than pinning a tab.

Appearance and permissions, scoped to one app

A second layer of settings works per app, and this is where the gap against opening the same site in a browser is widest.

On appearance, user scripts and user styles can be applied to a single app. Removing a specific element, tightening padding, or forcing a colour affects that app only. Light only sites can be converted to a dark appearance automatically, and zoom can be set per site. Doing the same things through browser extensions applies them everywhere, which is exactly the problem.

On permissions, notifications, camera, microphone, screen sharing, and location are each set per site to allow, deny, or ask. Cookie policy is also per app, with options to accept all, block all, or block third party cookies only. Download locations are per app too, which quietly solves the problem of work files and personal files landing in the same folder.

How built apps stay current

A detail worth knowing before building a library of ten apps: the apps do not update themselves independently. The builder updates itself, and by default it then applies that update to every app already created, so bug fixes and macOS compatibility work reach the whole library at once. Turning that default off freezes each app at the version it was built with until it is edited and saved again.

That behaviour also supplies the standard repair procedure after a major macOS upgrade. If an app misbehaves once the OS has moved, the documented order is to check for a builder update first, then edit and save the affected app so it is rebuilt against the current version, and only then contact support. Knowing that a rebuild is a two click operation removes most of the fear around upgrading macOS with a dozen of these in the Dock.

The same mechanism explains why a dormant library is a liability. An app built a year ago and never touched, with automatic updates disabled, is running old code against a website that has changed underneath it. Anyone who keeps these apps for years should either leave automatic updates on or set a reminder to rebuild after each macOS release.

Where it breaks down

Third party extensions do not work. This is the limit that sends most people elsewhere, and the comparison page states it plainly. A password manager extension, a grammar checker, a translation extension, or an internal company extension cannot be loaded. Some of the ground is covered by built in equivalents: ad blocking is built in, a password manager is built in, and the 26 July 2026 update added 1Password autofill as a beta, extended on 9 August to handle multiple signed in accounts. Everything outside that list has no substitute. The workable approach is to split daily sites into those that depend on an extension and those that do not, and only convert the second group.

Site compatibility is a moving target. Apps built this way present themselves to websites differently from a mainstream browser, so behaviour occasionally diverges. The changelog is the honest record of what that means in practice. The 18 June 2026 release fixed behaviour on sites running bot detection, refreshed the built in user agents, fixed user agent presets resetting after Safari or macOS updates, fixed NotebookLM modules failing to load, and fixed fullscreen playback on YouTube playlists and Netflix. The 26 July release fixed typing and response streaming being slower on ChatGPT style sites than in Safari or Chrome. None of that is unique to this product, it is the standing tax on every site specific browser. What it means for a reader is procedural: test the one site that matters most before committing, and treat update frequency as a feature.

The OS floor and the licence terms are hard edges. The current version requires macOS 15 or later, on Apple silicon or Intel. A Mac still on macOS 14 or earlier is simply outside the supported range. One app can be created for free with no feature restrictions inside it, and a licence is needed from the second app onward. A licence is active on one Mac at a time and has to be released before moving to another machine. Licences bought through the subscription bundle require opening the main application once every 30 days so the subscription can be verified, otherwise the created apps display a verification prompt. Apps cannot be handed to somebody without a licence of their own.

Migrating from the previous generation loses a few things. Apps built with Unite 6 can be converted, and the conversion carries over the URL, name, icon, mode, cookies and session, saved passwords, bookmarks, history, and user scripts. It does not carry over the old compact window style, which no longer exists and becomes a normal window, or the legacy Dock features, which have been replaced and need configuring again. Conversion also requires an active licence, so the free tier cannot be used to rescue an old library.

Who it does not suit

Three groups should stop reading at this point rather than spend an evening on setup.

Anyone whose core work depends on browser extensions will fight the tool constantly. Anyone on macOS 14 or earlier cannot install the current version at all. Anyone who wants a single window holding many unrelated sites is describing a browser, and already has one.

The group left over is specific and large: people running three to five services all day, who want notifications to arrive, accounts to stay separated, and a Dock icon that goes straight to the right place. A practical way to size that group for a particular person is to look through a list of services that commonly get converted, and the Supported services page is a quick way to check a shortlist against categories rather than guessing. If the list stops at one service, the free tier is the whole answer.

For the mechanics of what is decided at build time versus what can be changed later, the Guide walks through the creation flow in order, which is the difference between configuring an app once and rebuilding it three times. Mode, link handling, and permission defaults are the settings worth getting right on the first pass.

What to change first

Pick the single site that is hardest to find when it is buried in tabs, and build that one first while the free tier still costs nothing. Run it for a fortnight against the four breakdown points above, particularly extensions and site compatibility, before any licence is bought. If the result holds up and a second candidate appears, compare tools on engine, extension support, and one time versus recurring pricing rather than on feature counts, which is the same short checklist that makes a page like Kagemusha quick to evaluate.