The new reality in the Android ecosystem and the impact on our apps
Last week, Huawei invited us to their first Developer Day in London. An event where they showcased the newest version of the Huawei Mobile Services (HMS) platform, an extensive set of tools and SDKs they offer as an alternative to the Google Play/Mobile Services. Huawei claims that the integration of their SDKs is a low effort operation, but is this really the case?
Let’s say that my experience as a software architect on multiple big projects has made me very careful with such statements. A good integration is more than implementing some lines of code, it’s making sure that all your users (including the team behind the app) have the best possible experience in their touch points with their platform.
But first things first, what’s HMS?
In short, it’s a replacement of the Google Mobile Services (GMS). In May 2019, Google announced that it would ban Huawei from its GMS platform because of geo-political reasons. Huawei can still use the Android OS (which is open source), but can’t install applications like Google Maps or the Google Play store on their new devices. This also affects underlying libraries of those Google services, think of things like push messages, geofencing, Chromecast support, in-app purchases, … If you’re using any of those, you’ll need to implement the service that HMS offers as a replacement to make sure that your app will keep on working on new Huawei phones.
The Huawei Mate 30 Pro will be the first phone launching without this pack of Google services. Existing models won’t be affected and will still have the Google apps installed, but will receive additional support for HMS in updates later on.
Integrating the services
In your application
So what if you decide to jump on the HMS train? Huawei claims that it shouldn’t cost you a lot of effort to implement the SDKs, and that’s no coincidence: today, HMS looks a lot like GMS. The APIs are almost always an exact copy of how Google handles the same functionality. So if your application is well architected, creating a second flavor of the app with the Huawei services should be a piece of cake. And I guess this is the point Huawei is focussing on when making its claims about 3 days lead time.

In your DevOps pipeline
But things start to get a little more complicated when you look at your software development lifecycle. Crafting apps is more than writing code, it’s making sure that you have a solid pipeline to release your application to the store. The quality should be thoroughly checked, and more features means more variables to validate. Even if the HMS layer doesn’t add new visible features to your application, you will now have a hybrid app with 2 implementations (HMS or GMS) of the same feature instead of one, so there is extra complexity and thus more QA effort. Let me also give you this reality check: it’s software, so there will be bugs, and don’t expect them to be the same on both platforms.
You will have to adapt your workflow to add this additional delivery channel. Some of the work will be a one-off job, but some continuous effort will remain. Oh and don’t forget this fun fact: Huawei added a review process to get your app in the Huawei App Gallery. App rejection on Android, it’s a thing now.
In your roadmap
Let’s say you have implemented all equivalent services of HMS and your app is now up and running in the Huawei App Gallery, we’re done here, aren’t we?
I’m afraid not. The vision of Huawei is clear: they will keep on improving the HMS services, which is a good thing of course. But the reality is that you now have 2 service providers that start from the same point, but will eventually diverge. The effort that Huawei did in the past months is huge, they won’t stop here, and neither will Google. So you can expect both parties to bring out new features which are exclusive for their platform, or maybe with just way better results than the competing services.

So yeah, you start from the same point for both services, and as a developer you will now think: “I’ll write an abstraction layer for this”. But it wouldn’t surprise me if it could become really difficult to keep this abstraction for some parts of the services.
You could say that you choose to go for the 100% Huawei way, because when I asked, they told me that all their services will work on every Android phone (but probably better on Huawei ones?). But is this really the way to go? Certainly at this point in time? What if Samsung or another powerful brand launches their own version of mobile services? In my opinion, if you choose to do it, you should be ready to handle a third or even a fourth mobile services provider. Or, maybe more future proof, you can go for tooling that is store agnostic.
.avif)




.png)
.avif)