Unyo: a desktop anime and manga client built on Aniyomi extensions

What Unyo is: a desktop client for the Aniyomi extension ecosystem

Unyo is a desktop application for streaming anime and reading manga, written in Dart and built with the platform folders that Flutter desktop projects produce: linux/, macos/, windows/, plus linux-appimage/, snap/ and a windows-installer/ directory with an Inno Setup script. The project ships a pubspec.yaml and a .fvmrc, which pins the Flutter version used for development.

The README describes it as inspired by Dantotsu, and the technical debt of that origin is stated plainly. The extension system comes from Aniyomi, and the author explains the consequence: because the original project was for Android, a lot of the codebase had to be adapted to work on PCs, which means not all extensions will work. The parenthetical note that this is most likely a skill issue is unusually candid, and it is the single most important thing to know before you plan around a particular source.

What Unyo adds around that core is a desktop user interface with animations, and AniList integration that syncs what you consume. The README's summary is that it is fully integrated with AniList, so whatever content you consume is synced automatically, and that it is ad-free. The topic list names the other moving parts: torrent, torrentio, anilist, custom-api and aniyomi-extensions, which tells you that both local-file and streaming paths exist in the design.

The scope is a client, not a content host. Sources come from elsewhere, and the repository contains no source catalogue of its own; Unyo-Extensions is a separate repository for local ones. That division shapes everything else about how you install, configure and rely on the app.

Installing Unyo across Windows, macOS and Linux

The README's installation section splits by platform, and Linux gets the most options. On Windows you either download the .zip, extract it and run the executable named unyo.exe, or download the .exe installer, run it and follow the instructions. On macOS the .dmg file is the recommended route, installed like any other Mac application; the .zip is offered but explicitly not recommended, and the recommendation is to use the .dmg file instead.

Linux has five paths. The recommended one is the AM package manager, which installs and updates the app with two commands:

am -i unyo
am -u unyo

The first installs, the second updates. For Arch-based distributions the README points at the AUR under the name unyo-bin. There is also the plain .zip you extract and run, an .AppImage you run directly, and a .deb for Debian-based distributions:

sudo apt install ./package_name.deb

Releases are published on the releases tab, with the latest linked from the repository's releases page. Version 0.6.7 was released on 2024-10-30, preceded by 0.6.6 on 2024-10-13 and 0.6.5 on 2024-09-15.

One setup step matters more than it looks. The README says that when setting up Unyo, your AniList profile must be set to either public or semi-public, because Unyo will not be able to pull your anime and manga lists if the account is set to private. That is not a preference, it is a functional requirement, and it is the first thing to check if the app opens with an empty library.

Remote extensions through the shared API, and the request path for new ones

Remote extensions come from a custom API that uses Aniyomi extensions. The app talks to that server, and the server does the source-specific work, which is why the extension list you see is the same for everyone using the hosted mode.

Adding a source is a request, not a configuration step. The README says that if you want a source added you can open an issue with the name of the extension, and that the author will try to integrate it. That is a queue in somebody's inbox, and it is the shape of the project's governance in general: a single-maintainer application where the extension catalogue is curated by hand.

The trade-off of the hosted mode is uptime and availability, and the README is honest that the backend has been a problem. Under the future section it says a new backend is being developed to bring back more extensions and improve uptime, and that the backend is pretty much done. That statement sits alongside an admission about the older code: it had started to show signs of weakness in both performance and developer experience, and new features were very hard to add.

So the remote mode trades a shared server for a simpler setup, and the price is a dependency on infrastructure you do not control, with a source list that grows when the maintainer gets to it.

Local extensions: faster, broader, and heavier on your machine

Local extensions run the same Aniyomi-based extension code, but the API runs on your computer instead of on the shared server, using a modular system. The extensions themselves are downloaded through the app from the author's separate Unyo-Extensions repository, and the README promises guides and tools later to encourage others to contribute.

The README sets out the trade-off as a list. The advantages are faster response times, more extensions, since many work locally but not on the server because of the server's location, and no dependence on the server at all. The disadvantages are that you need Java 17 or later installed on your machine, and that the app will consume more RAM, around 100 to 200 MB.

The Java requirement is the hard constraint, and the README is unusually helpful about it, pointing at Oracle's JDK 17 downloads for Linux, macOS and Windows with the observation that most people probably already have it. The RAM figure is worth weighing against the app's own footprint: the extra memory buys you independence from someone else's uptime and access to extensions the server cannot reach because of where it is located.

For a desktop user with a stable connection and the sources they need already served remotely, local mode adds a JVM to the launch path for little gain. For a user whose preferred source is unavailable from the hosted API, or who wants the app to keep working when the server does not, the trade reads differently.

The rewrite branch: what the commit history says about the project's health

The default branch for this repository is rewrite, and that name is the story. The README's Unyo's Future section opens by acknowledging that the commit history shows Unyo has been stuck for quite a while with little to no development, and says the author is now getting back on track and will be more transparent and organised about progress. The stated pace is deliberate: development will resume slowly so the author does not get burned out, with a request for patience until there is more news.

The dates confirm the shape of the story. The last three published releases are from September and October 2024, while the last push to the repository was on 2026-10-16 and the repository is not archived. So the code is moving on a branch that has not yet produced a numbered release, and the releases page still serves the older line.

The stated reason for the rewrite is maintainability rather than features. The author decided to rewrite the app so it could be more maintainable and less buggy, and notes that end users probably had not noticed, but it had started to show signs of weakness in both performance and developer experience. A Flutter rewrite with a pubspec.yaml, an analysis_options.yaml and a dart test/ directory is what that looks like in practice.

For an adopter, the practical implication is that you have two artefacts to choose between: a dated build from the releases tab, and a branch that is still moving. Neither is a bad choice, but they are different commitments, and the README does not give you a versioned changelog for the rewrite.

Known issues: crashes on exit and a DLL hijacking advisory

The README has a Known Issues section, and its first entry is about stability. The app occasionally crashes in the latest version, with the crashes said to occur only when leaving videos; the suggested recovery is to relaunch it and get back to using it quickly. The issue has been diagnosed and is on the to-do list under the Projects tab, and the expectation is that it improves in the next version.

The second entry is more serious for Windows users. The README lists a DLL hijacking vulnerability and links to the issue discussion in the repository, issue 58. The README states the fact and points at the details rather than describing the mechanism or the affected versions, so the honest reading is that a Windows build may carry a DLL search order weakness that the maintainer has documented and is tracking.

That pairing of issues is the clearest argument for the local extension mode, incidentally. A hosted extension server reduces what runs on your machine, and a JVM-based local API adds to it. Whichever mode you pick, the two known issues in the README, exit crashes and the DLL hijacking advisory, are the things to weigh first, and both are documented rather than hidden.

The repository also carries an EULA.txt alongside the BSD-3-Clause LICENSE file, an AGENTS.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, which is the usual shape for a project that expects outside contributors even when it ships from a single maintainer's account.

Where Unyo is the wrong tool

The first wrong case is needing a build you can pin. The published releases end in October 2024 and the current work sits on an unversioned branch, so a team that must reproduce a known-good desktop client has nothing to point at except an old tag and a branch that moves under it. That is a real constraint for anyone shipping Unyo inside an image or an internal package.

The second is a machine with no Java 17 and no intention of installing it. Remote extensions work without it; local extensions do not, and the README is clear that local mode is where the wider extension list and the better response times live.

The third is any workflow that depends on the extension catalogue being stable. Both modes draw on Aniyomi extensions adapted for desktop, and the README states plainly that not all of them work after the Android-to-PC adaptation. The catalogue is also curated through issues, so the set you can rely on depends on a single maintainer's queue.

The fourth is legal and licensing, and it deserves to be said plainly rather than left implied. Unyo ships no content and no sources; the sources are Aniyomi extensions maintained elsewhere and pointed at third-party sites. The BSD-3-Clause licence covers the application code, not what any particular source serves. If you intend to deploy Unyo to other people, or to use it in a workplace, you need to check the terms of the sources you configure yourself. The topic list's mention of torrent and torrentio also indicates that not every extension path is a conventional website, and that is a further reason to look at what you are pointing the app at.

A fifth case is Android. This is a desktop application with Linux, macOS and Windows packaging; there is no mobile build described, and for phone use the Aniyomi lineage it draws from remains the direct route.

Editorial conclusion

Unyo suits desktop users who already live inside the Aniyomi extension ecosystem and want a Windows, macOS or Linux client with AniList list sync and no advertising. It does not suit anyone who needs a stable, dated build today, since the latest published release is v0.6.7 from 2024-10-30 and the active work sits on the rewrite branch, and it does not suit a machine without Java 17 if you plan to run extensions locally. Verify first which branch you are installing, that your AniList profile is public or semi-public, and whether the extensions you rely on load at all, since the README states plainly that not every adapted extension works on desktop.

Frequently asked questions

Official sources

1. Issues
2. K3vinb5/unyo-app on GitHub
3. License: BSD-3-Clause
4. README
5. Releases