Migrating an Android Project from Groovy DSL to Kotlin DSL

Learn the differences between Groovy and Kotlin DSLs, how Kotlin can benefit you, and what you need to know before migrating your Android project’s build files.

3 min
May 5, 2023
Scott Peterson
Mobile Developer

A Domain-Specific Language (DSL) is a language tailor-made for a specific purpose. Instead of being a jack-of-all-trades, a DSL is a master-of-one, designed to fit the needs of a particular domain or industry. It’s a language that speaks _your_ language.

As of April 2023, Google announced that Kotlin DSL has become the default language for build scripts. The key is unifying all aspects of Android development with the Kotlin language.

## What are some differences?

Groovy strings are single quoted while Kotlin strings are double quoted.

In Groovy you can omit parentheses. Kotlin requires them.

In Groovy you can omit the equals sign in a lot of places.

Kotlin DSL is type-safe--you'll know if you have errors at compile time instead of runtime.

### My thoughts

In my opinion, Kotlin files are more readable. There's less whitespace in the middle of code. Explicit assignments using the equals sign are more familiar to the developer.

### Let’s look at some code examples!

`versionName '1.0'` is less readable than `versionName = "1.0"`

   -- CODE line-numbers language-kotlin --


     plugins {

       id ''



is less readable than

   -- CODE line-numbers language-kotlin --


     plugins {




## How do I migrate?

Gradle Documentation

Android Developer Documentation

## How to manage dependencies?

This will be far from exhaustive!

In the Groovy world, one convention was to put all dependency version numbers and library string references in the project-level `build.gradle` file.

   -- CODE line-numbers language- --


     buildscript {

       ext.versions = [

         'dagger': '2.44.2'



       ext.deps = [

         'dagger': "${versions.dagger}"





and then in module build.gradle files you can reference the dependency:

   -- CODE line-numbers language- --


     api deps.dagger



### Version Catalogs

In the Kotlin world a common pattern is to use a `libs.versions.toml` file.

Gradle Documentation

Android Developer Documentation

When you need to use a dependency you can reference it via:


One bit of "magic" is that if a library key string in your `libs.versions.toml` is named `lifecycle-runtime-ktx` it is referenced with periods replacing the dashes


I am not a fan of such magic.

When writing string keys the developer is often left to decide if they prefer camelCase, PascalCase, snake_case, or other.

In this scenario, you don’t know the implications of using dashes (or not) until you need to access the key value (AND, after a compilation to boot!). I’d rather the key be accessed exactly as it’s written by the developer.

### Bill of Materials

Another great tool for managing dependencies is utilizing Bill of Materials (BOMs), whether it's the Compose BOM that is built for us, or a BOM we create.

### 3rd Party Plugin

The Autonomous Apps Dependency Analysis Plugin is another heavily utilized tool for managing dependencies.

## Summary

Any differences in ease of learning, writing, reading, and using Groovy DSL compared to Kotlin DSL are negligible. Groovy _feels_ like a spoken and written language, while Kotlin _feels_ like a programming language. This might flatten the initial learning curve to learning Groovy, but needs too much _magic_ during compilation.

The value of developers using Kotlin EVERYWHERE when writing an Android app is large (e.g. Kotlin for views instead of XML, Kotlin for build files instead of Groovy, Kotlin for business logic instead of Java).

Kotlin starts to inch ahead and then run ahead when considering tooling, support, type-safety, and interoperability.

Migration **may not be helpful** if you have a giant legacy codebase of Groovy DSL Gradle build scripts.

**If starting a codebase from scratch**, Kotlin DSL should be the easy choice for your Gradle build files.

Actionable UX audit kit

  • Guide with Checklist
  • UX Audit Template for Figma
  • UX Audit Report Template for Figma
  • Walkthrough Video
By filling out this form you agree to receive our super helpful design newsletter and announcements from the Headway design crew.

Create better products in just 10 minutes per week

Learn how to launch and grow products less chaos.

See what our crew shares inside our private slack channels to stay on top of industry trends.

By filling out this form you agree to receive a super helpful weekly newsletter and announcements from the Headway crew.