ReVanced Manager: the newest release is still a dev build

The most recent release is still a dev build

Three of the last releases are v2.7.0-dev.9, v2.7.0-dev.10 and v2.7.0-dev.11, dated 16 July, 23 July and 29 July 2026, and the last commit on the repository is 29 July 2026. Every one of them carries a -dev suffix, so what the version series says is 2.7.0 with a dev counter sitting on top, not a numbered stable build. That matters because the download section points people at the GitHub releases/latest link, and that link resolves to the most recent release whatever it happens to be named. If you want a build you can name and return to, there is no stable tag in the recent list to pin to. And the counter alone tells you nothing about whether the underlying application actually changed between dev.10 and dev.11, only that something was cut.

The manager patches apps, but the patches live somewhere else

ReVanced Manager is an application that uses ReVanced Patcher to patch Android apps, and the README lists three features as some of what it provides. Download automatically downloads apps using the ReVanced Manager downloader system. Patch selects and applies patches to any Android app. Customize manages patches, apps, signing, themes, updates and other settings. Read closely, none of those three is a list of modifications. This repository is the tool that applies changes, and the changes themselves are named elsewhere. The practical consequence is that installing the manager hands you the instrument and not the instructions for it. The README carries no patch inventory that tells you what a given patch alters about a target app, so if you want to know what you are about to apply before you apply it, this is not the place to read.

Download is a feature, so the tool fetches what it will modify

The Download feature automatically downloads apps using the ReVanced Manager downloader system, which puts the manager in charge of obtaining the application it is about to patch. That inverts the usual order. Instead of installing an app from somewhere and then modifying it, the tool fetches the package first and hands those bytes to its own patcher. Two things follow for anyone planning an install. The downloader sits in the chain that has to work, and a failure there stops the whole flow before any patching is attempted. And the target app version is whatever the downloader returns, a moving input to a patching step. The README does not state which app versions the downloader is expected to return.

Signing lives in settings, and the license covers the tool not the output

Signing is one of the things Customize manages, alongside patches, apps, themes and updates, so producing a signed build is a supported part of the flow rather than something you assemble by hand. What the README does not give you is the mechanics: no key store format is stated, no statement appears about where signing keys are kept once entered, and nothing addresses rotation. The license question is worth separating, because it is easy to conflate. ReVanced Manager itself is GPLv3, and the project states you may copy, distribute and modify it as long as you track changes and dates in source files, and that modifications must also be made available under the GPL along with build and install instructions. That grant covers the manager. The license is silent about the apps you patch with it.

One checkout carrying a Gradle project and an npm workspace

The root of the repository holds a Gradle project: build.gradle.kts, settings.gradle.kts, gradle.properties, a gradle/ directory, and both the gradlew and gradlew.bat wrappers, which is the Android build. Beside it sits a package.json marked private, declaring workspaces for api and app, along with package-lock.json. The telling detail is what that package.json contains. There are no runtime dependencies in it, only two devDependencies, semantic-release and @anolilab/multi-semantic-release. So npm is not how the application runs. It is how versions get cut. A contributor working in either the api or app workspace needs both toolchains present in a single tree, and build instructions are delegated to the documentation rather than laid out where the project files are.

Versions come from commit messages across two workspaces

Because the release tooling is multi-semantic-release configured over the api and app workspaces, each release spans more than one package and the numbers are derived rather than typed by hand. That is the mechanism behind a -dev.9, -dev.10 and -dev.11 sequence landing about a week apart, and it means the version you install is a function of what was committed rather than a decision somebody made on a release page. The consequence for contributors is narrow but real: if a commit message does not carry the type and scope the tooling reads, the change ships without a version bump attached to it. CONTRIBUTING.md holds the contribution guidelines, and the same documentation directory is where usage and build questions are answered.

The repository page answers none of the questions people arrive with

Download links are given for the newest version, at revanced.app/download and at the GitHub latest release. Learning to use the manager, and building it, both point at the same docs directory in the repository. Nothing further is answered here. The minimum Android version is not stated. Whether a rooted device is required is not stated. There is no list of supported target apps, and no explanation of where a first-time user obtains a patch set. The effect is that the repository page works as a signpost rather than a manual. Questions people arrive with, including how to patch a named app and whether it works without root, get handed to the docs directory. If you are trying to decide whether this runs on the device in front of you, this README will not settle that question.

crowdin.yml and adsfund.json sit beside the Kotlin source

Two configuration files sit at the root of an otherwise Kotlin repository: crowdin.yml and adsfund.json. The file names correspond to a hosted translation service and a funding configuration, and neither is described on the repository page. The project presents itself as continuing the legacy of Vanced and invites people to contribute, but the only contribution pointer given is a link to CONTRIBUTING.md, whose contents are not summarized. So if you want to help with translations, the route runs through an external service configured in a YAML file rather than a folder in the tree, and the README does not say which languages are in scope or who reviews incoming strings. Two small files, both meaningful for how the project operates, both left for you to infer.

Editorial conclusion

Use it if you intend to modify Android applications and you are comfortable deciding which patch set to point it at, because the manager gives you the mechanism and the settings, not the modifications. Do not pick it expecting documentation on the repository page: no minimum Android version, no root requirement, and no supported-app list appear there. Before committing, confirm three things for yourself, namely the Android version your device runs, where your patch set comes from, and what key ends up signing the output, since the GPLv3 grant covers the manager and says nothing about the apps you patch with it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. ReVanced/revanced-manager on GitHub