OpenSpot Music: an MIT-licensed music player built on Expo and Electron
OpenSpot is a free, open-source music app that lets you stream and download high-quality tracks across all your devices. With a sleek, intuitive UI built for a seamless experience, it supports Android, iOS, macOS, Windows, and Linux — so you can enjoy your favorite music anywhere, online or offline.
At a glance
- What is it?
- A single TypeScript project ships Android, iOS, macOS, Windows and Linux builds that stream, download and play music with no account. The code is open, the catalogue is not, and that split decides who should install it.
- Who is it for?
- OpenSpot is worth installing if you want a music player with no account, no adverts and offline downloads, and you are comfortable that the audio arrives through third-party services rather than a licensed catalogue of your own. The MIT licence covers the application code only, so anyone planning to fork it should look first at how streaming is wired.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 70 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 8, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One project, two build systems, five platforms
The repository is small at the top level and the names do most of the work. `openspot-mobile/` holds the phone and tablet app, `openspot-desktop/` holds the Electron build, and `apps.json` sits between them as the single file that tells an updater which binaries exist. Alongside those sit `IOS_INSTALLATION.md`, `CHANGELOG.md` and `ROADMAP.md`, which is a better documentation footprint than most hobby music apps manage.
The platform story is unusually wide for a project at this stage. The README's download block lists Android, iOS, macOS, Windows and Linux, and v3.1.5 is the version pinned there. Both a mobile and a desktop tree means the same feature set has to survive two very different runtimes: Expo and React Native on one side, Electron and Node on the other. Where the two diverge, the release notes are the place to look, because a feature described as added usually means added on both and the odd platform-specific caveat only turns up later.
The repository's own topics confirm the stack: expo, react-native, electron-app and nextjs appear alongside android, ios, linux, macos and windows. TypeScript is the primary language. This is a frontend project in the plain sense of the term. Most of what makes the app work is the APIs it calls rather than the logic it runs on the device.
Where the audio and the metadata actually come from
This is the question that decides how you feel about the project, and the README answers it across two different feature lists. Streaming reliability is attributed to an improved YouTube API, and trending tracks are described as coming from Spotify and made region-aware using IPinfo. Playlist import is described as taking any public Spotify playlist URL.
So the catalogue is assembled from other services rather than licensed from a label. Spotify supplies the browse and playlist structure, YouTube supplies the playable audio, and IPinfo supplies the country that decides which trending list you get. The v3.1.5 notes describe adding trending support in more than 75 countries and fixing cases where playlists, albums or songs came back empty in certain regions, which is what you would expect from a system that depends on region-specific responses from two outside APIs.
That architecture has a practical advantage. There is no subscription to cancel and no account to create, and the README is explicit that no login is required. It also has an obvious fragility. When an outside provider changes its client behaviour or blocks a region, the app loses features without any code changing on your side, which is the same class of problem that makes unofficial front ends age badly.
Downloads, offline mode and the v3.1.x correction arc
The release history tells you more about this project than the feature list does. Three tagged releases sit in a little over two months: v3.1.3 on 2026-04-30, v3.1.4 on 2026-05-05, and v3.1.5 on 2026-06-02. v3.1.3 is described as a hotfix pushed out as a force update after a backend and API error in the previous build. Offline mode landed in v3.1.0 alongside an optimised player and a region toggle for trending.
Offline listening then took two more releases to settle. v3.1.5 lists interrupted background downloads and a set of offline mode problems as fixed, which means offline was shipped in v3.1.0 before it was dependable. If you are evaluating the project today rather than reading the announcement post, that arc is the relevant fact: the current build has the fixes, the feature is not new.
v3.1.5 also adds direct import from a public Spotify playlist URL and full discography browsing for artists. Likes, custom playlists, shuffle, background playback and a capsule mini player on compatible hardware are all listed in the README's feature blocks. Ten interface languages ship in the app, with more offered as contributions.
The macOS step that every release note repeats
Three separate macOS users hit the same wall after installing, and the project answers it the same way every time. macOS Gatekeeper quarantines the downloaded application, so the app will not open until the quarantine attribute is cleared. The release notes give one command for this: `xattr -rd com.apple.quarantine /Applications/OpenSpot.app`, run after you move the app into Applications. It appears in both the v3.1.5 and v3.1.4 notes, which tells you this is a recurring step rather than a one-off report.
That command is a diagnostic worth taking seriously rather than a routine step. Unsigned macOS applications outside the App Store routinely trigger Gatekeeper, and clearing quarantine on an unfamiliar binary means trusting the source before you run it. The download link on the README is a GitHub Pages site at blackhatdevx.github.io rather than the releases page, and the MIT licence tells you nothing about who compiled the binary you downloaded. The read-only verification available to you is the MIT-licensed repository itself and the published `CHANGELOG.md`, which is the file to read before installing anything from that site.
What the public tree shows and what it withholds
The top-level listing has nine entries and no application source directory beyond the two build trees. There is no `package.json` at the root, no lockfile, no test directory and no CI configuration under `.github/`. A project with this much user-facing surface, five shipped platforms and a force-update mechanism has more code than that listing suggests, which is the honest reading: the published repository is a wrapper around something larger.
What is visible is useful in a narrower way. `apps.json` is the updater's manifest, so it is where you would look to understand how a build is distributed and whether a version has been pulled. `IOS_INSTALLATION.md` exists because iOS distribution has no equivalent of the macOS download, so the steps for getting a build onto an iPhone are documented separately. `ROADMAP.md` is where the maintainer states intent.
The last push to the repository was on 2026-08-03 and it is not archived, so the published tree reflects a project that was still being touched at that date. Whether a given platform build is current is a separate question, and the release tag is the better signal for that.
How it sits against the usual free-player options
The obvious comparison is not another free player but Spotify itself, since the app is built to consume Spotify's playlist and trending data while replacing the playback surface. What you give up is the licensed catalogue, the absence of regional blank spots, and an account that carries your library between devices. What you get back is no login, no adverts and files you own on disk.
Against purpose-built Android players, the difference is cross-platform reach. Building for iOS, macOS, Windows and Linux from one TypeScript codebase is not something the typical Android-first player attempts, and if you switch between a Mac and an Android phone, having one interface on both is a genuine gain.
There is also a class of projects that streams from YouTube and does nothing else. Those are usually a thin wrapper with no download manager and no offline mode to speak of. OpenSpot's downloads, background playback and library management put it closer to a real player. The cost of that ambition is the dependency described earlier: the catalogue belongs to somebody else and can change under you.
Editorial conclusion
OpenSpot is worth installing if you want a music player with no account, no adverts and offline downloads, and you are comfortable that the audio arrives through third-party services rather than a licensed catalogue of your own. The MIT licence covers the application code only, so anyone planning to fork it should look first at how streaming is wired. Start at the GitHub Pages download page for v3.1.5, run the quarantine command the release notes give you on macOS, and treat the repository's own CHANGELOG.md as the real source of what changed, since the published tree exposes only apps.json and two build directories.
Frequently asked questions
What is replacing Spotify?
OpenSpot positions itself as the replacement rather than the replaced. It imports any public Spotify playlist URL, reads trending lists from Spotify for more than 75 countries, and serves the audio through a separate streaming path, so you keep Spotify's playlist structure without a Spotify account.
Is OpenSpot Music really free and does it need an account?
The README states no login is required and describes the app as free and ad-free, with no in-app purchase mentioned. Music is still sourced from outside services, so what is free is the application, not a licensed catalogue.
Why does the macOS app refuse to open after I install it?
Gatekeeper quarantines the downloaded bundle. The release notes tell macOS users to run `xattr -rd com.apple.quarantine /Applications/OpenSpot.app` after installation, which clears the flag so the app can launch.
Does OpenSpot work offline?
Offline mode shipped in v3.1.0 with search and filter over downloaded tracks, and the v3.1.5 notes list fixes for interrupted background downloads and further offline problems. The current build is the one with those corrections.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/blackhatdevx-openspot-music-app)