Hello Firebase Developers!
Dependency management is probably one of your least favorite aspects when it comes to app development - whether that’s managing dependencies for an app that you’re building or for an open source project that you’re maintaining.
That’s why we’ve been working on improving dependency management and versioning for our Firebase iOS SDKs, and putting the spotlight on our Firebase BoM (“Bill of Materials”) for Android.
For both platforms, our goal is to make it easy to know which SDK versions to pick for the products you want to use without any muss or fuss, and move straight on to developing your app. There are few other really important motivating factors too.
Let’s get into the specifics for each platform.
Previously, each Firebase SDK for each product maintained its own version number - for both the SDK and the CocoaPod itself. Whenever an SDK got updated, both the SDK and CocoaPod version numbers would get updated too.
This approach was helpful in that each product could update independently more easily, but we’ve heard your feedback that it also had some drawbacks:
That’s why we’re moving to a unified versioning model for all our Firebase SDKs moving forward.
Every Firebase product will now use the same unified version number for its iOS SDK. At each release of a major or minor update, this version number will update for all iOS SDKs. That means that you can just select the same Firebase SDK version number across all Firebase products you want to use - they’ll be designed to be compatible with each other. For any patch releases, the affected product will be fully compatible with all other products at the same minor version. You can run `pod update` to install the latest patches for all products.
There are also a few more reasons why we think moving to this unified versioning model will help iOS developers in the long run.
We’ve been making more and more of our iOS SDKs open source, which has been great for community engagement, but contributing to them hasn’t always been easy.
In the previous model, whenever a product had a new release, a new individualized tag was created for that product. When it came to integrating multiple Firebase products together, these individualized tags made it difficult to figure out which product's tags matched with each other - both from the perspective of using Firebase to build an app, or to contribute to the open source libraries.
With the unified versioning model, you can directly map your Firebase SDK integrations to a single tag in GitHub for both CocoaPods and the Swift Package Manager. The new model also makes it easier for contributors to understand our release and versioning strategy, and make contributions going forward.
While our current release strategy still revolves around CocoaPods, the versioning system we’re now using closely mirrors the conventions used in the Swift Package Manager as well.
Getting ready for that versioning system was additional motivation to move to this model. In fact, the Swift Package Manager for Firebase is now in beta if you want to give it a try.
Over in the Android world, we’re leveraging Gradle’s support for Android BoMs (or “Bill of Materials”), which provides a way to manage the versions for all the libraries you use by specifying a single BoM version for your app.
Firebase has its own “Firebase Android BoM” which has been around for a while, but we’re putting it back into the spotlight as it’ll be the recommended way to manage your library dependencies going forward. When using the Firebase BoM, all you need to do is set a single Firebase Android version in your app - the BoM’s version - and the BoM will pull in the versions of the libraries mapped to that specific BoM.
When you use the Firebase BoM, you’ll still need to declare which Firebase libraries you want to use in your app, but you will no longer need to specify which versions of those libraries your app will require. Instead, just specify the BoM version you want to use, and the BoM will manage which library version to use. And all these versions will be cross-compatible with each other!
Here's an example build.gradle file that uses the BoM:
dependencies { // Import the Firebase BoM implementation platform('com.google.firebase:firebase-bom:25.11.0') // When using the BoM, don't specify versions for Firebase dependencies implementation 'com.google.firebase:firebase-analytics' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
If necessary, you can override the library version specified in the BoM by including the desired version in the library's dependency declaration. For example:
dependencies { implementation platform('com.google.firebase:firebase-bom:25.11.0') implementation 'com.google.firebase:firebase-analytics:17.5.0' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
The goal behind using the Firebase BoM, though, is to avoid needing to do this in your project. Each BoM version is curated to include library versions that all play well together.
The improvements mentioned above are a start to further improvements we plan to make in the near future - from better support for the Swift Package Manager, to providing easier getting started journeys in the Firebase Assistant plugin in Android Studio.
Please stay tuned for more, and as always, reach out to us on the GitHub issue trackers for the Firebase iOS SDK and the Firebase Android SDK to let us know what you think about these updates.
