Cosmic IDE: a full Arch Linux ARM userland inside an Android app
A desktop-class, general-purpose IDE for Android, powered by a full Linux environment.
At a glance
- What is it?
- Cosmic IDE is a GPL-3.0 Kotlin Android application that runs real compilers, build tools and language servers inside an app-private Arch Linux ARM environment. It is a serious option for JVM work on a phone or tablet, and a poor fit for anyone expecting a supported, frequently released product.
- Who is it for?
- Adopt Cosmic IDE if you want to compile and run JVM or Rust code on an Android tablet or DeX device and you are willing to accept a nightly-only download, an Arch Linux ARM userland you administer yourself, and a release history that stopped at v2.0.3 in October 2023. Do not adopt it if you need a supported product with an upgrade path, or if your work depends on tooling that only ships for x86_64.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Cosmic IDE targets: a compiler on a device that has no Linux userland
Android ships a kernel and a runtime, not a POSIX userland you can install packages into. That is why most mobile code editors stop at editing: they highlight text and sync it somewhere else to be built. Cosmic IDE takes the opposite route. Its README describes it as "a runtime that hosts genuine compilers, build systems, and language servers", and the architecture section states that it provides "a complete Linux-based development environment inside an Android app" that is "compatible with Arch Linux ARM".
The audience is narrow and specific. It is the developer who already carries an Android tablet, a phone with a keyboard, or a Samsung DeX setup, and who wants to open a Gradle, Maven or Cargo project and actually build it without a second machine. The README's screenshots point at the same audience: Scala completion through Metals, a successful Scala Gradle build in the integrated terminal, Java diagnostics and quick fixes, Java completion backed by JDT LS. This is JVM-first tooling, not a general-purpose scratchpad for editing config files.
The claim worth examining is the phrase "desktop-class". It is defensible only because of the Linux layer. Without a real userland there is no pacman, no compiler toolchain, and no language server process to talk to. Everything else in the app depends on that layer existing.
How the Linux environment, the terminal and the plugin system fit together
The mechanism described in the README has three moving parts. The first is an app-private Linux environment compatible with Arch Linux ARM. The second is a PTY terminal, described as "a full-featured PTY terminal", which is the interface to that environment. The third is a plugin layer that supplies language intelligence to the editor.
The data flow is conventional for an IDE, with one unusual twist. Language servers run as processes inside the Linux environment rather than as Android services, and the editor talks to them over the Language Server Protocol. The README names the servers it expects: Metals for Scala, JDT LS for Java, rust-analyzer for Rust, clangd for C and C++, LuaLS for Lua. Because those are ordinary executables in an Arch Linux ARM userland, they are installed and updated with pacman rather than bundled in the APK. That is the design decision that makes the plugin marketplace meaningful: the app ships the editor and the plumbing, and the userland supplies the heavy binaries.
Build execution follows the same pattern. The README says tasks such as Gradle, Cargo and Maven run with "real-time output in integrated tool windows", which implies the build runs in the Linux environment and the app renders its stdout. Git is handled in-app for cloning, branching, committing and syncing, so not every workflow requires dropping into the shell.
The plugin system is the part with the least public detail. The README says support for languages and build tools can be "added or updated independently" and that you can add "custom language servers, TextMate grammars, and project templates without modifying the app's source", and it points to docs/plugin-architecture.md for the actual contract. Without reading that document, the boundary between what a plugin can do and what is hardcoded in the Kotlin app is not something I can state.
Getting it running: nightly APK, guided bootstrap, then pacman
There is no stable download link in the README. The Quick Start section points at a nightly build artifact, app-arm64-v8a.zip, produced by the project's Android CI workflow. The architecture string in that filename matters: the build is arm64-v8a only, consistent with the Arch Linux ARM userland underneath. A device that is not 64-bit ARM is not addressed by the material at all.
The three documented steps are short. Install the nightly APK. Follow "the guided setup to install a JDK and the base Linux environment". Then create a new project or clone a repository. The JDK install is called out separately from the base environment, which tells you the bootstrap is not a single tarball extraction; there is at least one component the app fetches or installs on top of the base system.
After bootstrap, the package manager is the main configuration surface. The README states you can "install and run tools from the official Arch Linux ARM repositories using pacman", and lists package management as a feature: use pacman to install CLI tools, compilers and utilities. So a typical setup step for, say, a C project is a pacman invocation for the toolchain, followed by installing clangd through the in-app Plugin Marketplace. The README says language support is managed and installed "directly from the in-app Plugin Marketplace", which is where you go for Metals, JDT LS, rust-analyzer, clangd or LuaLS rather than pulling them by hand.
Project storage is worth noting before you start. The README says projects remain "in app-private storage or shared storage via Android's Document Picker". Those are two different trust and backup models, and the README does not say how a project moves between them.
Where Cosmic IDE is the wrong tool
The release history is the first limitation, and it is not a small one. The most recent release listed is v2.0.3, dated 2023-10-05, following v2.0.2 two days earlier and v2.0.1 in late September 2023. The repository's last push is 2026-08-21T14:37:27Z, so there is activity on the default branch, but the README's own install path is a nightly artifact rather than a tagged release. Anyone who needs a version number to pin, a changelog to read, or a rollback target is working outside what the project currently publishes.
The second limitation is the userland itself. Arch Linux ARM is a rolling distribution. The README presents pacman as a feature, and it is, but it also means the toolchain under your project moves when you update. A Gradle or Cargo build that works today can break after a pacman upgrade, and there is no documented pinning or snapshot mechanism in the supplied material. You are the administrator of that environment.
The third is architectural reach. The nightly artifact is arm64-v8a. Nothing in the README describes an emulation layer, so x86_64-only binaries are out of scope by construction. If your build depends on a proprietary tool that ships only for x86_64 Linux, Cosmic IDE cannot host it, no matter how good the editor is.
Finally, the touch-first framing cuts both ways. The README claims the UI is "optimized for touch, keyboard, and Android desktop environments like Samsung DeX". A phone screen with a soft keyboard is a poor place to read a Gradle stack trace. The screenshots show a touch-friendly project explorer, which is honest about the target: this is a tablet and DeX tool that happens to run on phones.
How it differs from Termux plus a text editor
The obvious alternative on Android is Termux with a terminal editor such as Neovim, or Termux with a lightweight GUI editor alongside it. Both approaches run a Linux userland on Android, so the difference is not the presence of a shell. It is where the integration lives.
In the Termux approach, the editor and the language server are separate programs you wire together yourself: you install the server, configure the client, and manage the session. Cosmic IDE instead ships an editor with LSP support, inline diagnostics and quick fixes, a project explorer, Git workflows and build output tool windows as one application, and it exposes the underlying environment through a terminal rather than making the terminal the primary interface. The README frames the plugin marketplace as the distribution channel for language support, so Metals or JDT LS arrive as an in-app install rather than a manual configuration exercise.
The trade-off runs the other way too. Termux is a general Android terminal with its own packaging and a much wider set of users; Cosmic IDE is a single application with a single arm64-v8a nightly build, and its Linux environment is app-private, which the README presents as a privacy property ("your projects remain in app-private storage") but which also means other Android apps cannot reach into it. If you want your toolchain to be scriptable from outside the IDE, the app-private model works against you. If you want your build environment isolated from the rest of the device, it works for you.
Licence and the cost of keeping it current
Cosmic IDE is licensed under the GNU General Public License v3.0. For anyone using the app as a tool, that is unremarkable. For anyone modifying it or redistributing a build, GPL-3.0 carries obligations around source availability and derivative works, and the plugin architecture is the interesting question: the README invites you to add language servers, TextMate grammars and project templates "without modifying the app's source", which suggests plugins are configured data rather than linked code. Whether a given plugin is a derivative work is a question for a lawyer, not for this article, and nothing in the supplied material settles it.
Maintenance cost is the part that is easy to underestimate. Three things move independently. The app itself moves with the default branch, since the documented install is a nightly. The Linux environment moves with Arch Linux ARM, since pacman pulls from rolling repositories. The language servers move on their own schedules, installed through the marketplace. A working setup is therefore a snapshot of three moving parts, and the README documents no version pinning for any of them. The practical consequence is that reproducing a build environment six months later depends on what the Arch Linux ARM repositories still serve at that time.
The project is funded through Open Collective, linked from the README, and the README states it is free and open source. There is no commercial support tier described, no LTS branch, and no compatibility matrix. Budget for the setup being a weekend project you own, not a product you consume.
Who should install it, and what to check before trusting it with a real project
Cosmic IDE is worth installing if your work is JVM-centric and your hardware is an arm64 Android tablet or a DeX setup. The README's examples are exactly that: Scala completion through Metals, Java diagnostics through JDT LS, a Gradle build running in the integrated terminal. If you already know Gradle and you want to edit and build on the same device, the architecture is aimed at you. The same applies to Rust and C/C++ work, provided rust-analyzer or clangd is available in the marketplace and the toolchain is available through pacman.
It is not for you if you need a pinned release, a support contract, or x86_64-only tooling. It is also not for you if you expect the editor to be the whole product: the README is explicit that the Linux environment is the foundation, and if you are not comfortable running pacman, you will hit a wall early.
Before moving a real repository onto the device, verify the bootstrap on your specific hardware. Confirm the guided setup installs a JDK without errors, then open the terminal and confirm pacman can reach the Arch Linux ARM repositories and install one package you actually need. Then check the in-app Plugin Marketplace for your language server. If all three pass, the environment is real. If the bootstrap fails on your device, nothing downstream matters, and the nightly-only download means there is no older tagged build to fall back to.
Editorial conclusion
Adopt Cosmic IDE if you want to compile and run JVM or Rust code on an Android tablet or DeX device and you are willing to accept a nightly-only download, an Arch Linux ARM userland you administer yourself, and a release history that stopped at v2.0.3 in October 2023. Do not adopt it if you need a supported product with an upgrade path, or if your work depends on tooling that only ships for x86_64. Before committing a project, verify three things on your own device: that the guided bootstrap installs a JDK successfully, that pacman can install the specific compiler or CLI tool you need, and that your target language server is present in the in-app Plugin Marketplace.
Community notes