A Crunchyroll app for Mac: episodes in a window of their own

Looking for a Crunchyroll app for Mac is almost never about features. The web player works, the catalogue is the same one, and the picture is fine. The irritation is structural. An episode sits in a browser tab next to twenty work tabs, quitting the browser at the end of a working day stops playback, and closing a window that happened to contain the episode ends it without warning. A twenty four minute activity is living inside a container designed for two minute activities. That gap can be closed, but only after it is clear what is on offer and what is not.

What the App Store listing covers, and where it stops

The App Store page is the fastest way to settle whether an official Mac build exists. The app is published by Crunchyroll, LLC, it is a 253.8 MB download in the Entertainment category, and the compatibility section names iPhone requiring iOS 17.0 or later, iPad requiring iPadOS 17.0 or later, Apple TV requiring tvOS 17.0 or later, and Apple Vision requiring visionOS 2.2 or later.

Read that list for what is absent. There is no Mac entry. On Apple silicon, an iPhone or iPad app can be offered on the desktop when the developer permits it, and the listing then says so by naming macOS and an Apple M1 chip or later in the same compatibility block. This listing does not. The route of installing the iPad build on a MacBook is therefore closed, and it is closed by a publisher decision rather than by a hardware limit.

The tvOS line explains the thinking. Crunchyroll treats the television as the primary screen and the phone as the second. A laptop is neither, and the assumption is that a laptop already has a capable video player built into its browser. That assumption is defensible. It is also the entire source of the friction.

Two other approaches sometimes get suggested and are worth naming honestly. An Android emulator will run the Android build on a Mac, at the cost of running an entire second operating system to watch television, with the video decode path going through several layers that were not designed for protected streams. Screen mirroring from an iPad or iPhone puts the picture on the Mac without putting an application on it, which helps with a one off and not with a daily habit.

Watching on a Mac means watching in a browser

The web player at crunchyroll.com is the desktop product, and that is the whole of it. It streams, it holds the same library, and it remembers where an episode stopped because that position is stored against the account rather than the window.

Region matters more here than with most services. Requesting the site from a territory Crunchyroll does not operate in returns a page stating that it is not currently available in that location, and a desktop window makes exactly the same request from exactly the same connection. Wrapping the site changes the container and not the network path, so a window helps with tab management and does nothing about availability.

The in-app purchase list on the App Store page gives a sense of the tiers: Fan at $9.99, Mega Fan at $13.99 monthly or $139.99 annually, and Ultimate Fan at $17.99, alongside several bundle and regional entries. A subscription bought inside the App Store build is managed by Apple, and one bought on the website is managed there. Anyone planning to watch mainly on a Mac is better served buying on the website, because the subscription then lives in the same place it is used.

What a browser tab does badly to a long episode

A browser tab is the most fragile container a long form video can occupy, and the failures are predictable rather than mysterious.

Quitting the browser stops playback. Most people quit the browser at the end of a work session without thinking about it, and if the episode is inside that browser it ends with everything else. Closing a window with several tabs in it does the same thing more quietly, because the tab holding the episode is not the tab in front.

Switching to it is slow. Cmd+Tab lands on a browser, not on the episode, and the remaining step is identifying the right tab among many by a favicon a few pixels across. For something opened once an evening this is tolerable. For something opened several times it is not.

Coming back is worse. A window reopened returns to the address it was built from. A tab reopened returns to a new tab page, and the path back to the series is a search box and two or three clicks.

There is also a performance effect that gets misattributed. A browser holding a live video stream alongside a dozen other live pages is doing a great deal of work, and the machine gets warm and the fan comes on. The obvious conclusion is that the video is heavy. The accurate conclusion is that the browser is busy. Leaving only the viewing window running and quitting everything else is the simplest fix available, and it is impossible while the episode lives inside the browser being quit.

Two ways to build the window

Route	What it needs	Extensions	Separate login	Protected video
Safari, Add to Dock	macOS Sonoma 14 or later	Not supported	Yes, separate from Safari	Handled by WebKit
Chromium based window	Chrome, Brave, Edge, Vivaldi or similar installed	Chrome Web Store extensions work	Yes, its own profile	Handled by Widevine in the browser engine

Safari's route is the shortest. Open crunchyroll.com in Safari, click the share control in the toolbar, choose Add to Dock, then click Add. Apple documents the result plainly: an icon for the web app is added to the Dock and to Spotlight Applications, the window carries a simplified toolbar, and notifications arrive the way they do from any app. A site that was already signed in usually stays signed in inside the new web app, with the same user name and password.

The part that matters for a streaming account is the settings panel that web app then owns. Opening it, clicking its name in the menu bar, choosing Settings and then Privacy gives controls for camera and microphone access, screen access, location, and clearing website data for that web app alone. The data boundary is drawn per app rather than per browser.

The Chromium route uses a real browser engine underneath and adds two things Safari's version cannot offer. Chrome Web Store extensions run inside the window, and each window gets a browser profile of its own, which keeps a personal streaming account entirely separate from a work Google session. What each approach supports is set out on the Features page.

For video specifically, the engine choice is the thing to test rather than reason about. Protected streams either play or show a blank player, and there is no partial state. Playing one episode for thirty seconds in a newly built window settles it immediately, and it is the single test worth doing before setting anything else up.

Setting the window up so it stays useful

A viewing window benefits from a handful of deliberate choices that a tab cannot have.

Build it from a useful address. A window built from the account's watchlist or history page opens onto the next thing to watch rather than a promotional home page. The address the window is created from is the address it returns to every time.

Fix its place on screen. Right clicking the Dock icon, opening Options, and choosing This Desktop makes the window open on a chosen space. Putting the viewing window on one space and the working browser on another turns Control and an arrow key into a single gesture for moving between watching and working.

Decide about full screen before using it. Full screen on a Mac creates its own space, which is good for focus and means the way back is Control and an arrow key or a four finger swipe. A window kept at a quarter of the screen in a corner suits watching while doing something else. Both work, and mixing them by accident is what makes a setup feel unpredictable.

Handle popups deliberately. Some players open in a separate popup window, and a container that blocks every popup will show a play button that appears to do nothing. A tool that turns a website into a standalone Mac app usually offers a middle setting that allows authentication and player windows while blocking advertising ones, and that setting is the right default for a streaming window.

Turn notifications down. A window built as an application appears in System Settings under its own name rather than as a URL, so notifications can be silenced for the viewing window alone without touching the browser. Anyone building several windows like this will find the services commonly handled this way on the Supported services page.

Households, second accounts, and keeping them apart

Two situations make the case for separate windows stronger than tab management alone.

The first is a household with more than one viewer on the same Mac. In a browser, two accounts mean signing out and signing back in, or running one of them in a private window that forgets the watch history every time. Neither survives contact with daily use. Two windows, each with its own browser profile, hold two sessions at once, and each keeps its own watch history and its own resume positions without either one touching the other.

The second is the separation between a personal streaming account and a work browser. A streaming service signed in inside the everyday browser profile shares that origin with every extension and every other site open in it. Moving it into a window of its own narrows that surface considerably, and it also stops a streaming account from appearing in an account picker during a screen share.

Both of these are profile problems rather than window problems, which is why the choice of container matters. Safari's Add to Dock keeps site data apart from Safari itself, which covers the first half of the problem. A Chromium based window assigns a separate profile per window, which covers both halves, and it is the reason people running more than one account tend to end up there. The FAQ page sets out how profiles and logins are handled in that arrangement.

What breaks later, and how to keep it working

One failure mode is worth knowing in advance because it catches people weeks after setup. Chromium based browsers update every few weeks, and a window that was built by copying a browser binary or pointing at a version specific path can lose its icon or stop launching when that happens. Windows built to follow the browser rather than a fixed copy keep working through updates, which is the difference between a setup that lasts and one that needs rebuilding every month.

The second is the login. A viewing window that asks for a password every evening will be abandoned within a week. Build it, sign in, quit it completely, open it again, and confirm the account is still there. If it is not, the container is discarding cookies and the setup needs a different route rather than more patience.

The third is resume position. Quit the window mid episode, open it again, and check that the service offers to continue rather than starting from the beginning. That behaviour comes from the account rather than the container, so it should survive, and confirming it once removes the doubt.

What to change first

Open crunchyroll.com in Safari, click the share control in the toolbar, choose Add to Dock, and play one episode in the result, checking full screen and whether the login survives a quit. If extensions or a login kept separate from the everyday browser matter, or several sites are going to be handled the same way, a purpose built window from Kagemusha is the version worth keeping.