DEV Community: Hendrik Haandrikman 🚀

Migrating to Google Play Billing Library 5

Hendrik Haandrikman 🚀 — Fri, 25 Nov 2022 16:06:47 +0000

At Google I/O 2022, the Google Play Team presented Google Play Billing Library 5.0 – the newest version of its in-app billing and subscriptions library.

In this post, we'll go through some of the main steps you need to take to migrate your Android app from Google Play Billing Library 4 to PBL5.

This is an excerpt of a post first published on the RevenueCat blog, where you'll find more information on Google Play Billing Library 5

Also, the cover image is what DALL·E makes of the prompt "A cat hugging the Google Play logo" 😅

Highlights of a Google Play Billing Library 4 to 5 migration

If you’re not using RevenueCat for Android in-app subscriptions, migrating from PBL4 to 5 involves multiple steps. We’ll share the highlights and most important changes you’ll need to make here, but you’ll find more details in Google’s integration guide, and billing specific samples on GitHub.

Creating a product catalog

Google recommends creating new products using the updated entity structure of Google Play Billing Library 5 before migrating your app. You can do this by consolidating the duplicate products that represent the same subscription benefits with different configurations of price, duration, etc.
This is the recommended first step as editing converted subscription products can result in issues with older versions of your app that still use PBL4 and deprecated methods like querySkuDetailsAsync().

Managing your catalog with the new API

If you manage your subscriptions automatically with the Developer API, there are three new endpoints to be aware of:

Monetization.subscriptions to manage subscription products
Monetization.subscrtipions.basePlans to manage base plans for your subscriptions
Monetization.subscrtipions.basePlans.offers to manage the offers associated with your base plans

For anything but one-time purchases, these new endpoints should be used via the Subscription Publishing API. Your one-time purchases will still be managed via the inappproducts API previously used for subscriptions as well.

Updating the Billing Library dependency

Created your new products? You can now migrate your app by updating your Play Billing Library dependency in your build.gradle file:

dependencies {
    def billingVersion = "5.1.0"

    implementation "com.android.billingclient:billing:$billingVersion"
}

Note that on October 31st of 2022, Google released the Google Play Billing Library 5.1, which – if you’re implementing PBL5 now – should be the version you’re using.

Showing available products

Because we’ve switched from SKUs to Products, the calls required to show eligible offers have changed:

Replace BillingClient.querySkyDetailsAsync() with BillingClient.queryProductDetailsAsync()
Replace SkuDetailsParams with QueryProductDetailsParams

Query results have gone from SkuDetails to ProductDetails, showing you information about the product (title, type, ID, etc), similar to before. New is List<ProductDetails.SubscriptionOfferDetails>, which contains the available offers for a specific user. Note that – unlike in PBL4 – you’ll be able to see several different offers for the same subscription period. In some cases, Google will handle eligibility, but in other cases, you’re able to define which offers show up in the paywall.

Important: If you’re showing a personalized offer as determined by Art. 6 (1) (ea) CRD of the Consumer Rights Directive (2011/83/EU) to a user in the EU, you’re required to disclose this via the Play UI. To do this, customize setIsOfferPersonalized() with true or false, depending on the offers shown to your user.

Launching the purchase flow

There are very few changes here, beyond going from SKUs to offers:

Use ProductDetailsParams instead of SkuDetails for BillingFlowParams
Use SubscriptionOfferDetails to get offer ID, base plan ID and other offer details

You’ll then pass the offerToken for a selected offer into the ProductDetailsParams object to purchase a product.

Processing purchases

This also largely remains the same, but you will need to pass a QueryPurchasesParams object with a BillingClient.ProductType value, instead of a BillingClient.SkuType value to queryPurchasesAsync().

Managing subscription status via the API

Your current subscription purchase status management backend component will be able to manage converted subscriptions pre-dating May 2022 as well as backward compatible offers, but will not support any of the new functionality introduced in Google Play Billing Library 5. To fully support the new subscription features, implement the new Subscription Purchases API (link), which will check purchase status and manage entitlements in your backend.

Replace calls to purchases.subscriptions.get with purchases.subscriptionsv2.get to access a new resource called SubscriptionPurchaseV2. There, you’ll find the necessary information to manage entitlements for subscriptions created in the new model.

Testing Android subscriptions for Google Play Billing Library 5

Before launching your app or submitting your app’s update, – as always – thoroughly test your subscriptions. The process to do so doesn’t differ from how you did it in PBL4, so simply follow the steps detailed in RevenueCat's ultimate guide to Android subscription testing.

Migrating to Billing Library 5, from Android Dev Summit ‘22

At this year’s Android Dev Summit, Diana García Ríos from Google’s Android team presented on the topic of PBL5 migrations. In this 16 minute video, she explains how to adopt Android and server integrations to take advantage of these new capabilities, and cust maintenance load by designing your subscription system for PBL5 from the bottom up:

Want to save yourself some pain?

RevenueCat was built to help developers manage the complexity of offering subscriptions across their mobile applications and web. Read more on our support for Android in-app subscriptions here, or sign up and start building

What expert iOS devs expect from WWDC21

Hendrik Haandrikman 🚀 — Fri, 04 Jun 2021 16:39:16 +0000

"Dub Dub" is just around the corner, so that means that every iOS developer out there is filled with equal parts excitement about the shiny new things being announced, and dread about the many ways in which those shiny things will break their apps.

Wondering what expert iOS devs wish for, fear, and expect from this year's Apple Developer Conference? We asked:

WWDC 2021 Wishes, Fears, and Expectations

Vincent Pradeilles, iOS developer and YouTuber extraordinaire, spent the last couple of weeks talking to some great folks from the iOS community to ask them about their expectations, fears and wishes for this year's WWDC.

In a series of interviews, he spoke to Kaya Thomas, Donny Wals, Anastasiia Voitova, Antoine van der Lee, Ellen Shapiro, and Carola Nitz to hear their thoughts.

Vincent Pradeille's perspective

Kaya Thomas' perspective

Donny Wals' perspective

Anastasiia Voitova's perspective

Antoine van der Lee's perspective

Ellen Shapiro's perspective

Carola Nitz's perspective

Join the post-WWDC conversation

To see just how wrong/right everyone was, join them in a post-WWDC live discussion hosted by Bitrise:

Date: June 17th, Thursday
Time: 9 AM PDT / 6 PM CEST

Guests: Paul Hudson, Ellen Shapiro, Vincent Pradeilles, Anastasiia Voitova, Donny Wals, you

Reserve your seat here (if you're not able to make it, we'll send you the recording after the stream has ended)

Xcode matters - These are the CICD services where you'll find it first

Hendrik Haandrikman 🚀 — Tue, 01 Jun 2021 17:54:12 +0000

Xcode versions are the drumbeat that iOS teams all around the world march to. Rapid access to Xcode versions ensure that apps are submitted, and updated on time, while Xcode betas help prepare for new features, functionality, and – dreaded – deprecations.

With WWDC 2021 around the corner, enticing teams with the shiny new things the Apple folks thought up for us, this topic is more relevant than ever.

The research method

Over a 12 month period, a sample of Xcode GMs, RCs and betas was generated based on data aggregated by https://xcodereleases.com/ - For this sample of 15 Xcode releases, we pulled in publicly available information on Xcode releases on Bitrise, GitHub Actions, CircleCI, and Travis.

Whenever a particular Xcode version was skipped by a CI provider, the next version was used instead to determine availability.

The data

The following table shows the tracked releases, and their availability on the different platforms:

To ensure we're comparing apples to apples, the dates listed are based on CET

Speed of Xcode availability on Bitrise

Over the last 12 months, on average, it took 3.4 days to have a new Xcode version available for developers on Bitrise. This includes GM’s and betas.

Even though this 3.4 day average puts Bitrise ahead 3 days ahead of its second fastest competitor, it falls short of their aim to have new Xcode versions available within 48 hours. Mostly, this is due to a stretch of slower releases in Q4 2020, and Q1 2021 resulting from increased focus an ongoing infrastructure improvement. Regardless, they have expressed a renewed commitment to hit <48 hours availability, where possible.

Bitrise Xcode updates based on stack update notices posted to their Discourse space here

Xcode support on CircleCI

New Xcode versions are usually available on CircleCI within a one week window, but their average time to availability came in at 7.2 days – a little over a week. This is mostly caused by some slip-ups related to a number of Xcode beta versions that took several weeks to make it onto CircleCI’s macOS stacks.

Note that, at time of writing, no Xcode 12.5 beta or GM is available on CircleCI’s macOS stacks, so we’ve left this latest version out of our calculations.

CircleCI Xcode updates based on stack update notices posted to their Discourse space here

Xcode support on GitHub Actions

New Xcode versions are generally available on GitHub Actions a little over a week after launch, but their average time to availability came in at 6.5 days – a little under a week. Their average got pulled up by a handful of versions that were supported in 2 or 3 days. Like most CI’s, they also managed to support the Xcode 11.5 GM in a day.

Note that, at time of writing, the Xcode 12.5 beta made available briefly on GitHub Actions is now only available as a “private preview”. There, it can be accessed to those organizations that used GHA’s macOS 11.0 image while it was in public preview mode.

GitHub Actions Xcode updates based on the commit history for their MacOS 10.15 virtual environments doc here and their MacOS 10.14 doc here

Xcode support on Travis CI

New Xcode support on Travis CI seems erratic, with some versions being supported very quickly (looking at you, Xcode 12.2 Beta 1), but their average time to availability came in at 12.6 days – close to two weeks, and slower than anyone else benchmarked in this article. Time to availability regularly ran over a week, and 12.4 took a full month to support.

Note that Travis CI is one of the few cloud CICD platforms that currently offers Xcode 12.5 builds, but they seem to have skipped the betas and took a little over 2 weeks to make the RC available.

Travis CI Xcode updates based on stack update notices posted to their changelog here

Xcode support on App Center

Even though there are still quite a few mobile teams building there today, we’ve not included App Center Xcode updates in this roundup: For the entirety of the measured period, App Center macOS builds ran on GitHub Action macOS images. Their performance can therefore be assessed as being identical to what we’ve recorded for GHA.

Xcode support on Jenkins

🤷‍♀️ probably captures the sentiment here best: On Jenkins, you or someone on your team will be responsible for ensuring new Xcode versions are available.

How long that’ll take is dependent on a number of factors, including the priorities of the team, or the stability of your Jenkins environment: If it’s already kept together by luck, positive thoughts and firefighting, those engineers responsible for maintaining it will often be hesitant to rush out an Xcode update… However eager mobile developers might be to get their hands on it.

Turns out, there's life after Jenkins and it's GREAT

Hendrik Haandrikman 🚀 — Mon, 15 Mar 2021 20:51:47 +0000

This article contains research findings from Bitrise's report Mobile CI after Jenkins - 6 lessons learned. If you're not interested in my stories about uncle Jenkins, manga and struggles with stacks of Macs, just skip ahead a few sections, and I'll share data on how the folks that used to be responsible for Jenkins feel their jobs changed.

Uncle Jenkins

Did you know that in Japan, devs will often refer to Jenkins as 'Jenkins ojisan', or 'Uncle Jenkins'? 🇯🇵 When I first started working at Bitrise and Google Translated Japanese Tweets, that confused me tremendously. Fast forward a couple of years, and we actually hired a manga artist to tell the story of devs struggling with their Jenkins boxes:

Bitrise JPN

@bitrisej

#新プロジェクト待ちに待ったその答えは、、、
Bitriseユーザーの生の声を4コママンガにしてお届けいたします！
その名も #マンガでBitrise 🤖🐱

今回の作品は、@fromkk さんの体験談を基に作成しました。
マンガのデザイナーには、 @net_the_mario さんにご協力いただきます！
次回作もお楽しみに！

23:00 PM - 19 Aug 2020

But I digress.

Jenkins is free.... ? 🎉

We all know Jenkins. It's estimated to be what over 70% of devs use for their CI, and for good reason:

It's free
It's flexible
It's open source

But that flexibility comes at a price. It's devilishly difficult to master for beginners, and - as detailed in the Nextdoor Engineering Blog recently - has its limitations when you try and use it at scale for mobile engineering:

Maintenance is a constant struggle, with the necessary hardware to build for iOS as an (expensive) bonus
There's a lack of isolation between builds, which means that - for example - the cache from an old build can cause a new build to fail (have fun troubleshooting that one 😓)
There's a limit to the speed at which you can spin up physical machines if your needs increase, and probably a finance department that wants to know why trucks filled with Macs keep pulling up

Oh, and on Jenkins being "free", Moataz Nabil (Senior Software Engineer at Delivery Hero) had the following to say:

"While Jenkins - technically - is free, the cost of hosting the server on which it will run can not be easily calculated. It's not always possible to estimate the kind of load the server needs to handle, or the amount of compute power you'll need from hardware stacked in the office. The total cost associated remains unpredictable."

TLDR: It's free, if you ignore the fact that you're spending a ton of time on it, and also need hardware to run it on. Unless that's fallen off of a truck by the docks, Jenkins is probably not 'free'

Let's migrate! But... What do we do with our Jenkins folks?

For these and a number of other reasons that could make up an entirely separate article, cloud-based alternatives like CircleCI, Travis and - yes - Bitrise have been edging out the traditional "Jenkins box" in most mobile engineering organisations.

That's usually great for those organisations (more on that later), but what about the folks that were responsible for maintaining Jenkins?

Are they out of a job? Demoted to getting coffee and bagels for the team? What does their day to day look like after we've said our goodbyes to uncle Jenkins?

We decided to find out, by asking.

The report

Over January and February of 2021, our UX research team, developer advocates, and a number of other folks surveyed and interviewed hundreds of ex-Jenkins maintainers who had switched to cloud CI for mobile.

Our goal was to find out exactly what had changed for these people, and - more then anything - figure out how they felt about the change.

What follows are some of the main takeaways:

Computer says... Engineers are happier!

(the computer actually said 'yes', but there's no GIF for that...)

73.9% of those interviewed answered that they were happier with their jobs after moving from Jenkins to a cloud CI alternative. Half of those even reported being much happier, a mental state that - according to Google - usually requires 7 minutes of exercise, more sleep, meditation and / or cake.

We found a lot of reasons for that increased happiness in answers throughout the survey and interviews, but found 3 big themes:

The people responsible for Jenkins have usually worked (very) hard at gathering the necessary knowledge to support their teams, but feel like the constant firefighting leaves them with no time to spend on meaningful improvements to the team's CI / CD setup
ex-Jenkins maintainers spend more time on building and improving workflows after switching to cloud CI, but see way more results in team performance for that time spent (a whopping 90% reports that their teams are faster and more productive after migrating)
Turns out that - in most cases - those years 'learning Jenkins' won't go to waste:

Hiring: A Jenkins Expert to manage our Bitrise / CircleCI / Travis setup

Even though a little under 14% of those we talked to thought their Jenkins expertise made it more difficult to find their way around cloud CI, the majority disagreed. Almost 60% were able to use their Jenkins expertise to get started with cloud CI quicker. 34.1% even thought their time on Jenkins gave them a significant edge, and were able to see results sooner, and make a bigger difference in their team's performance.

Bonus fun fact:

Everyone saw that they were gaining a lot of time to spend on things other than fixing broken workflows on Jenkins. Only 8.7% of the folks we talked to spent that time on 'rest and relaxation', tho. The rest of them opted for things like creating new features, building and improving automation, and a range of - arguably more productive - efforts.

In conclusion

Jenkins is fine, the people that are responsible for Jenkins in their organisations are usually great, and when you give them cloud CI plug like Bitrise /plug to play with, they're amazing.

Download the full report if you're interested in our other findings, and contributions from folks with impressive titles at cool companies. Stuff like WeTransfer, Nextdoor, Signify (the folks of the Hue lightbulbs!), and more. You get the picture 😉