iPlay: One Media Client for Emby and Jellyfin on Five Platforms

A Player for the Servers People Actually Run

iPlay is a modern video player for Android, iOS, Windows and macOS, and the project's own line is Play Anywhere, Anytime, On Any Device.

What it plays is the point. The feature list has support for Emby and support for Jellyfin both checked off, and those are the two self-hosted media servers that a large share of technical households run. The player is the client half of that arrangement, not a streaming service with its own catalogue.

The remaining features are the smaller ones that separate a usable client from a demo. There is a multi-site switch, so one app can point at more than one server, which matters for anyone with a library split across a home server and a remote one. There is an audio player, which is the mode for music libraries rather than films. There is support for a custom font. And there is support for Windows, which is one of the harder platforms to include.

The platform list in the README names Android, iOS, macOS, XBox and Windows, and the store table below it adds tvOS through the Apple listing and Harmony through the Huawei AppGallery listing, so the target is six platforms rather than five once the tvOS and Harmony builds are counted.

Where Each Build Is Published

The store table is the clearest description of the platform matrix, and it is organised by target rather than by feature.

There are two Microsoft store entries, one for XBox and one for Windows, both under the apps.microsoft.com domain with different product identifiers. The Apple listing covers MacOS, iOS and tvOS in one app, and the Google Play listing is for Android with the application id top.ourfor.app.iplay. The Huawei AppGallery listing is the Harmony build, and its id carries the capitalised iPlay spelling, which is a small difference from the other platforms' identifiers.

The direct downloads are separate from the store listings. The Android and iOS builds are both linked to the latest release on the repository, and the TestFlight link is for the iOS beta, so the Apple ecosystem has three routes: the App Store, TestFlight and the GitHub release.

That split is worth noting for an evaluator. A store build is signed, reviewed and updated on the vendor's schedule, while a GitHub release build is whatever the maintainer published. The build workflow in the repository produces the Android artefacts that end up in those releases.

The Makefile Produces Three Android Architectures

The build system is a Makefile, and the interesting part is that the version information comes out of git rather than out of a file.

The variables at the top set the project root, the build directory and the app name, then the version is assembled from two git commands. BUILD_ID is the short hash from git rev-parse, VERSION_NAME combines the version string with that hash, and VERSION_CODE is the total number of commits from git rev-list --count HEAD.

The default target builds three things in sequence, an apk, an aab and an aws-aab. The apk target runs the Gradle assembleRelease task and then copies three artefacts out of the build output, one for each Android architecture: arm64-v8a, armeabi-v7a and x86_64.

The gradle invocation itself is:

cd $(ANDROID_DIR) && ./gradlew assembleRelease -PversionName=$(VERSION_NAME) -PversionCode=$(VERSION_CODE)

So the version name and the version code are passed into Gradle as properties rather than being edited in a build file, and the commit count is what an app store uses as the version code. The aab target does the same thing with the bundleRelease task, which is the Android App Bundle the Play Store expects, and clean removes the build directory and runs the Gradle clean task.

The Amazon Build Rewrites the Application Id

The aws-aab target is the one piece of the build that deserves a warning, because it modifies your working tree.

The target contains a comment explaining what it does, and then it runs a substitution in the Android Gradle file:

sed -i '' 's/applicationId "top.ourfor.app.iplay"/applicationId "top.ourfor.app.iplayx"/' $(ANDROID_DIR)/app/build.gradle

The application id is changed to a variant with an x suffix, and then the bundle is built and copied out as the Amazon aab. The reason is that the Amazon Appstore requires a distinct application id from the Google Play build of the same app, so the two cannot coexist in one device's app list under the same identifier.

What the target does not do is undo the change. It rewrites the file and leaves it rewritten, so a subsequent build of the Play variant would produce an app with the wrong id unless the file is restored by hand. The clean target removes the build directory and runs the Gradle clean, but it does not touch the Gradle file either.

For anyone who builds this themselves, that is the step to be careful about, and it is a reminder that the Makefile here is a maintainer convenience script rather than a general purpose build system.

Player Engines Behind the App

The third-party dependencies section is short and reveals the architecture.

Under Player there are three engines: mpv, vlc and exo, which is ExoPlayer. So the video decoding is delegated to established players rather than implemented, with mpv and VLC for the desktop and mobile shells and ExoPlayer for Android, where it is the platform-native choice. The primary language of the repository is recorded as C, which is consistent with a codebase that talks to native player engines and to the platform's own media stack.

Under Utils there are okhttp, the HTTP client, and lombok, the Java boilerplate reducer. The presence of an HTTP client in the utility list rather than the player list is a small signal about where the work is: the app is as much a client of the Emby and Jellyfin APIs as it is a player.

The UI work is also pointed at rather than embedded. The design section links to Figma files for the player UI, for the Radix icons, for a flat icon set, and to the Fluent UI System Icons repository, so the visual design is documented in Figma and the icons come from a shared system rather than from drawings in the repository.

A One Person Project, and What That Means

The development progress section is a single sentence: it is developed in my free time.

That is the most important operational fact in the README for anyone considering depending on this project, and it sits alongside the release history, which is a string of v1.0 tags with the build hash in the tag name. The recent releases are v1.0.1154 from 2025-10-17, v1.0.1133 from 2025-09-14 and v1.0.1123 from 2025-09-11, so the numbering is a running count rather than a semantic version, and the hash in the tag ties each release to a commit.

The repository layout reflects a mobile-first project with a second target. There is an android/ directory for the Gradle build, a harmony/ directory for the Huawei platform, a tools/ directory, a doc/ directory holding the screenshots used in the README, and a PRIVACY.md at the root. The Windows and Apple builds are not visible as directories here, which suggests they are built from elsewhere or not from this tree, while the Android build clearly is.

The community side is a Telegram product discussion group and a bug report channel. The licence is GPL-3.0, the repository is not archived, and the last push was on 2026-05-17, so the project is alive but on the schedule of one person with a day job.

Editorial conclusion

iPlay fits a household that runs Emby or Jellyfin and wants one player across a phone, a desktop, a television and a console, and that wants a build it can produce from source rather than only store downloads. It is a poor fit if you need the audio mode or the multi-site switch in a build that does not come from the maintainer, and a poor fit if you expect a rapid release cadence, since the releases are tagged from a single developer's free time. Before building it, read the Makefile, because the version name and version code are derived from the git history rather than from a file, and note that the Amazon build is produced by rewriting the applicationId in the Gradle file, which means a build run modifies your working tree. The project is GPL-3.0 licensed, the newest release is v1.0.1154 from 2025-10-17, and the last push was on 2026-05-17.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. saltpi/iPlay on GitHub