Copilot+ PC apps on a Mac: what transfers and what cannot

Searching for a Copilot+ PC app and landing on a Mac produces the same result every time: no download button, no App Store listing, and a pile of articles written for people who already bought a different computer. The reason is simple once stated. Copilot+ PC is not the name of a program. It is the name of a hardware tier. Sorting the features by where the computation happens turns a confusing search into a short decision.

The name describes silicon, not software

Microsoft applies the Copilot+ PC label to Windows 11 machines that carry a neural processing unit capable of more than 40 trillion operations per second. The developer documentation states the threshold directly: many of the new Windows AI features require an NPU with the ability to run at 40+ TOPS. That number is a gate for which machines qualify, not a description of a program that can be installed.

Because the label describes a machine, there is nothing to download. A person looking for a Copilot+ PC app is usually looking for one of two different things that share part of a name. The first is the set of experiences that ship inside Windows on qualifying hardware. The second is the assistant reachable from any browser on any operating system, which appears in the same search results because the word overlaps.

Those two things have opposite answers on a Mac. One of them has no path onto the machine at all. The other is already available and has been for a while. Most of the frustration in this search comes from reading advice written about the first while needing the second.

How to tell which one is being described

A quick test works on almost any article. If the feature is described as working without an internet connection, it is running on the device and belongs to the hardware tier. If the description mentions signing in, a subscription, or a service, it is running somewhere else and the device is just the window onto it. Applying that test before reading further saves a lot of time.

Where the computation happens splits the feature list in two

Microsoft publishes which Copilot+ PC features need a connection and which do not. Recall in preview, Windows Studio Effects, Live Captions, and Super Resolution in Microsoft Photos run locally on the device. Cocreator in Paint, Generative Fill in Paint, Image Creator in Photos, and Restyle Image in Photos reach out to cloud services. Click to Do in preview mostly runs without a connection.

Feature group	Where it runs	Reachable from a Mac
Recall, Studio Effects, Live Captions, Super Resolution	On the device NPU	No
Cocreator, Generative Fill, Image Creator, Restyle Image	Cloud services	The underlying service is online
Chat, drafting, image generation	Cloud services	Yes, in a browser

The split is not arbitrary. Work that has to answer many times per second, such as blurring a background during a video call or captioning speech as it happens, cannot survive a round trip over a network. Work that can tolerate a few seconds, such as drafting a paragraph or generating an image, runs fine on a server far away.

That distinction is the useful one for anyone weighing a purchase. The on-device group is genuinely tied to the machine and cannot be reproduced by any software installed on a Mac. The cloud group is a service with an address, and an address can be opened from anywhere.

What actually arrives on a Mac, and in what shape

The cloud half arrives, but it arrives as a URL rather than as an icon. That difference sounds cosmetic and is not. A tab has no place in the Dock, does not appear in the application switcher, and disappears into a row of twenty other tabs within an hour of opening it. Closing it by accident means finding it again through history.

Half of what makes the Windows side feel like an application has nothing to do with the processor. It comes from having a window of its own, a name in the switcher, and notifications that arrive under that name instead of under the browser. None of that requires special hardware. It requires deciding that a particular site deserves to stop being a tab.

The other half, the part that runs on the device, does not transfer. It is worth being clear about this before spending an afternoon on setup. Turning a site into a standalone Mac app changes where it lives and how fast it can be reached. It does not add features that were never in the web version.

Counting before deciding on hardware

The decision about whether to buy a different machine comes down to how often the on-device features would actually get used, not how appealing they sound in a demo. Three numbers settle it.

• How many times in the past seven days a situation came up where one of those features would have applied
• Whether the same task could have been finished with a browser based service instead
• If not, how many minutes the workaround cost each time

Seven days is the right window. Estimating a month invites guessing, and guesses drift toward whatever the last article implied. Counting a week that actually happened produces a number worth acting on.

One more factor belongs in the count: how portable the habit is. A feature that only exists on one machine stops existing the moment work happens on a phone, a borrowed laptop, or a second desk. Features delivered as services follow the account rather than the hardware, which is why they survive a change of machine without any migration. For anyone who moves between devices during a normal week, that difference often outweighs raw speed.

Availability is also worth checking rather than assuming. Microsoft notes that Copilot+ PC experiences and their availability vary by device, region, and time, and that some features require installing an update before they appear. A machine bought today may not have the full set on the first day.

Three things that change how a site behaves once it has its own window

For the half that does transfer, how the window gets built determines how much maintenance it needs later. Three details matter more than the rest.

Sign in state comes first. A work account and a personal account sharing one browser profile will keep evicting each other. A window with its own profile keeps cookies and sessions separate, so both can stay signed in at once.

Extensions come second. Translation, password management, and content blocking are part of how most people actually read the web. A window built on a Chromium based browser keeps those working. A window built on a different foundation usually does not. The Features page lists what a window can be given, and the Guide covers the build itself.

Survival across browser updates comes third. Chrome ships a new version every few weeks. Some ways of creating a site window break on each update, losing the icon or refusing to launch, and have to be rebuilt by hand. A build that references the browser binary and re-syncs when it changes avoids that recurring chore.

Notifications are the fourth detail, and they surface later. A site running in a tab delivers alerts under the browser name, mixed in with every other site that has permission. The same site in its own window announces itself, which makes the notification centre readable and makes it possible to silence one service without silencing the rest. It also makes quitting a single distraction possible, instead of closing a browser that holds thirty other things.

A short audit worth running before building anything

Rather than deciding in the abstract which sites deserve a window, it is faster to look at what is already happening. The exercise takes about ten minutes and produces a list short enough to act on the same day.

Open the browser history for a single normal working day and sort by the sites visited most. The top of that list is rarely a surprise, but the order usually is. Sites that feel important often sit far below sites that get opened reflexively between other tasks. The reflexive ones are the candidates, because they are the ones paying a small cost many times over.

Then check each candidate against three questions. Does an official Mac application already exist for it, and does that application accept the account in use? Some publishers ship a Mac build but restrict it to personal accounts, leaving organisation accounts on the web. Does the site need to stay signed in as a different identity than the main browser profile? Does anything about the daily use depend on a browser extension?

A site with no official application, a second identity, and an extension dependency is the clearest case for a separate window. A site with a good official application that accepts the right account needs nothing built at all. Most lists come out with two or three in the first group, which is a manageable amount of setup rather than an afternoon project.

The order matters too. Building one window, using it for a week, and then adding more produces better decisions than building eight at once. A window that turns out to be unnecessary is easy to remove, but eight icons added in one sitting rarely get pruned afterwards.

Reading the preset list as evidence of what deserves a window

Tools that turn sites into Mac applications accumulate a useful signal: which services people actually bother to separate out. With 300 or more presets available to pick from, the pattern in the list is consistent. Communication, AI assistants, and work tools dominate, and what they have in common is frequency. They get opened many times a day for short visits rather than left running all afternoon.

The inverse is equally clear. An admin panel visited once a month, or a reference page reachable from search, gets worse when it becomes an icon, because every extra icon slows down finding the ones that matter. The Supported services list is worth scanning for that reason. Grouped by category, it makes the handful of genuine candidates easy to spot.

Cost structure deserves one look as well, since a one time purchase and a monthly subscription diverge sharply over three years, and how much is usable for free decides whether the idea can be tested at all. Both are on the Pricing page.

What to change first

Decide which half of the search actually applies. If the on device features are the goal, only different hardware provides them, and no amount of setup on a Mac substitutes. If the goal was the assistant itself, the missing piece is not processing power but a place to put the window, and the fix takes a few minutes with Kagemusha.