What's the advantage of using the new Gradle Versions Catalog system vs. declaring all version values in the *application*-level gradle build file?

Question

For configuring Android apps builds, I'm looking at the new Gradle Versions Catalog system and trying to figure out why I would need to use it rather than simply declaring all version values in the single application-level gradle build file instead - where it can be seen by all modules. (Gradle VC seems to involve may more work to set up than using the app-level build file.)

Are there any additional features/benefits that the versions catalog system provides?

Answer 1

As you've discovered, if you're already stating all versions in a single, module-independent place then version catalogs are less of an improvement than those defining versions in multiple places.

However, there are still a few advantages:

1. Consistency. With many different ways to define versions, every app I've worked on ended up with a weird, custom solution. Version catalogs provide Google's recommendation on a single, consistent way of doing this.
2. IDE Support. Now there's a single recommended format, Android Studio (and other tools) can easily understand, check, update versions.
3. Plugin management. The [plugins] block helps make plugin management more in line with typical dependency management, instead of existing totally separately.
4. Type safety. Depending on how your dependencies are currently defined, version catalogs will likely provide better type safety, ensuring when you add a dependency it is what you expected it to be and not arbitrary data.

Having just migrated a large project that previously stored ~95% of the dependencies in a central dependencies.gradle, but had plenty of exceptions, the migration was a great "clean slate" moment.

In conclusion it's better than any other solution (since it's standardised and officially supported), but not by much (yet).