SeriesGuide: a solo-maintained Android TV tracker with a two-license split

One maintainer, one app, and a licensing structure that anticipates reuse

SeriesGuide is an Android application for keeping track of TV shows and movies, written in Kotlin, and published by a single developer, Uwe Trottmann. The download, help and support links all point at seriesgui.de, and the repository is not a thin client for someone else's service: it is the app itself, including its database, its sync layer and its widget set.

The licensing is the first thing to understand because it is deliberately layered. The README states the program is licensed under GPL 3.0 or later, and then carves out an exception that matters to anyone building on top of it: some parts, including the SeriesGuide API library in the `/api` directory, are licensed under the Apache License 2.0. That combination is a common pattern for GPL applications. The app stays copyleft, while the pieces a third-party developer would want to call or embed are permissively licensed so they can be used without dragging the whole application along.

GitHub itself reports no license identifier for this repository. The README statement and the GitHub field disagree, and both facts belong in your reading of the project. What settles it in practice is the `LICENSES/` directory, which holds the actual GPL-3.0-or-later and Apache-2.0 texts the README links to, and the project's own claim that every file carries an `SPDX-License-Identifier` tag on its first possible line plus `SPDX-FileCopyrightText` comments naming copyright holders. That per-file tagging is what you would check if you needed to reuse one specific class rather than the app.

What the top-level layout reveals about scope

The tree tells you what kind of codebase this is before you read a line of Kotlin. Alongside the familiar `app/` module you have `api/` for the permissively licensed client library, `backend/` for whatever the app talks to beyond Trakt, `build-logic/` for convention plugins rather than a flat `build.gradle` file, `flatbuffers/` for generated schema code, `widgets/` for the home screen and Wear surfaces, `translations/` for the string resources, and `store/` for Play Store listing material.

Two build files sit at the root, `build.gradle.kts` and `settings.gradle.kts`, next to `gradle.properties` and the `gradle/` directory, so this is a Kotlin DSL Gradle build rather than the older Groovy style. The presence of `build-logic/` as its own directory says the project has outgrown a single root script, which is a sign of a maintained build rather than a neglected one.

The `docs/` directory and `CREDITS.txt` are worth a look if you are considering reuse. `CREDITS.txt` is the dependency attribution file the README points at for licences and copyright holders of everything SeriesGuide pulls in, and it is the honest place to start if your question is what ships inside the APK. `docs/` suggests the project keeps developer documentation in the tree rather than only on the website.

The Trakt dependency reshaping features in 2026

Repository topics include both `trakt` and `tmdb`, which is the shortest way to see where the metadata comes from. The 2026 release notes then show what depending on somebody else's service looks like from the maintainer's side.

Release 2026.4.3, published on 2026-09-23, sends Trakt links to a new web app and renames Trakt comments to reviews. Release 2026.4.2, seven days earlier, does the same renaming, adds a rule that sync skips uploading a show when sync adds it, and fixes a crash when updating a show that had just been removed. The rename landed in two consecutive releases, which tells you it was a multi-step migration rather than a one-line change.

That is the real architectural constraint on this project. SeriesGuide holds show data locally and reconciles it with remote services, so when a remote service reorganises its own product, the app inherits the work whether it planned for it or not. If you are evaluating the app, that is worth more than any feature list: it means sync behaviour is the part most likely to need maintenance, and the release notes are the honest record of that. The movie side got a related treatment in 2026.4.3, which caches genres and trailers in the local database and shows cached data immediately rather than blocking on network requests.

Rotation handling and autofill tell you where the bug reports actually come from

Two separate releases, 2026.4.1 and 2026.4.3, both carry a fix for preserving entered text when the screen rotates or the app window is resized, covering the comments screen, list add, list edit and the check-in dialog. The fact that the same item appears in both, with the second phrased as once again, tells you this was a recurring report rather than a one-off.

2026.4.1 also shows the app reacting to a platform dependency going wrong. It drops a Play services security provider that was causing not-responding issues when launching the app on some devices, adds autofill hints and correct next or done keyboard buttons, and makes the app always ask which saved password to use when signing in to cloud sync. It also hides the more-information link when installed via the Play Store in all regions again, to comply with the Payments policy.

For a reader deciding whether to depend on this project, that list is a fair sample of what maintenance means for a single-maintainer app with cloud sync and store distribution. Most of the work is not new features. It is platform behaviour, input handling and policy compliance, all of which arrive from outside the project.

Dev branch, main branch, and a version number nobody else would pick

The default branch for this repository is `dev`, but the README's release notes link points at `blob/main/CHANGELOG.md`, and the README's contribute link is a relative path to `CONTRIBUTING.md`. Both facts are in the repository as published, and they disagree about which branch is the front door.

That matters more than it sounds if you intend to build from source, because the two branches can be at different points and you would be reading documentation that may describe a tree you do not have. The practical check is to look at the branch your clone actually checked out and confirm which branch the README link resolves to before drawing conclusions from it.

The version scheme is the other unusual thing here. Releases are tagged `v2026.4.3`, `v2026.4.2` and `v2026.4.1`, so the version is a year plus a sequence rather than a semver major/minor/patch line. Releases land weekly during this period, 2026-09-04, 2026-09-17 and 2026-09-23, and the last push to the repository was on 2026-09-25. If you are pinning a build, understand that the tag does not carry semver compatibility promises; the changelog is where the compatibility information lives.

The release tooling is in the repository, not in a wiki

SeriesGuide keeps its release process in the tree, which is a useful signal for anyone reading the project as a template. There is `RELEASING.md`, an `insert-next-release.sh` script at the top level, a `CHANGELOG.md` for the user-facing notes and a separate `CHANGELOG-K.md`, and a `.gitattributes` file alongside a `CHANGELOG-K.md` that appear to cover localization changes.

./insert-next-release.sh

Translation work is handled outside Git. The README states that translation contributors are tracked on Crowdin rather than in the commit history, which is the normal arrangement for an app of this size and explains why `translations/` exists as a generated-facing directory rather than a stream of per-language commits.

If you want to read this project as a reference for a native Android app with sync, the order that pays off is CONTRIBUTING.md for the working setup, then the app module's data layer, then the backend and api directories to see how the remote calls are structured. The website carries the user-facing help pages, and the discussion board at discuss.seriesgui.de carries the announcements, so neither the README nor the repository alone tells the whole story.

Editorial conclusion

SeriesGuide is a good reference for a native Android app that has to live with a third-party API changing its own product underneath you, because the 2026 release notes are mostly that story: Trakt links and comments moved, and the app had to follow. The licensing split is also deliberate rather than accidental, with the reusable pieces under Apache 2.0 so other projects can depend on them. Two things to settle before touching the code, though. First, build instructions are not on the README, so read CONTRIBUTING.md. Second, the default branch is dev while the README links its release notes into main, so confirm which branch you are reading before trusting anything about the current state of the tree.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. UweTrottmann/SeriesGuide on GitHub