Music Assistant Mobile: the official Android and iOS client for a self-hosted music server

What Music Assistant Mobile solves, and for whom

Music Assistant Server aggregates music providers and players on your own hardware. What it does not ship is a first-party phone client. This repository is that client: an Android and iOS app that talks to a Music Assistant server, controls its players, and can also play audio on the phone itself from the server library.

The audience is narrow and specific. You need a running Music Assistant server, and you need to be comfortable with sideloading on Android or joining a TestFlight beta on iOS. The README is blunt about the state of things: the project is "still under (heavy) development and not yet in a production state or published to any of the app stores." That sentence sets the expectations for everything else on this page.

Feature scope is deliberately uneven across platforms. Android requires 8.0 or later and gets a media service for background playback, a system media notification, and Android Auto plus Google Assistant and Gemini App Actions voice phrases. iOS requires 18.5 or later and gets native playback through AudioQueue (CoreAudio) with FLAC, Opus and PCM support, Lock Screen and Control Center integration, background audio with automatic resume after a phone call or Siri interruption, a WebRTC data channel for Sendspin streaming, and CarPlay in what the README calls a very early state where "a lot of bugs are expected."

How the client, the server and Sendspin fit together

The architecture is a thin client over a server that holds the library. The app manages the queues and playback of Music Assistant players, handles dynamic and static groups (static group creation is explicitly out of scope), and browses the library and providers. Playback of an external player happens on that player, not in the app.

Local playback is the interesting part. The app streams from the Music Assistant library to the device using Sendspin, the streaming protocol named in the README, carried over WebRTC or WebSocket. On iOS the README notes a WebRTC data channel transport for low-latency Sendspin streaming. So there are two transports for the same protocol, and the choice matters for latency rather than for feature availability.

The design goals explain why the UI is shaped the way it is. The README lists actions that should be reachable "in pretty much any state" when the app opens: see what is playing, change player, play/pause, transfer playback, group with another player, global search, home, next track, browse library, settings. Two stated directions follow from that: optimize for searching, filtering and drilling down rather than navigating long lists, and keep customization settings near what they affect instead of in one global settings screen. That second choice will annoy anyone who expects a single place to configure everything, and it is intentional.

In-car support is a stated core focus, and the README draws a hard line around it: CarPlay and Android Auto are "dedicated exclusively to the local player; managing external players is out of scope."

Installing the APK or joining TestFlight

There is no store listing yet, so installation is manual on both platforms. The README points Android users at the APK attached to the latest release on the GitHub releases page, and iOS users at a TestFlight invite link.

For Android, download the APK from the releases page and install it. Because it is a sideloaded build, Android Auto needs an extra step; the README defers the details to docs/ANDROID-AUTO.md, which covers "enabling Android Auto with sideloaded debug/self-signed builds (Unknown sources flow)."

A build from source is a Gradle build, since the repository root holds gradlew, gradlew.bat, settings.gradle.kts and build.gradle.kts, with androidApp/, composeApp/, iosApp/ and shared-icons/ as the module directories. The README does not give a build command, and no other repository file here specifies one, so the exact Gradle invocation is not documented.

Once installed, the first real task is connecting the app to your server and signing in. The README describes a Settings screen with sections for server connection, authentication (builtin or OAuth) and local player configuration. After that, the app is usable against your existing players: pick one, control its queue, and optionally switch to the built-in local player for on-device playback. For the full walkthrough the README points at docs/app-documentation/index.md rather than repeating the steps. The README does not document a rollback path for the mobile app, so if a build misbehaves you are reinstalling an older APK or leaving the TestFlight beta.

Where Music Assistant Mobile is the wrong tool

The README carries a disclaimer that decides a lot of adoption questions: "This app is not intended to provide offline playback." If your use case is a phone with music on a plane or in a tunnel, this is not the client for it, and no setting changes that.

Server version coupling is the second constraint. Releases of the mobile app are intended to support the latest Music Assistant Server stable version at the time of release and one previous stable version. Run an older server, or track the server's development branch, and you are outside the supported window with no compatibility promise.

CarPlay is the third. The README calls it a very early state with many expected bugs, which is a different risk profile from the Android Auto path, where the project documents testing and limitations in docs/ANDROID-AUTO.md. If in-car use is the reason you are here, that asymmetry should shape which phone you install it on.

Finally, the release channel itself is a limitation. Android users get an APK from the releases page and iOS users get a TestFlight build, so there is no store review, no staged rollout, and no automatic update story described in the README. For a household appliance this is tolerable; for a phone you rely on daily it is a maintenance commitment.

Music Assistant Mobile compared with a generic Subsonic client

The obvious alternative is a mature third-party client for a music streaming protocol, most commonly a Subsonic-compatible app paired with a server that exposes that API. The difference is where control lives.

A Subsonic-style client is a player and a browser. It sees a music library and plays it. Music Assistant Mobile is a controller first: its job is managing players, queues and groups on the server, and local playback is one mode among several rather than the whole product. If you have a house full of speakers driven by Music Assistant, the Subsonic model does not give you player transfer, grouping, or a single place to see what is playing on the kitchen speaker from your phone.

The trade-off runs the other way too. A generic client is usually store-published, has years of offline caching behaviour, and does not care which server version you run. Music Assistant Mobile is pre-release, tied to a two-version server window, and explicitly not built for offline. Choosing it means choosing the Music Assistant ecosystem, not just a player.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-26, with releases the same day: ios-v1.0-build-49, ios-v1.0-build-48, and android-v0.12.0. The iOS and Android version numbers tell their own story about maturity, with iOS at 1.0 and Android at 0.12.0.

The upgrade cost is real but bounded. Because releases track the latest Music Assistant Server stable plus one previous, upgrading the server eventually forces a mobile app upgrade, and upgrading the app can force a server upgrade. It is a two-sided upgrade loop rather than a one-way dependency, and the README does not describe a rollback procedure for either side.

The licence is Apache-2.0, per the repository. That permits use, modification and redistribution under the terms of that licence, including a patent grant, and it requires preserving notices and stating changes. It does not by itself grant rights to the Music Assistant name or logos, and nothing here should be read as legal advice; if you plan to redistribute a modified build, read the LICENSE file and the trademark position of the upstream project yourself.

Editorial conclusion

Adopt it if you already run a Music Assistant server, want in-car control through Android Auto or CarPlay, and can live with APK updates and TestFlight builds. Skip it if you need offline playback, static group creation, or a store-published app, because the README says the project is not in a production state and is not intended for offline playback. Before installing, check that your server runs the latest stable release or the one before it, since releases of the mobile app target those two versions.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes