# You should use AndroidX betas

DevFeed: [You should use AndroidX betas](<https://devfeed.tech/articles/you-should-use-androidx-betas-20984.md>)

Original publisher: [Read original article](<https://jakewharton.com/you-should-use-androidx-betas/>)

Published: 2025-11-19T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Library](<https://devfeed.tech/topics/library.md>), [Compose](<https://devfeed.tech/topics/compose.md>), [releases](<https://devfeed.tech/topics/releases.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [compose](<https://devfeed.tech/tags/compose.md>), [features](<https://devfeed.tech/tags/features.md>), [library](<https://devfeed.tech/tags/library.md>), [releases](<https://devfeed.tech/tags/releases.md>)

## AI overview

The article explains that AndroidX uses stricter versioning than typical libraries: beta releases are API-stable and generally production-ready, while release candidates and even earlier builds are extensively tested. It argues that developers should consider using AndroidX betas to access fixes and features sooner, while recognizing that stable releases are spaced farther apart.

## Source excerpt

Did you know the versioning of AndroidX libraries and their stability guarantees are different from most libraries? Their betas and RCs are actually production-ready, and you should be using them! In a "normal" library, such as the ones I release, features are added and known bugs are fixed to produce a stable release which might be released as version 1.2.0. If any bugs are found in that release, they get fixed and put into a version 1.2.1. If new APIs are added, the next version becomes 1.3.0. This is basic semantic versioning. AndroidX does not do versioning this way. When a library has its features added and its known bugs fixed they promote that library to beta01. This artifact is now API stable! Don't believe me? This is documented in their guidelines. They also have tooling which validates that you cannot break APIs or even introduce new APIs once an artifact has reached beta. Thus, when AndroidX releases a 1.2.0-beta01 of some library, it is equivalent to a normal library releasing a 1.2.0. This is still semantic versioning, but it's a more strict subset that imposes restrictions on prerelease versions. Why do they do this? The motivations are simple: they want the stable versions to be extremely stable. That is to say, to have most of the bugs that would otherwise necessitate subsequent patch releases to be caught in the ramp-up to 1.2.0. Here's all those words in chart form: Normal library AndroidX library 1.2.0-RC 1.2.0-alpha01 1.2.0 1.2.0-beta01 1.2.1 1.2.0-beta02 (etc.) 1.2.2 1.2.0-rc01 (etc.) 1.2.0 (same bits as final RC) Wondering if anyone else uses these betas? All of Google's first-party apps ship against the code in AndroidX HEAD. Not only are they relying on these beta and RC versions, they build, test, and ship with the alpha versions and random commits in-between. By the time a library even reaches -beta01 it has already been widely tested and deployed. AndroidX is to Google's apps as what all of your util- and common- modules are to your app: