AMWin-RP: Discord Rich Presence for the Apple Music Windows app

A tray app that reads the Apple Music window through UI Automation

AMWin-RP exists because Apple ships no official bridge between its Windows player and Discord. The project describes itself as a Discord Rich Presence client for the native Windows Apple Music app, and it also scrobbles to Last.FM and ListenBrainz.

The interesting engineering is in how it gets the track information. The readme explains that song detection works through a UI Automation library used to scrape the Apple Music client app. That is a screen level approach: the application reads what the player is displaying rather than hooking into a documented media session API. The project ships a `TECHNICAL_DOCS.md` at the root of the repository, next to `AMWin-RichPresence.sln` and the `AMWin-RichPresence/` project directory, and the readme points to that file for the underlying detail.

The application is a single executable, `AMWin-RichPresence.sln` builds it in C#, and at runtime it stays in the background minimised to the system tray. Double clicking the tray icon opens the settings window, where individual options such as run on startup, scrobbling and song detection are adjusted, and the app is closed by right clicking the tray icon and choosing Exit. There is no service, no separate server and no browser extension in the design.

Choosing between the x64, ARM64 and NoRuntime packages

The release section is unusually explicit for a project of this size, which tells you the audience is ordinary users rather than developers. AMWin-RP requires Windows 11 24H2 or later. Builds are published on the releases page, and the first decision is architecture: pick x64 or ARM64 based on the processor in the machine, with x64 being the right choice for an Intel or AMD CPU.

The second decision is packaging. Two files are offered, the standard one and one marked `NoRuntime`. If you are unsure, the readme says to take the unlabelled release. That version bundles the .NET components the application needs, works universally, and is larger because of it. The `NoRuntime` package is much smaller but requires the .NET 10 desktop runtime to be installed, and if that runtime is missing the application will prompt you to install it when it opens.

So the real trade is size against friction. The self contained build is a larger download with no prerequisite. The `NoRuntime` build is small and needs a runtime that the operating system may or may not already have. For a machine that will be reinstalled often, or for a shared family PC, the bundled version removes a failure mode that shows up as a dialog on first launch.

The Microsoft Store build of Apple Music is not optional

The readme is direct about this: you need the Microsoft store version of Apple Music to use AMWin-RP. That single requirement shapes who the project works for, because the app is scraping the player window and a differently packaged Apple Music client may present a different UI tree for the automation library to read.

There is a second condition that is easy to misread. By default, the Apple Music app must be open and currently playing music, meaning not paused, in order for Rich Presence to show. So a paused player does not advertise a track, and neither does a closed one. If you want the presence to appear the moment you start listening, the default behaviour already does that; if you want a paused track to stay advertised, that is a setting rather than the default.

Discord has to be configured as well. The bug reporting checklist asks you to double check that Rich Presence display is enabled in Discord under Settings, Activity Settings, Activity Privacy and Activity Status. That step sits in the readme as a troubleshooting item, which tells you how often presence fails to appear for reasons that have nothing to do with the music.

Scrobbling runs to Last.FM and ListenBrainz, and offline plays are dropped

Scrobbling is a second feature rather than an afterthought, and it covers two services. For Last.FM you need your own API Key and API Secret, which the readme tells you to obtain from the Last.FM API page by selecting Get an API Account, then you enter the key, the secret, your Last.FM username and your password in the settings menu.

Password handling is done properly here. The Last.FM password is stored in Windows Credentials Manager under your local Windows account, rather than in the settings file or a plaintext config. ListenBrainz is simpler, since it only needs a user token added in the settings.

The limitation is stated without hedging. The scrobbler implementation does not support offline scrobbles, which means any song you listen to while not connected to the internet will be lost. This is not a deferred feature with a workaround, it is a defined boundary of the implementation, and it is worth weighing before you treat the scrobbler as a complete listening history. A flight, a basement with no signal, or a laptop that sleeps on a train will each silently drop plays.

The README is also translated into Korean, Japanese, Russian, Latin American Spanish, European Spanish and German, which is a reasonable proxy for who the project is written for.

Logs live under %localappdata%\AMWin-RichPresence

Before opening an issue, the readme asks two things of you. First, check that the problem is not already covered by an existing issue, open or closed. Second, attach the relevant `.log` files, which it locates at `%localappdata%\AMWin-RichPresence`.

That is the whole debugging surface. The application writes logs into a folder under the local application data directory, keyed by the application name, and a bug report is expected to carry them. For a project that scrapes another application's UI, logs are the only way to tell whether a track was not detected because the player was in a different state, because the automation tree changed, or because Discord refused the presence update.

The repository structure is small and conventional: `AMWin-RichPresence.sln` at the top, the `AMWin-RichPresence/` project directory holding the code, `BuildReleases.ps1` for the PowerShell based release build, the `LICENSE` file, the translated readmes and `TECHNICAL_DOCS.md`. The presence of a dedicated technical document alongside a short readme is a good sign for anyone who needs to know how the scraping works in detail.

Virtual desktops and pausing are where the approach breaks

Two failure modes deserve attention because they are structural rather than bugs.

The first is virtual desktops. The readme notes that if you use virtual desktops, AMWin-RP and Apple Music must be in the same desktop, and it attributes this to a technical limitation of the UI Automation library used to scrape the Apple Music client app. So on a machine where people keep a separate virtual desktop for music or for work, the presence simply stops appearing, and moving the player to another desktop is the fix. This is a constraint that comes from the choice to read the UI rather than from a policy decision.

The second is the paused player requirement described earlier. Presence reflects a playing track, not a loaded one.

Taken together with the offline scrobble gap and the Windows 11 24H2 floor, the picture is of a tool that works well in one configuration: a single physical Windows 11 desktop, Apple Music from the Microsoft Store installed and visible, Discord configured to display activity, and a network connection when you want your plays recorded. Every deviation from that setup is a case where this project is the wrong tool, and the readme is honest about the first two.

The licensing is GPL-3.0 with the full text in the `LICENSE` file at the repository root. That matters for anyone thinking about bundling or redistributing the code rather than just running it.

How a native player client differs from a browser based scrobbler

The usual alternative for listening history is a browser based scrobbler or a media session bridge that listens to whatever the operating system reports. The difference in approach here is where the track data comes from. A browser based tool or a media session integration reads an event stream that the player publishes, which works across many applications and survives the player being a different program. AMWin-RP reads the Apple Music window directly through UI Automation.

The upside of reading the window is coverage of information a media session does not necessarily carry, and the ability to work with a player that exposes little through session APIs. The downside is that the method depends on the target application rendering the expected elements, which is why the same readme has to tell you which build of Apple Music to install and why the UI must be on the same virtual desktop.

For the Discord side of things the distinction matters less, because Rich Presence is fed by the application either way, and Discord presence needs the game or application id, the timestamps and the artwork. The Rich Presence part of this project is ordinary integration work. The unusual part, and the part that determines whether the tool works for you, is the scraping layer underneath it.

Editorial conclusion

AMWin-RP is the right tool for a Windows user on the Microsoft Store build of Apple Music who wants Discord to show the current track and wants their listening history recorded, and it is the wrong tool for anyone on a virtual desktop setup, on a non Microsoft Store build of Apple Music, or on a platform other than Windows. Before installing, check that your Apple Music build comes from the Microsoft Store, decide between the self contained and NoRuntime packages, and remember that a lost network connection drops the scrobble permanently because offline scrobbles are not supported.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. PKBeam/AMWin-RP on GitHub
4. README
5. Releases