Imagine starting every project with all your tools set up and ready to go. Sounds like a dream, right? As an Android developer, I’ve always relied on pre-configured tools to quickly kick off projects and add features with ease. But when I ventured into Kotlin Multiplatform (KMP), the lack of ready-to-use tools slowed me down. Determined to improve my productivity, I decided to build my own plugin.

It wasn’t an easy journey, but it was worth it. Today, I’m sharing what I learned and which traps I fall into, so you can avoid the same mistakes.

This article focuses on JetBrains plugins, but similar principles apply to VS Code extensions. For more on that, check out the official VS Code website.

To Build a Plugin or Not To Build? Exploring the Alternatives

Building a plugin can be a long task. Trying it requires launching a separate instance of your IDE, which takes time. Luckily, JetBrains IDEs already come with several built-in tools that might meet your needs. Before jumping into plugin development, consider these alternatives:

• Live Templates: Think of these as code snippets triggered by a keyword. I use them all the time to speed up boilerplate coding on Android.
• File Templates: Similar to Live Templates but applied to entire files. Perfect for generating all the files needed for a new feature or screen. I often use them as well.
• Postfix Completion: These are like Live Templates but allow you to wrap your existing code in a template—for example, quickly wrapping a block in a try-catch.
• Structural Search and Replace Inspections: A supercharged version of search and replace, capable of automating complex replacements.
• IDE Scripting Console: Write lightweight scripts in JS, Kotlin, or Python to interact with IDE APIs. It’s like creating a mini-plugin without the overhead.
• Flora Plugin: Add actions, shortcuts, and tool windows using Kotlin and JavaScript. It’s a lightweight alternative to full plugins.
• LivePlugin: Similar to Flora but includes advanced features like custom intentions and uses Groovy or Kotlin.

Plugins, however, take things a step further by combining these features with project data access and IDE APIs for complex actions. External tools like the Compose Multiplatform Wizard can also help. But in my case, I needed the power and flexibility of a custom plugin.

Why a Plugin Can Supercharge Your Productivity

Plugins can transform your IDE into a toolset perfectly tailored to your workflow. Here are just a few things you can achieve:

• Actions: It’s quick actions accessible via context menus, you can bind keyboard shortcuts on it. For my plugin, this was the go-to solution.
• Intent Actions: Context-sensitive actions triggered based on your code.
• Tool Windows: Custom interfaces for displaying project-related information.
• Editor Inspection and Highlighting: Detect and fix errors or bad practices directly in the editor.
• Access to Project Data: From a plugin you can obviously analyze or transform project data programmatically.
• Version Control Integration: Leverage advanced features for version control systems.

By automating repetitive or complex tasks, plugins boost your productivity. For guidance on building plugins, check out the JetBrains plugin documentation.

Challenges Along the Way

Gradle Plugins vs. IntelliJ Plugins

A Gradle plugin configures your project, like the Android Gradle Plugin (AGP), and integrates into your build.gradle files. In contrast, an IntelliJ plugin enhances your IDE directly, like GitHub Copilot, and is installed through the JetBrains Marketplace. “Jetbrains plugin” will be a better naming because all IDEs that have access to this marketplace can use them.

Choosing Between 1.x and 2.x

When building a plugin, you have two frameworks to choose from:

• Gradle IntelliJ Plugin (1.x)
• IntelliJ Platform Gradle Plugin (2.x)

Version 1.x is no longer maintained, so I recommend 2.x. If you used a template before summer 2024, you’re likely on 1.x. Migrating to 2.x requires some updates to your Gradle files. Luckily, a Gradle Plugin make this task easy.

Be careful, the IntelliJ Plugin DevKit that help you build one is based on the 1.x version.

Fleet Plugin Limitations

Fleet, JetBrains’ IDE for KMP development, currently supports only theme plugins. Custom actions and tool windows are not yet available.

Compatibility Issues After IDE Updates

After an IDE update, my plugin’s actions disappeared. I had to update it for compatibility, which was caused by poorly defined version ranges. To avoid this, only define a minimum version. By doing this, you take the risk to bug the users IDE with your untested plugin

The Target Version Trap

Besides minimum and optional maximum version, you have to set a target IDE version. It’s used for get dependencies and debug your development.

Some target versions like androidStudio("2024.2.1") can cause unexpected issues. Here’s a workaround.

What I Learned

Building this plugin didn’t just improve my devX—it introduced me to tools like Flora, LivePlugin, and Structural Search and Replace, which will save me time on future projects. If you’re curious about my plugin, feel free to reach out!

Conclusion

Improving my devX has saved me countless hours on repetitive tasks. Small optimizations add up: shaving off five minutes a day adds up to nearly two workdays a year. It all started with identifying time sinks and finding ways to automate them.

It took me two full weeks to develop this plugin. Was it worth it ? simpler solutions could have sufficed in some cases. My advice? Weigh the cost and benefit of each improvement. Focus your energy where it makes the biggest impact. An optimized devX means more time for what really matters: delivering value through your code.

Resources

• My plugin: Kotlin Multiplatform Kuik
• Example of improving devX with Maestro: Unlocking New Possibilities with Maestro: Beyond Automated Testing

‍