# LyricFever puts timed lyrics over Spotify and Apple Music on macOS > LyricFever is a SwiftUI menubar app for macOS that follows playback in Spotify or Apple Music and shows synchronised lyrics, with karaoke mode, fullscreen view, translation through Apple's on-device API and offline caching in CoreData. It also relies on private Apple Music APIs, which is the sharpest edge in an otherwise self-contained design. **aviwad/LyricFever** — Best Spotify & Apple Music Lyrics experience for macOS (spiritual successor to LyricsX) - Repository: https://github.com/aviwad/LyricFever - Website: https://lyricfever.com - Stars: 639 · Forks: 36 - Language: Swift - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/aviwad-lyricfever ## A menubar app that watches what the player is playing LyricFever is a macOS app that shows lyrics for whatever Spotify or Apple Music is playing, and it is described as the best lyrics experience for Spotify and Apple Music on macOS. It is also described as a spiritual successor to LyricsX, which explains a lot about the design: this is a menubar app, not a music player, and the whole point is that you keep using Spotify or Apple Music as your player and the lyrics appear on top. The feature list describes what that means in practice. There is automatic lyric playback in the menubar. There is a fullscreen mode modelled after the Apple Music fullscreen view, and a karaoke mode where the lyric popup stays on screen. Karaoke mode can be customised, including font colour. There is lyric translation using Apple's on-device APIs, and offline caching, with lyrics stored offline using CoreData so they do not need to be fetched again. The interaction is deliberately passive. You play music in the Spotify or Apple Music app and the lyrics play on the menubar automatically. Nothing about the playback flow changes, which is why the app works as an enhancement rather than as a replacement player. The requirements are short and worth checking before anything else: macOS Sequoia or higher, and the Spotify Desktop Client if you use Spotify. There is no mention of an Apple Music desktop requirement, since Apple Music is a system app on macOS. The interface language includes Simplified Chinese, contributed separately from the core work, and the README points to a Crowdin project for translations, with a request to open an issue if you want another language. ## How it learns the current track without controlling the player The technical section is where the interesting engineering is, and it is honest about which parts are private. The UI is built with SwiftUI. Lyrics are updated and fetched using Swift Concurrency and Swift Tasks, and stored to disk with CoreData. The app interfaces with Spotify and Apple Music through their AppleScript methods and also by subscribing to their playback state change notifications, using Apple's ScriptingBridge interface for the AppleScript side. Then the part worth knowing before you install it. The README states that private APIs are used to get the currently playing Apple Music song's iTunes ID, and that MusicKit maps that to an ISRC code. Apple Music songs are then mapped to an equivalent Spotify ID using the ISRC, which is how lyrics fetched from Spotify can be displayed for either platform. The strategy is sensible: Spotify is the primary lyric source, and ISRC is the join key that lets a song playing in Apple Music find its Spotify lyrics. Private API use is the risk. It is undocumented, it can change in any macOS or MusicKit update, and a user cannot expect a stable contract. The README's own comparison of LyricsX suggests the author expects this project to continue evolving against those changes, and the release history shows an emergency update for version 3.2 in October 2025 followed by 3.3 in November 2025, which is what a project living on private APIs looks like in practice. ## Three lyric sources and a fallback chain Lyrics are fetched from Spotify, LRCLIB and NetEase, and the README describes the order of preference. Spotify is the primary source, LRCLIB is the backup when Spotify fails, and NetEase is used when both LRCLIB and Spotify fail. The acknowledgements section confirms the chain, crediting the LRCLIB project as an open source lyric library used when Spotify fails, and NetEase for lyrics used when LRCLIB and Spotify fail, along with a hosted NetEase API deployment and a StringMetric helper used to determine how similar NetEase search results are from the search query. That similarity measure matters more than it sounds. NetEase is a search-based source, so a query for a song title can return several candidate entries, and the app has to decide which one is the right track. The credit list shows the app also borrows a Chinese conversion class from LyricsX for character conversion, and a Japanese romanization library, Mecab-Swift, for romanizing Japanese lyrics. The practical consequence for a user is that lyric quality and availability depend on which source answers. A song that Spotify does not have lyrics for may be served by an open database or by a search endpoint, and the quality of the result, including its timing and its translation, is uneven across those sources. A third-party lyric source is also a third party that can disappear. Two smaller features round this out. The app fetches a background color with each lyric and uses it for the karaoke mode window background, and the fullscreen view uses a custom mesh gradient with colors extracted from the album art through ColorKit, which the author ported to macOS. ## Installing on macOS Sequoia or later There are two documented installation routes, and the Homebrew one is the one to prefer for anything but a quick look. The manual route is a DMG file, linked from the releases section of the repository: ```text Download the DMG file [here](https://github.com/aviwad/LyricFever/releases/download/v2.1/Lyric.Fever.2.1.dmg). ``` The Homebrew route is a single command, run in a terminal: brew install lyric-fever. Note the hyphenated formula name, which differs from the app name, and note a wrinkle in the README: the manual download link points at a version 2.1 DMG even though the release list shows version 3.3 as the most recent tagged release, dated 2025-11-28, with a 3.3 beta before it and a 3.2 emergency update before that. If you install the DMG by hand, check which version you actually get. The application update mechanism is Sparkle, with the appcast.xml file at the repository root, so once the app is installed it can update itself, and the README credits the Sparkle project for app updates. Permissions are the other part of a first run, and the repository carries a file named newPermissionMac.gif, which suggests the app prompts for new macOS permissions during setup. Since the app automates Spotify and Apple Music through AppleScript and ScriptingBridge, it will need automation permission for those applications, and the fullscreen view and menubar presentation also depend on macOS APIs that can prompt for access. The user interface itself is a menubar extra, so it lives in the menu bar rather than in a window, with a floating lyric window for the karaoke display. ## Where this app is the wrong tool There are clear limits, and they come from the dependencies rather than from the app itself. The first is platform. This is a macOS application, not a cross-platform one, and it needs Sequoia or later. There is no iOS or Android version mentioned anywhere in the README, and the repository has no mobile target, so a phone user gets nothing here. There is a Lyric-Fever-on-TV-Info.plist at the repository root, which suggests some television support, but the README does not describe it, so treat it as undocumented. The second is the requirement for the Spotify desktop client when using Spotify. If you play music in the Spotify mobile app or the web player, there is no local playback state for LyricFever to observe. The third is the private API dependency, already mentioned, which means breakage is a matter of time rather than if. The version history supports that reading: a 3.2 emergency update and a 3.3 release labelled as visual fixes and more, both within two months of each other. The fourth is the lyrics themselves. Whatever the source, the timing and the words are third-party data, and a karaoke display that highlights the wrong line is worse than no display at all. The project's own comparison with LyricsX on efficiency, 0.1 percent CPU usage against 3 percent, is a fair claim to hold it to, and it also underlines that the app is intended to sit in the background of a music session rather than to be a feature you configure carefully. ## LyricFever against LyricsX The project positions itself explicitly as the successor to LyricsX, and the README is not shy about the comparison, claiming 95 percent more efficiency with 0.1 percent CPU usage against LyricsX's 3 percent, and stating that a technical write-up is coming soon. The architectural difference that matters to a user is where the app sits relative to the player. LyricsX was a menu bar application for Spotify on macOS, driven by AppleScript against the Spotify client, and it was abandoned when Spotify's macOS client changed in a way that broke those scripts. LyricFever is built for the current generation of both players, uses playback state change notifications alongside AppleScript, and reaches into Apple Music with MusicKit and ISRC matching so that a single lyric pipeline serves both services. The other difference is that LyricFever is not tied to a single provider. With LRCLIB and NetEase as fallbacks and Apple's translation API for non-English lyrics, it covers more songs than a Spotify-only approach can, and the offline cache means the second listen of a song does not need the network. The comparison has a limit worth stating. The efficiency figure is the author's own, taken on unspecified hardware, and it is a CPU usage comparison, not a feature comparison. What matters more to an adopter is that LyricFever's approach depends on private APIs, so its longevity is a function of Apple's cooperation rather than of the code quality. A lyric app lives and dies by that kind of external contract, and LyricFever's answer is to support two players and keep a fallback lyric source, which reduces but does not remove the exposure. ## Conclusion Adopt LyricFever if you listen to Spotify or Apple Music on macOS Sequoia or later and want synchronised lyrics without leaving the player, and if you are comfortable granting the app automation permissions and accepting that it calls private Apple Music APIs that can break when Apple changes them. Do not adopt it for a setup without the Spotify desktop client, since the README lists that as a requirement when using Spotify, and do not treat the lyrics as authoritative, since they come from Spotify first and then from two fallback providers of varying provenance. Verify first that your macOS version meets the Sequoia floor, that the Homebrew formula installs the release you expect, since the manual DMG link in the README still points at version 2.1 while the newest release listed is 3.3, and that the app can reach each of the lyric sources on your network before you rely on it during a listen. ## FAQ ### How do I install LyricFever on macOS? The README gives two routes: a DMG download from the repository releases, or a Homebrew install with brew install lyric-fever. The app requires macOS Sequoia or higher, and the Spotify Desktop Client if you use Spotify. ### Where does LyricFever get its lyrics from? Lyrics are fetched from Spotify first, with LRCLIB as a backup when Spotify fails and NetEase used when both LRCLIB and Spotify fail. Lyrics are cached offline using CoreData, and non-English lyrics can be translated using Apple's Translation API. ### Does LyricFever work with Apple Music as well as Spotify? Yes. The app reads the current Apple Music track through private APIs to get its iTunes ID, maps that to an ISRC with MusicKit, and uses the ISRC to find the equivalent Spotify ID so Spotify lyrics can be shown for either player. ### What is the difference between LyricFever and LyricsX? LyricFever is described as a spiritual successor to LyricsX. The README claims 95 percent more efficiency, with 0.1 percent CPU usage against LyricsX's 3 percent, and LyricFever supports both Spotify and Apple Music with fallback lyric sources and offline caching. ### Can LyricFever show lyrics for songs playing in the Spotify mobile app? No. The app observes local playback state from the macOS clients, and the README lists the Spotify Desktop Client as a requirement when using Spotify. Lyrics shown by LyricFever come from the desktop player session, not a remote device. ## Sources - [aviwad/LyricFever on GitHub](https://github.com/aviwad/LyricFever) - [License: MIT](https://github.com/aviwad/LyricFever/blob/main/LICENSE) - [Project website](https://lyricfever.com) - [README](https://github.com/aviwad/LyricFever/blob/main/README.md) - [Releases](https://github.com/aviwad/LyricFever/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aviwad-lyricfever