ChatGPT as a Mac app: how to decide what you need
There are four ways to end up with ChatGPT in the Dock on a Mac: the official desktop app, a Safari web app, a Chrome installed app, and a purpose built wrapper. Comparison posts list all four with pros and cons and leave the reader exactly where they started, because pros and cons only resolve once the conditions are applied in a fixed order. Applied in the wrong order, every route looks defensible. Applied in the right order, most readers are down to a single option by the third condition. The order below is what makes the decision finish.
Why the comparison stalls
A table puts speed, cost, permissions, accounts, and maintenance in columns of equal width. They are not equal. Two of those conditions eliminate options outright, and three of them only rank options that are already available.
The eliminating conditions are the macOS version and who controls the machine. Both are matters of fact, verifiable in under a minute, and neither depends on preference. The ranking conditions are usage frequency, account separation, and who maintains the thing after it is built. Those depend on habits, and habits are harder to assess honestly, which is exactly why they belong later. By the time a reader reaches them, there are usually two candidates left rather than four.
So the sequence is: macOS version, then device ownership, then how often and how long it opens, then how many accounts, then who fixes it later.
Condition 1: what the macOS version leaves standing
Two of the four routes have a hard floor here.
The official app requires macOS 14 along with Apple Silicon or an Intel processor, and no release for older systems is planned. Safari's ability to save a page as an app arrived in macOS Sonoma 14. Both sit on the same side of the same line, so a Mac that cannot reach Sonoma loses two options at once.
Chrome supports macOS 13 and later. On a Mac held at Ventura, the Chrome route and a purpose built wrapper are what remain, and the comparison just became a choice between two things rather than four.
Working out which machines fall outside takes one lookup. Sonoma 14 support starts at the 2018 MacBook Pro and the 2018 Retina MacBook Air. A 2017 model tops out at Ventura 13 regardless of how well it performs. The About This Mac panel under the Apple menu settles it.
A managed fleet deliberately kept one major version behind produces the same outcome. The question becomes whether to wait for a policy refresh measured in months or to choose from the routes that work today.
There is also a branch inside the official option itself. As of July 9 a new desktop app combines Chat, Work, and Codex, and the older macOS app was renamed ChatGPT Classic and is still supported. Instructions written before that date describe Classic. Anyone comparing notes with a colleague should establish which of the two is being discussed before arguing about features.
Condition 2: who controls the Mac
The second question is whether the machine is personal or issued by an employer. Three things follow from the answer: whether software can be installed at all, whether system level permissions can be granted, and what the management software silently blocks.
The official app's ability to read the frontmost application depends on Accessibility access. That is the same permission class used by automation tools and screen readers, and it is a standard target for device policy. An administrator setting can disable the feature outright, so a missing menu item on a work Mac is often configuration rather than a fault.
Browser based routes are strong on exactly this condition. Nothing new is installed, the browser is already approved, and the resulting app lands in the Applications folder inside the home folder, which needs no administrator rights.
On a machine where installing software is prohibited, condition 2 alone reduces the field to Safari or Chrome. Everything after this point is about choosing between those two.
Establishing the answer does not require a conversation with IT. If System Settings shows a profile installed by an organisation, or if dragging an application into the system wide Applications folder prompts for credentials that are not available, the machine is managed and the conclusion follows. The distinction that matters is between the system wide Applications folder and the one inside the home folder, since the second accepts files without elevated rights and is exactly where browser built apps are placed.
Condition 3: how often it opens, and for how long
With the facts settled, usage decides the rest. Two numbers matter: openings per day, and minutes per opening.
High frequency with short sessions makes the cost of opening dominant. The official app's floating bar exists for this pattern, since the current screen never has to be left. Above roughly thirty openings a day, it is worth revisiting conditions 1 and 2 to see whether the official route can be made to work.
Low frequency with long sessions inverts the picture. If each visit lasts half an hour, the two seconds saved at launch are noise. A separate window and a Dock icon are enough, and both browser routes provide them.
A third pattern sits between them: the window that stays open all day and gets glanced at rather than launched. For that habit, neither launch speed nor a hotkey carries much weight, and what matters instead is whether the window survives being ignored. A separate app keeps its own place in the application switcher and does not get closed accidentally along with a browser window full of unrelated tabs. Readers in this group often find the decision easier than they expected, because almost every route serves them equally well.
When the honest answer is unclear, count for three days. Perceived frequency and actual frequency diverge more often than not, usually in the direction of overestimating how much the hotkey is used.
Notification behaviour belongs to this condition too. A Safari web app can show an unread count as a red badge on its Dock icon, but the permission prompt has to be answered inside the web app rather than inside Safari. Only then does the app appear in System Settings under Notifications, listed by its own name instead of a URL. For anyone who closes the window between sessions and relies on being pinged, that detail is worth testing before committing.
Condition 4: how many accounts
Readers who keep a work login apart from a personal one should treat this as the deciding condition, because the routes differ structurally.
A Safari web app shares no browsing history, cookies, website data, or settings with Safari. The separation is automatic, which suits running two accounts side by side without either one leaking into the other.
A Chrome installed app belongs to the profile it was created from.
A web app is an app built for the web that you can access on any device. You can use web apps to have a website work as an app and access it on your computer or mobile devices through the launcher or home screen. Source: support.google.com
Separating accounts on the Chrome route therefore means separating profiles first, then installing from each profile. That is one extra step at setup, and in exchange the app's signed in state stays consistent with the browser, which some people find easier to reason about.
Anyone running a single account can skip this condition entirely.
Condition 5: who fixes it afterwards
The last condition is maintenance, and it is the one most often skipped. Three moments arrive eventually: the service changes a URL, the name or icon needs adjusting, and the app needs removing.
For a Safari web app, opening the app and choosing Settings from the menu bar exposes Application Name, Application URL with a Set to Current Page button, and Icon. The same panel toggles the navigation controls and whether the title bar picks up the site colour, and a Privacy tab clears the app's cookies and cache. Deleting means dragging it out of the Applications folder in the home folder.
For a Chrome installed app, chrome://apps is the control panel. Right clicking an entry offers a desktop shortcut and an Open at login option. Uninstalling happens from the app window, with a checkbox deciding whether the stored site data goes with it. Chrome also raises a notice when an installed app changes its name or icon, offering to accept, ignore, or uninstall, which is the right place to look if a Dock icon starts resembling something else.
For anything distributed to a team, decide who holds this responsibility before handing it out. An app only its creator can repair becomes everyone's problem on the day the URL changes.
The four routes side by side
| Route | macOS floor | Install required | Account separation | Global hotkey |
|---|---|---|---|---|
| Official app | macOS 14 | Yes | Switch inside the app | Yes |
| Safari web app | macOS Sonoma 14 | No | Separate from Safari | No |
| Chrome installed app | macOS 13 | No | Per Chrome profile | No |
| Purpose built wrapper | Varies | Yes | Varies | Varies |
The fourth row covers a wide range of products, so it needs its own set of checks rather than a single verdict. Three questions cover most of it: how far back the macOS support goes, whether there is a cap on how many apps can be built, and whether the price is a one time purchase or a recurring charge. Those three are visible on a pricing page before anything is downloaded, and they determine the cost over three years far more than the headline number does. A fourth question is worth adding for anyone building more than one app: whether each app can be given its own storage, since that is what turns a set of wrappers into genuinely separate workspaces rather than four windows onto the same session.
Read it by deleting rows, not by scoring columns. Condition 1 removes rows, condition 2 removes more, and whatever survives gets ranked by conditions 3 through 5.
When Safari and Chrome are the two survivors, three tiebreakers cover nearly every case: which browser already holds the login, whether browser extensions need to stay available, and whether accounts need splitting. A Safari web app's toolbar carries buttons for installed Safari extensions, so extension users are not cut off. If none of the three separates them, build both and keep whichever one still gets opened after a week.
What to change first
Check the macOS version and who owns the machine before reading another comparison. If one route survives, build it today. Supported services shows the kinds of sites that get pulled out of the tab strip, Features covers what a built app can carry, and Kagemusha sets out the cost side for the fourth route once the first two conditions are settled.
Frequently asked questions
Which condition should be checked first?
The macOS version. The official app and Safari web apps both require macOS 14, while Chrome supports macOS 13 and later. That single fact removes options before any preference is involved, so checking About This Mac takes less time than reading a comparison table.
What is the safest route on a work issued Mac?
A browser based route, because nothing is installed and no system permission is requested. Features depending on Accessibility access are the ones most likely to be blocked by policy. Build what works without that permission first, and raise a request with the administrator only if something is genuinely missing.
How should two accounts be handled?
Safari web apps keep cookies and site data separate from Safari automatically, so two can run side by side. On the Chrome route, split the accounts across Chrome profiles first and install from each. In both cases, give each app a distinct name and icon so the wrong window does not get used by mistake.
What happens when the service changes its URL?
A Safari web app has an Application URL field in its settings, including a button that sets the app to the page currently open, so editing takes a few seconds. For a Chrome installed app, rebuilding is often faster than hunting for the setting. Either way, note where the setting lives before the situation arises.