iHeartRadio for Mac: radio in a window instead of a tab

Live radio is the longest thing most people leave running on a computer. A station goes on at nine, it is still going at four, and the whole point is that attention is somewhere else the entire time. That is a strange job to hand to a browser tab, which is why the search for iHeartRadio for Mac tends to start right after a tab got closed by accident and a six hour stretch of background noise stopped mid-sentence.

Where iHeart publishes an application, and where it does not

iHeart maintains a page listing every platform it ships to, and it is unusually long. The App Stores block names the Amazon App Store, the Apple App Store, the Google Play Store, the Microsoft Windows App Store, the Samsung Galaxy Store and Chromebook. Below that come Epic Games, Xbox, seven television platforms, six speaker platforms, four voice assistants, nineteen car makers and two smartwatch platforms. There is also a single entry labelled Web, and its link points to iheart.com.

The Mac App Store is not on that page. Searching the Mac catalogue confirms it: no application published by iHeartMedia Management Services, Inc. appears there. The iOS listing tells the same story. iHeart: Radio, Music, Podcasts is free, sits in the Music category at 261.8 MB, lists in-app purchases, and its compatibility line reads "Requires iOS 15.0 or later." The devices named above the description are iPhone, iPad, Apple Watch and iMessage.

A Mac line is missing from that listing, and that is the deciding fact. When a developer allows an iPhone and iPad build to run on Apple silicon, Apple adds a Mac entry naming the minimum macOS version. iHeart has not enabled it, so the route that works for some other media apps is closed here.

The asymmetry with Windows is the part that confuses people. A Windows machine can install a real iHeart application from the Microsoft Store. A Mac cannot install anything, from any store. Forum answers written by Windows users are therefore accurate about their own machines and useless on a Mac, and they make up a large share of what this search returns.

What iHeart's own help centre treats as the computer

The Device Help section of iHeart's help site is organised by hardware, and the list of categories is short: iHeart.com, iHeart app on Mobile, Speakers, Wearables, iHeart in Cars, Casting and Android TV.

There is no desktop category. The computer appears as iHeart.com, which is to say as a website. That is not an omission to work around; it is the answer. On a Mac, iheart.com is the product, and every question about improving the experience is a question about improving the window that holds it.

What the site does well is the thing radio needs. Live stations, presets, the station dial, podcasts and playlists are all there, and signing in carries favourites across from the phone. The supported services list shows how many sites end up in this position, where the web version is complete and the only thing missing is a container that behaves like an application.

What the site cannot do is anything offline. Downloading episodes for a flight is an application feature on iHeart's mobile apps, and no amount of window management adds it to a web page. Anyone whose main use is offline podcast listening is looking at a phone or an iPad, not a Mac, and that is worth settling before spending time on the window.

Why a long listen and a browser tab work against each other

A browser is built for the opposite of radio. It expects many short-lived pages, competing for memory, with the foreground tab treated as the one that matters. Radio is one page, open for eight hours, that must never be the foreground tab because the user is doing something else.

Three specific frictions come out of that mismatch.

The tab is one keystroke from gone

Cmd+W closes the frontmost tab. On a strip of thirty tabs the frontmost tab is frequently not the one the hand intended, and a station that has been playing since morning is exactly as easy to close as a search result nobody wanted. There is no confirmation, because a browser has no way to know that one of those tabs was the point of the whole session.

Playback keys have to guess

When two tabs can both produce sound, the keyboard's play and pause keys become a coin flip, and so does the Now Playing control in the menu bar. A podcast paused in one tab and a station running in another will trade the controls back and forth depending on which page claimed them last. A window holding one site removes the ambiguity, because there is only one candidate.

Long-lived tabs are treated as expendable

Browsers reclaim resources from pages that have sat in the background for hours. Audio playback is usually protected from the worst of that, but a laptop that sleeps, a network that drops, or a browser process that has been running for three weeks all interrupt playback more often than a window pointed at a single site does. Fewer things share the window, so fewer things can disturb it.

Putting the player in its own window

macOS has a documented route that costs nothing, and Apple is precise about what it produces.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

The path in Safari is File then Add to Dock. Apple's article, which requires macOS Sonoma 14 or later, states that the result is saved to the Applications folder of the home folder, which means it turns up in Spotlight, keeps a fixed Dock position and answers to Cmd+Tab like anything else. The settings panel inside the window allows the name and the icon to be changed, allows the URL the window opens to be edited, and can hide the navigation controls so the window stops looking like a browser.

For radio, one of those settings matters more than the rest. Setting the Application URL to a specific station or podcast page rather than the iHeart home page means the window opens on the thing being listened to, not on a recommendations grid. Apple's documentation notes a Set to Current Page button for exactly this.

Apple also documents a Dock badge for unread notifications, which is useful for a site that announces live shows, and an Extensions tab where Safari extensions can be switched off for that one window. Turning off a content blocker for the listening window alone is often the difference between a player that starts and a player that sits on a spinner.

Where the built-in route stops is engine and session control. A Safari web app uses Safari's engine and its own storage, which is fine for one account. A site to app tool covers what is past that line: a window with a session entirely of its own, a second window for a second household account on the same host, and a choice about what the window is allowed to do while it sits in the background.

The first ten minutes of testing

Check three things before the browser tab gets closed for good. Whether the media keys reach the new window, since that is the clearest practical gain. Whether the stream survives the display going to sleep, which is a macOS energy setting rather than anything to do with iHeart. And whether the window keeps the sign-in after a restart, because a station list that resets to defaults every morning is worse than a tab.

Why the search results make this look unsettled

This query returns a particular mix of pages, and each one is answering a slightly different question.

Apple's own listing for the iOS app ranks high, which is reasonable, since it is the authoritative page. It is also the page that settles the matter, because the compatibility line names iOS and stops there. The Microsoft Store listing ranks too, and it describes a genuine desktop application, just not one that installs on a Mac. Third party software catalogues also rank, and their entries describe an iHeart desktop app in general terms because the catalogue itself supplies the window rather than iHeart.

None of those pages is wrong. They are simply about different platforms, and read together they produce the impression that a Mac application exists somewhere and is hard to find. It does not exist, and the check takes ten seconds: open the App Store listing and look for a Mac line under Compatibility.

One more source of confusion is worth naming. Emulator pages rank for almost every "app for Mac" search, offering to run the Android build inside a virtual machine. On a Mac that means installing a virtualisation layer to run a phone operating system in order to reach a service whose website already works in Safari. For a radio stream, the website is the lighter answer by a wide margin, and it is also the one iHeart's own help centre points to.

Comparing the three honest options

	Windows app	iheart.com in a tab	iheart.com in its own window
Available on a Mac	No	Yes	Yes
Survives Cmd+W by accident	Not applicable	No	Yes
Owns the media keys	Yes	Shared with other tabs	Yes
Dock icon and Cmd+Tab	Not applicable	No	Yes
Offline playback	App feature	No	No
Cost	Free	Free	Free with Safari

The column that does not exist is a Mac application, and no configuration creates one. What the third column does is close most of the gap between a tab and an application for the specific job of leaving audio running, which is what the original search was actually about.

Subscriptions sit outside all of this. iHeart's paid plans are account-level, so a plan bought on a phone applies to the website in a window, and nothing about the container changes what plays or how many skips are allowed.

Two accounts means two windows

Households frequently have two iHeart accounts, because presets and podcast positions are personal and sharing them makes both worse. A browser profile holds one signed-in session per site, so two accounts in one browser means signing out and back in, or keeping one in a private window that forgets the login on close.

Two windows, each with its own session store, keeps both accounts signed in at once with no switching. It is the same mechanism that makes a work login and a personal login coexist, applied to a station list, and the number of windows a setup allows is the thing to check first.

What to change first

Put the station or podcast page that actually gets played into its own window today, set its URL to that page rather than the iHeart home page, and leave the rest of the browser alone. If that window needs a session of its own or a different engine than Safari's, Kagemusha is one way to get it.