Morphe Desktop: patching Android apps from a CLI or a GUI

What Morphe Desktop does and what it leaves to others

Morphe Desktop is an application for patching Android apps, and the README splits the responsibility in two. The patching itself is done by Morphe Patcher, a separate component with its own repository, and Morphe Desktop is the layer around it. That layer comes in two forms. There is a command line interface, and the README states plainly that it is based on the prior work of the ReVanced command line tool, so the argument handling and the general shape of the commands come from that lineage. There is also a graphical interface, developed by the Morphe team, which is what the README recommends for a first time user. Everything else is packaging. The README states that all modifications made by Morphe can be found in the Git history, which is the honest way to look at the difference between the two projects without reading either codebase. The audience is a developer or power user who has an app package, has a set of patches, and wants to produce a modified package. It is not an app store, it is not a catalogue of tweaks, and it does not download anything for you.

Two front ends, and the Quick mode the GUI opens with

Morphe Desktop runs in two modes, and the README describes how you enter each. The CLI mode is started by calling the tool directly in your preferred terminal. The GUI mode is started by double-clicking the downloaded jar file, which opens the Morphe Desktop window. The README recommends the GUI for a first run and suggests moving to the CLI once you are comfortable, and it explains why with a small but important detail about packaging. The GUI is described as far more user-friendly and straightforward than the CLI, and on first launch it opens in Quick mode, which the README calls the simplified, non-expert path. That first-launch behaviour is also where the packaging note sits. Morphe ships as a single small jar, and while the command line tool runs on its own, the GUI needs a couple of platform-specific components, among them Skiko, which the README begins to name before the text stops. So the first launch of the GUI is the one moment where the application may fetch or unpack extra native pieces, while the CLI is self-contained from the start. Anyone automating the tool should plan around the CLI and treat the GUI as the exploratory surface.

The five inputs the README asks you to assemble first

The prerequisites section is the most concrete part of the documentation, and it lists what has to be in place before any patching happens. First, a Java Runtime Environment, version 21 or above, with Azul Zulu JRE, Temurin and OpenJDK all named as options. Second, the Morphe Desktop jar file, named morphe-desktop-*-all.jar, downloaded from the project's releases page, with the Homebrew route offered as an alternative for macOS and Linux, where the formula pulls in OpenJDK as a dependency. Third, if you are using the CLI, a patches file in the MPP format, named patches-*.mpp, taken from the Morphe official patch files repository. Fourth, the app you want to patch, as app.apk or app.apkm, with APK Mirror named as a source. Fifth, and marked optional, the Android Debug Bridge, and the reason given is specific and useful: ADB is what lets you install the patched APK to your device directly from your computer. Note the consequence of that list. The tool does not contain the patches, it does not contain the app, and the repository it lives in has a home page, Morphe.software, and separate GitHub repositories for the patcher and for the patches themselves.

Installing from Homebrew and the first launch caveat

There are two installation routes and they suit different habits. The manual route is to download the jar from the latest release and run it with a Java 21 runtime on your machine. The packaged route is the Homebrew formula, which the README describes as the alternative for macOS and Linux: you install Homebrew, then run the install command, and the formula installs OpenJDK as a dependency so you do not have to arrange the runtime yourself. The README then points you at the help output to get started, and links the Morphe formula page for details.

brew install morphe

Two things to expect on the first run. The first is the GUI's Quick mode, described above as the simplified path that opens on first launch. The second is that the GUI pulls in a couple of platform-specific components, including Skiko, the first launch only, so the very first start of the window needs those pieces in place while the command line tool does not. Neither of the two modes needs the patches or the app file to be present just to open, but both need them before they can do any work.

The patch file is the part that comes from elsewhere

The division of labour in this project is the thing worth understanding before you use it. Morphe Desktop applies patches. The patches themselves are published separately, as MPP files named patches-*.mpp, from the Morphe patches repository, and the README points you at the latest official patch files there. The application file is likewise something you supply, as an APK or an APKM, and the README suggests APK Mirror as a place to get it. This structure has consequences. A user who installs Morphe Desktop and stops there has a tool that can do nothing, because without a patch file there is no modification to apply, and the application you want to modify has to be obtained separately. It also means the tool is agnostic about what the patches do, which is why the README can honestly say that you can experiment with other apps, and why the recommended list is a recommendation rather than a restriction. The repository ships a documentation file at docs/documentation.md for the full usage guide, and the README is explicit that sticking to the suggested apps is recommended even though the tool itself does not enforce that.

Gradle, semantic-release and the translation setup

The repository layout says more about how the project is built than the README does. It is a Kotlin project built with Gradle, with build.gradle.kts, settings.gradle.kts, a gradlew wrapper for Unix and gradlew.bat for Windows, a buildSrc directory for custom build logic, and proguard-rules.pro for shrinking rules. The src directory holds the application code, and there is a scripts directory plus a .run directory for IDE run configurations. Two entries point at the release process. There is a package.json whose dependencies are entirely about releasing: semantic-release, the semantic-release changelog and git plugins, a Gradle semantic release plugin, and a backmerge helper. There is also a .releaserc file, so the version and the changelog are produced by that tooling rather than by hand. The release tags on the repository are consistent with that setup, and with the fast iteration the project allows: the three most recent listed releases are v1.19.0-dev.9, v1.19.0-dev.8 and v1.19.0-dev.15, all published on 2026-10-19, which is the usual shape of a project that publishes development builds continuously. A crowdin.yml file indicates that the user facing text is translated through Crowdin, and an aboutlibraries directory holds the third party licence records.

GPL-3.0 and the limits of what the tool will do for you

The licence is GNU General Public License version 3, which matters for anyone who wants to redistribute the tool or build on it, because it carries both source availability and copyleft obligations for derived work. The README also points out that all modifications made by Morphe to the codebase are recorded in the Git history, which is a practical resource rather than a licence term: you can see exactly what the Morphe team changed relative to the ReVanced work the CLI is based on. On the limits of the tool itself, three are worth stating plainly. It patches the package you give it and nothing more, so it cannot obtain an app for you. It needs the patch file in the MPP format, so the set of possible modifications is bounded by what the patch author wrote. And the install step to a device needs ADB, which the README lists as optional, so a patched APK on your computer is the normal end state rather than an installed app. The README also frames the scope loosely, recommending the suggested apps while inviting experimentation with others, which is a statement of intent rather than a technical limit, and it is on the user to check the terms of the app being modified.

Editorial conclusion

Morphe Desktop fits a developer who owns the app they want to modify, already has the APK or APKM and a patch set, and wants a repeatable command line patching flow plus a GUI for exploring options. It does not fit someone looking for a one-click app store installer, because the patch files come from a separate repository and the tool does nothing without them, and it does not fit a team that cannot ship GPL-3.0 code. Before you run it, verify the three inputs the README lists, a Java 21 or newer runtime, a morphe-desktop jar, and patches in the mpp format, and check the release tag you install, since the recent tags are development builds such as v1.19.0-dev.15 published on 2026-10-19.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. MorpheApp/morphe-desktop on GitHub
3. Project website
4. README
5. Releases