Roxum IDE: a Flutter code editor and mini IDE for Android

A Flutter app over a Rust editor engine

Roxum IDE is described as a mobile-first code editor and mini IDE for Android, built with Flutter, combining editing, terminal workflows, Git and GitHub tooling, AI assistance, runtime downloads and deep customization in one app.

The architecture is the interesting part and the README is unusually clear about it. Roxum uses the code_forge package as the editor engine, and the feature list describes a Rust based editor backend using rope and sum tree data structures, similar to the zed editor.

That is a real design decision rather than a wrapper around the platform's text view. A rope is a tree of string chunks, which lets an editor treat a large buffer as a sequence of pieces rather than one contiguous block, and a sum tree gives logarithmic-time aggregates over the buffer, which is what you need to answer questions like where the next match is or how much text falls in a range. Doing that in Rust rather than in the Dart of the UI is what keeps a mobile editor responsive on large files, and it is the reason the project can claim to be more than a text field with syntax colours.

The primary language of the repository is Dart, and the layout follows a Flutter project: `lib/` and `assets/` for the app, `android/` for the native host, a pubspec.yaml and pubspec.lock, plus l10n.yaml and analysis_options.yaml for the localisation and lint configuration.

Termux as the backend for the terminal side

Two of the feature bullets are about the same thing and they are what separates a code editor from a mini IDE. There is built-in Termux support for using Termux as a backend, and there is a built-in terminal.

The distinction between the two is not spelled out in the documentation, so it is worth being careful about what can be claimed. What is stated is that Termux can be used as a backend, and that a terminal is built in. A reasonable reading is that the terminal is the interface and Termux is the environment underneath it, which is what gives a phone the shell that a compiler toolchain, a language server or a version control client needs in order to run at all. The project also ships offline compilers and extensions for popular languages, so the common case does not need a network round trip to a package index.

This is the design that makes the app useful rather than decorative. An editor that only edits text on a phone is a viewer, while an editor with a working shell, a compiler and a terminal is a place where you can actually run the code you write.

Local GGUF models and external providers, side by side

The AI story comes in two forms and the feature list makes the distinction. There is support for downloading or loading local GGUF LLM models for offline chat and code completion, and separately, the ability to integrate with external AI providers for agentic editing.

The local route is the one that sets this project apart from a stock editor. GGUF is the format that local model files are distributed in, and running the model on the device means chat and completion work with no account and no data leaving the phone. On a mid-range handset, however, a local model is a serious memory and battery commitment, which is a constraint the documentation does not quantify and that you would have to judge on your own hardware.

The provider route is the opposite trade: a hosted model does the work, and the interesting capability there is agentic editing, where the model can make changes rather than only suggest text. The feature list also includes AI code completion as a separate item, which is the more modest use and the one most people will actually turn on.

Whether the local and external paths share one interface is not documented here, and that is worth checking before you commit to a setup.

LSP, Git, SSH and a long list of themes

The remaining capability list covers the things that make an editor usable on a daily basis. LSP support is listed with the specific features it brings: suggestions, completions, error highlighting and hover info. That list is the answer to the usual objection that a phone editor cannot do real language tooling, since the language servers do the work and the editor hosts them.

Alongside that there is Git and GitHub integration, and SSH support for connecting with remote systems. The Git integration is the piece that lets an edit on a phone become a commit, and the SSH support is what makes the same app a client for a machine on your desk, which is the arrangement that most people end up with: a real workstation for the work, and a phone editor for review, quick fixes and reading a diff.

The customisation entry is quantitative, which is unusual: 245 built-in themes and an option for creating custom themes. For an editor people look at all day on a small screen, that is a genuine feature rather than a gimmick, and the screenshots in the repository include a themes page and separate views for the diff, the explorer, the LSP panel, the AI completion and the terminal.

One entry deserves a note of caution. The feature list advertises external AI providers for agentic editing, and the project ships a special thanks noting that someone helped fund the Play Store release, so the app is distributed commercially in spirit even though the code is free and open source.

Building from source when the Play Store is out of reach

The installation story has two paths, and the second one is unusually well documented. The app is on the Play Store, and the README points out that if the Play Store is not accessible in your country you can download the full apk from the releases page instead. The build-from-source section is explicitly intended for users from countries like China where the Play Store is not accessible, and otherwise it recommends the Play Store build.

Building from source has one prerequisite that is easy to miss. You need git-lfs installed and accessible via the path, and the README says not to skip the step, because the compilers and interpreters are stored in GitHub large file storage. You also need the Flutter and Android development tools.

The first step builds an `aab` bundle:

cd android && ./gradlew :app:bundleRelease

The output lands in `build/app/outputs/bundle/release/app-release.aab`. The next step converts that bundle into an installable set, using the official bundletool releases:

java -jar path/to/bundletool.jar build-apks --bundle=your_app/build/app/outputs/bundle/release/app-release.aab --output=output.apks --mode=universal

and the last step installs it, with a device or emulator connected through `adb`:

java -jar /path/to/bundletool.jar install-apks --apks=output.apks

The reason for the extra work is size, and the documentation explains it. The standalone bundle includes all compilers, interpreters and extensions, so it is bigger than the APK from the Play Store, where those external dependencies are downloaded on demand when you request a particular compiler, interpreter or extension.

Two build models, and a branch named for the store build

The distribution split deserves a second look, because it is the main practical decision. The Play Store build is smaller and pulls its toolchain on demand, so the first install is quick and the storage cost tracks what you actually use. The self-built bundle is large because it carries everything, which is the right trade for a user on a metered connection or one who wants the toolchain guaranteed present.

Neither is a demonstration build. The README recommends the Play Store version for everyone else and calls it the full-featured APK, so the difference is packaging, not capability.

The default branch of the repository is `playstore-version`, which tells you which build the tip of the branch tracks, and the top-level entries include `README-CN.md` and `README-ES.md` alongside the English README, so the project is documented in Chinese and Spanish as well. There is a CODE_OF_CONDUCT.md and a LICENCE file, and the licence is MIT, which in practice means you can read the code, build it and redistribute it, with the notice retained.

Releases every few weeks, and a Rust backend still being tuned

The release cadence is brisk. The recent versions are 2.8.0 on 2026-10-18, 2.7.0 on 2026-09-20 and 2.6.0 on 2026-09-10, and the repository is not archived with the last push on 2026-10-18, the same day as the newest tag.

The changelog for 2.8.0 in the README is short and telling: fixes against issues 56, 53 and 52, a fix for a Zig compiler error, and one enhancement described as an optimized editor backend.

That single enhancement is the most informative line in the release notes. It says the Rust backend, the part that does the rope and sum tree work and is the reason the editor can handle large files on a phone, is still being tuned rather than being finished. A project at version 2.8 with that kind of changelog is a project in motion, and for a mobile editor that is understandable: the device you install it on is the device you have, and the performance work happens on real hardware rather than on a specification.

The practical consequence for anyone adopting it is that you should expect the app to keep changing, and that the version you read about today is not the version that will be on the Play Store next month.

Editorial conclusion

Roxum IDE fits an Android developer who wants to read and edit code on a phone or tablet, with a terminal, LSP and Git in the same app, and who is willing to deal with a large install and on-demand compiler downloads. It is the wrong choice if you need a stable, offline-capable toolchain on a device without patience for the first-run downloads, and the wrong choice if you want a full IDE rather than a focused editor. Verify first that the app source you install matches the version you read, and that the compilers you need are the ones the bundle or the on-demand download provides.

Frequently asked questions

Official sources

1. heckmon/roxum-ide on GitHub
2. Issues
3. License: MIT
4. README
5. Releases