Visual Code Space: a Kotlin code editor that runs entirely on an Android phone

An editor for a phone, built on a real editor core

Visual Code Space is described as a code editor built specifically for Android devices, so you can code on the go. The homepage is a .com.br address, the project is written in Kotlin, and the topic tags include jetpack-compose, mobile-ide and code-editor.

What separates it from a text editor with a file picker is the list of dependencies in the special thanks section, because they tell you which parts are genuinely difficult and which parts were borrowed from elsewhere.

The editor core is sora-editor by Rosemoe, which is the code and text editor component that powers several Android editors. The syntax highlighting definitions are the TextMate files from VSCode, contributed by Microsoft. The terminal emulator is the Termux application. And the inspiration credit goes to Akash Yadav for AndroidIDE, the long running Android IDE project.

So the architecture is a Kotlin and Jetpack Compose application wrapping an existing editor core, existing syntax definitions and an existing terminal, with the parts specific to this project being the file explorer, the tabbed interface, the plugin layer and the Android integration.

That is the honest picture of what you are installing. You are not getting a from-scratch editor; you are getting a well-assembled Android application around components that are themselves maintained elsewhere. The project topics also list ai and ai-code-generator, and collaborate, which the readme itself does not describe in any detail, so treat those as aspirations rather than documented features.

The feature list, and the one line that says plugins are BeanShell

The key features section is short and each entry names a concrete capability.

The file explorer is described as blazing fast, for navigating your project directories. There is multi-language syntax highlighting for a wide array of programming languages, making your code more readable and less error-prone. The tabbed editor lets you manage multiple files simultaneously. There is an integrated terminal emulator to execute commands directly within the app. And the experience is ad-free, so you can focus on your code without distractions.

Then there is the plugin support, and this is where the readme contains a contradiction you need to resolve before you write a plugin. The feature list says plugins extend the functionality of Visual Code Space with custom plugins written in BeanShell. The plugin development section, headed with the line about unleashing the power of customization, says the project supports custom plugins written in Java, and points at the Basic Plugin documentation at docs/plugins/basic-docs.md for detailed instructions and examples.

Two different languages are named for the same extension point. One of them is a reasonable reading: BeanShell is a Java-like scripting language, so a plugin system that lets you drop a script into the editor and run it is plausibly scripted, while a plugin system that compiles against a typed interface is plausibly Java. But the readme does not resolve it, and the documentation file it points to is where the answer is. If you intend to write plugins, read docs/plugins/basic-docs.md first and confirm which language the released build actually loads.

The repository tree supports the composition story. There is an app module, a core module, a feature directory, a docs directory, build.gradle.kts and settings.gradle.kts, a gradle wrapper with gradlew and gradlew.bat, a .clang-format file and a .idea directory, plus renovate.json for dependency updates and a RELEASE_NOTES.md.

Installing it, and the distribution path is an APK

There is no package manager step, because there is no package. The installation is a download.

Download the latest version of Visual Code Space from the releases page, or from the Telegram group the readme links. Both routes are given, and the Telegram group being a primary channel tells you something about how the project distributes.

That is the practical consequence of not being in the Play Store, and it has real effects. The user has to allow installation from an unknown source, the update path is manual, and there is no store listing to check for the version you are about to install. The releases on GitHub are the reference, and the recent ones are v2.0.1 from 2025-02-28 and v2.0.0, Visual Code Space (VCSpace), from 2024-12-15.

The naming in the release titles is worth noting because it tells you the project was renamed at some point. The older release is branded VCSpace and the newer one uses the full Visual Code Space name, and the topic tags still carry vcspace alongside visual-code-space.

The continuous integration badge points at a workflow named androidci.yml, so the Android build is what gets verified on every change. The repository is not archived and the last push was on 2026-10-15, so the code is being worked on well after the v2.0.1 release, which means a build from the main branch is not the same thing as the latest published APK.

What the terminal and the borrowed pieces actually give you

Since much of the editor is composed from other projects, it is worth being precise about what the composition delivers.

The TextMate files from VSCode are the syntax definitions, and that single decision is what gives the editor broad language coverage without the project writing a grammar for every language. It is the same approach desktop editors take, and it means the highlighting quality on a given language depends on whether a mature TextMate grammar exists for it.

The Termux terminal emulator is a different kind of contribution, because a terminal on Android is not a trivial feature. The AndroidIDE project that inspired this one is built around the same idea, and the terminal is what turns the app from a viewer into a place where you can actually run a build. The practical questions to ask are the ones the readme does not answer: which shell is bundled, whether packages can be installed into it, and how the termux environment is provisioned on a fresh install.

The sora-editor core is what makes the editing experience itself credible, with a document model, syntax highlighting rendering and the input handling that a real editor needs, which is the part most home grown mobile editors get wrong.

So the app is an integration project, and that cuts both ways. You get real components instead of approximations, and you inherit their constraints: the terminal behaves as the Termux app behaves, the highlighting covers the languages with TextMate grammars, and the editor behaves as sora-editor behaves. When something does not work, the question of which layer to look at is a real one, and the README does not say.

Where an Android editor is the wrong tool

There are several cases where this is the wrong choice, and the honest framing starts with what the project is not claiming to be.

The first is a full IDE. There is no build system integration, no refactoring, no debugger, no language server, and no project model beyond a file tree. The readme describes a code editor, and the feature list is a file explorer, highlighting, tabs and a terminal. If you want an IDE on Android, this is not it, and the inspired-by credit to AndroidIDE suggests that project is the closer comparison.

The second is distribution risk. Installing an APK from a GitHub release page or a Telegram group means the user is responsible for where the binary came from, and there is no store review in the path. For a code editor that runs commands on your device, that is a real consideration, and it is the price of not being in the Play Store.

The third is the version gap. The last tagged release is v2.0.1 from 2025-02-28, and the last push is from 2026-10-15, so the published APK trails the source by a long way. If you pick up the latest release you are picking up code from around early 2025.

The fourth is the plugin contract. Two languages are named for the same extension point in one document, and the plugin documentation is a single file in the docs directory. Whatever the answer turns out to be, a one-file plugin guide suggests a young extension API.

The fifth is device fit. An editor with a terminal on a phone is a real workflow for a specific person, editing on the go. It is not a replacement for a laptop, and the keyboard is still the limiting factor no matter how good the editor is.

Against a desktop editor over SSH, and against AndroidIDE

Two comparisons make the choice clearer.

The first is against SSH from a phone into a remote machine. The difference in approach is where the files live. With SSH, the machine that runs the editor is not your phone, and the code, the toolchain and the compiler are all on the server, which is where a real development environment usually is. With Visual Code Space, the code is on the device, the terminal is on the device, and the toolchain has to be installed on Android, which is possible for some languages and awkward for others.

The trade is convenience against capability. An SSH client gives you the full power of the server with the inconvenience of a terminal and a small screen. This app gives you a real editor on the device with the inconvenience of a phone keyboard and whatever your Android device can compile.

The second comparison is against AndroidIDE, the project the readme credits as its inspiration. The readme does not describe the differences, and it should not be assumed that this is a fork or a successor, since the credit is framed as inspiration rather than derivation. What can be said from the readme is that they share a problem domain and a technical tradition, the terminal in particular, and that AndroidIDE is the one with a longer history in the space.

So the decision is whether you want an editor that treats the phone as a first class development machine, with the built-in terminal as the centrepiece, or an editor that treats the phone as a thin client for a machine elsewhere. Visual Code Space is clearly the first, and the plugin system and the terminal are where that bet shows.

The GPL-3.0 notice, and what it means for a fork

The licence is GPL-3.0, and the readme states it in full rather than linking to the text. The notice is reproduced in the repository, and the first part of it reads:

Visual Code Space is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

The interesting part for a user is the last sentence of the notice, which says the software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, and that a copy of the licence should have come with it. Any violations of the licence can be reported either by opening an issue or by writing a mail to the maintainers directly.

The GPL-3.0 choice is the normal one for a community Android application, and it matters for anyone who wants to modify it and ship the result, because the copyleft obligations follow the derivative work.

Editorial conclusion

Adopt Visual Code Space if you edit code on an Android device and want a real editor with a terminal on the same machine, and you are willing to install an APK from the releases page or a Telegram group rather than a store. Skip it if you need a stable, store-distributed, formally supported toolchain, because the last tagged release is v2.0.1 from 2025-02-28 while the last push was on 2026-10-15. Verify first which plugin language the version you install expects, since the readme names BeanShell in the feature list and Java in the plugin documentation, and check that your Android version and device can run the terminal component you depend on.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Visual-Code-Space/Visual-Code-Space on GitHub