Our flexible install model supports the widest range of users and devices
Code On the Go (CoGo™) shipped Version 1 on April 28, 2026 as a 1 GB Android package. Because we want to support global developers on the widest range of Android devices, that’s just too big, especially for people who pay for data by the byte or whose devices don’t have room for an APK that size.
Creating a professional-strength IDE with the smallest possible footprint is a challenge. Our answer is fractionalization: splitting CoGo into a smaller core product and a large set of independently installable plugins, so anyone can download only what they need.
We want developers to be able to choose only the plugins they need for the device they have, but also know that being presented with too many choices can create additional problems. This article lays out our plans and explains the decisions so you can understand why we’re making the changes and have the opportunity to provide early feedback to us.
The APK footprint challenge
A full development environment with a code editor, compiler toolchain, debugger, UI design tools, and libraries has a big footprint. On a laptop with 500 GB of free space, that isn’t a problem, but on a phone with less than 8 GB of free space, the size of the APK and installed app matters a great deal. The easy option of shipping a single fixed bundle with everything included shuts out users with the most limited storage.
The other option is to make every feature optional and let people build their own setup from scratch. The problem is the sheer number of decisions you have to make to tailor the IDE to your needs. In practice, too much flexibility can result in decision fatigue: presenting too many choices can lead to poor decisions or no decisions at all.
Fracturing the monolith: The plugin solution
We’re in the process of splitting CoGo into a core and a set of plugins. You’ll choose what you want and download only what you need.
The first piece we pulled out was the Android Native Development Kit (200 MB), which immediately cut our footprint by 20 percent. The next plugin conversion was Sketch to UI™. As cool as we think this feature is, it’s not essential for developing Android apps.
The next target is the large documentation database. Because we’re committed to supporting offline users, we provide CoGo help as well as local copies of crucial developer information (e.g., the Java® Platform, Standard Edition & Java Developer Kit Specification. We also provide PDFs additional reference materials like textbooks. We’ve pulled all of the PDFs out of the primary documentation database and moved them to the Bookshelf plugin, so they won’t consume storage space unless you expressly ask for them.
The AI experiment is also moving from the core into a plugin. This reduces the core footprint and lets contributors add their own ideas for AI integration.
We may also move Kotlin support into a plugin, which would save around 120 MB. We’re also considering pulling Android and Java support out of the core IDE. CoGo now supports Python, and there may be use for a lightweight Python-only version where Android and Java aren’t needed. If we pull out Kotlin, Android, and Java, the core app would be around 40 MB.
What we learned from Eclipse and Android Studio
As we began exploring fractionalization, we looked at other IDEs’ approach to the issue. Many feel that the Eclipse IDE is a case study in what can happen when you create too many plugins without providing guidance about interoperability. With over 1,600 plugins and no dependency resolution, there’s no reliable way for a new user to know which combination would actually work.
A 2026 analysis by Toolradar put it plainly: “Eclipse’s plugin system lacks dependency resolution, conflicts manifest as cryptic errors or silent failures” and “the real cost is time—Eclipse requires more setup, more plugins, more configuration to reach the same functionality IntelliJ provides out of the box.” Eclipse lost market share while competitor IntelliJ IDEA grew by offering a curated working environment from the start.
Android Studio’s SDK Manager takes a different approach, sorting components into clear categories and automatically flagging missing dependencies before you hit an error.
Those two examples directly shaped how CoGo handles plugin selection. We’re not trying to recreate Eclipse’s open bazaar, and we’re not trying to lock everything down. The goal is a standard install that works for most developers out of the box and a clear path for developers who want or need greater customization. Here’s our vision.
For most CoGo users, the standard install includes everything needed for a full Android development workflow: the core editor, the Android SDK, the on-device debugger, Jetpack Compose support, the layout editor, and Git integration. These are built into the standard core product so you have a working environment as soon as you open the app.
Developers who want a smaller footprint can use a second install path that exposes the full component list. Anything in the essential category shows a plain-language warning about what you’ll lose if you remove it.
Where things stand
Our current version of CoGo has a footprint under 1 GB. Builds are faster because a smaller core compiles faster than a monolith, and a single plugin faster still. We’re developing new plugins regularly, and two community members have contributed their own plugins to extend CoGo.
If you think we’re splitting something in the wrong place or if you have strong views about which plugins should or shouldn’t be part of the standard install, tell us! We need your feedback to improve our system. And if you want to build a plugin of your own, we’d like to hear about that too. Happy coding!