Another year comes to an end, so it’s time to look back and reflect on what had happened in the native Android development ecosystem during this time.

Last Year’s Predictions

As usual, let me start by reviewing my predictions from 2021 to see how they fared.

It was ruled by the Supreme Court of the United States (SCOTUS) that Google’s incorporation of Java APIs into Android had constituted so-called “fair use” […] Consequently, the motivation for Google’s “secret” next-generation operating system, Fuchsia, becomes very questionable, as there is no need to replace Android. Furthermore, since Flutter framework is Fuchsia’s “native” development toolkit, I suspect that the long-term prospects of Flutter also became unclear following this decision.

I haven’t heard much about Fuchsia this year, so it looks like Google indeed aren’t rushing to unleash it onto the world. As for Flutter, I solidified my opinion about it and will share it with you later in this article.

All in all, in terms of productivity, stability and maintenance, I wouldn’t recommend adopting Jetpack Compose for at least another 6 months.

I still recommend waiting with Jetpack Compose adoption, except for very special use cases.

[…] after Google won in the Supreme Court, I’m really not sure whether they have any incentive to invest into Kotlin multiplatfrom going forward. Especially in light of the fact that they already have in-house multiplatform framework, Flutter. So, why would they want to compete with their own product and share the control over the ecosystem with JetBrains? Doesn’t make much sense now, but only time will tell.

Except for releasing an experimental support for KMP in several simplest Jetpack libraries, I don’t remember Google announcing anything in this context this year. Definitely feels like they lost interest in KMP.

Material You […] All in all, while adaptive color scheme might make sense for system apps, I won’t invest even one minute to learn about this feature of Material You.

From my point of view, Material You simply doesn’t exist. Frankly, I don’t even know what it does in general. That said, I wonder what proportion of developers implemented this approach and whether their projects got any benefit from it.

In the past, I expected Coroutines to grow in popularity until it becomes the primary tool used for concurrency in Kotlin code. That was the reasonable expectation, given Coroutines framework is the official concurrency framework for Kotlin, and both Google and JetBrains invest so much into its marketing. However, my general sense is that many developers today aren’t eager to learn and adopt Coroutines at all.

Yep, Coroutines adoption indeed platooed. Very interesting trend.

So, even though it looks like too much investment and ego went into ViewModel to deprecate it, Jetpack Compose will set us free.

I don’t use Jetpack Compose myself and don’t know many developers who do, so I’ll need your help evaluating this prediction. Do you use ViewModel with Compose?

All in all, last year’s analysis and predictions turned out to be pretty accurate.

Jetpack Compose

In my opinion, 2022 was the year of Jetpack Compose in Android development. From community-generated content, to Google’s concentrated engineering and PR efforts – Jetpack Compose dominated on all fronts.

Last year I was hesitant adopting Jetpack Compose because it looked too immature. This year, despite all the work that went into this new UI framework and the associated tooling, I’m still hesitant, due to the same reason. Surprisingly, even though, usually, my opinions about new tech aren’t very popular (to say the least), there seems to be much more hesitancy towards Compose among experienced Android developers than what I’d expect to see. It’s a sign of community maturity, in my opinion.

Don’t get me wrong, though. I’m sure that, eventually, the majority of Android developers will be using Compose. Just like we use Kotlin today. However, the timing of adoption is still a very important decision with major potential consequences. So, developers resisting the hype can spare their projects a lot of unneeded overhead, which is especially important in the current financial climate.

In this context, my heart goes to Android developers who maintain the Twitter Android app nowadays. For reasons that I find difficult to understand, the previous leadership agreed to introduction of Jetpack Compose into their codebase, which was (and still is) a relatively immature technology. So, they embarked on this project, but then came the layoffs and resignations. I don’t have any insight into what’s going on at Twitter, but I’m willing to speculate that the developers who maintain this codebase today would really benefit from not having such technological fragmentation, tricky integrations, longer build times and quirky bugs.

My predictions for Jetpack Compose are fairly straightforward: it’ll keep maturing and gaining traction going forward. I hope Google will implement proper hot reload for Compose this year (which they call Live Edit), so we could get at least some real benefits from this questionable addition to our toolbox.

Alternative Billing Systems for Apps on Google Play

Google allowed alternative in-app billing systems to be used by apps distributed through Google Play. Currently, this option is available in just several countries and EU, and comes with many strings attached. Nevertheless, in my opinion, it’s a major step forward in terms of opening up competition around Google Play.

The reason for this change is pretty clear: antitrust agencies all around the world are looking into Google’s monopoly over Android and impose regulatory and legal restrictions on Google’s mobile business.

Note that even if apps opt for the alternative billing systems, they’ll still be subject to Google Play service fee, albeit reduced by 3%. So, this change, however important, will impact the earnings of the high-performing apps by less than 10% (from 30% to 3% + the cost of the alternative billing system). I guess that smaller apps, which qualify for the 15% service fee, won’t even bother to explore this option.

Big screens

Remember the era when tablets were the “hot and new” tech and everybody was obsessed about supporting bigger screens? If you do, then I’ve got sad news for you: you aren’t young anymore. Sorry. Seriously, though, as someone who lived through the “big form factors are the future” wave, I noticed a similar sentiment arising in 2022 as well.

Last time, the rush towards big screens turned out to be a short-term fad. Tablets didn’t deliver on the enthusiastic expectations and, surprisingly, it was Apple who ended up having the biggest chunk of this market. In my experience, most newer Android projects today don’t even consider the implications of big screens and don’t invest any time into the respective adaptations.

All in all, I expect the current wave of “big screen” enthusiasm to fade away pretty quickly, without leaving much impact on the ecosystem. One valid counter-argument to this prediction would be “what about Chromebooks?”. Chromebooks are indeed a growing market segment, but, in my estimation, they present an attractive target for only a small subset of special applications (at least for now).

Per-app Language Preferences

One serious flaw of internationalization mechanism in Android is that all applications on a given device use system’s locale and there is no way to change that. Therefore, when you want your users to be able to change app’s locale at runtime, independently of system’s locale, you need to resolve to tricky hacks to work around Android’s limitations.

Android 13 finally introduces support for “per app language preferences”. This feature consists of a centralized screen in Settings where users can change individual apps’ locale and a set of corresponding APIs for developers to use. Hopefully, we won’t need to resolve to various hacks (e.g. substitutions of base Context objects) going forward. In addition, there is backwards compatible version of the APIs in AndroidX, so you don’t need to wait for a widespread adoption of Android 13 to use the new APIs in your projects.

The only caveat here is that this feature seems to assume that all your localization resources (e.g. strings translations) are bundled inside the distributable APK/AAB. Therefore, if your app fetches localization information from the internet, you might need to still employ some hacks to integrate with the new APIs.

All in all, given the fact that implementing per-app language choice became much simpler with the new APIs, I expect more apps to implement this feature than we saw in the past.

Android Studio

Usually, I wouldn’t describe new features inside Android Studio as breakthroughs, but there is one new feature that I really like, so I want to give it a shoutout. I’m talking about the ability to pair a device for debug over Wi-Fi using either QR code or Pin code. I’m pretty sure that this feature was relatively simple to implement, but, boy, what an improvement in developer experience it makes.

Android Studio folks, congrats! Please find more low-hanging fruits like this one.

Android vs Flutter

Surprisingly, my biggest realization and takeaway from this year isn’t related to Android Framework, but to Flutter.

Long-term readers of this blog probably remember that I’ve been skeptical towards Flutter from the very beginning. In my imagination, the best case scenario for Flutter was to replace React Native as the most popular cross-platform framework. I thought that Flutter might gain control of React Native’s market share, but won’t grow much past that. Well, it’s time to admit that I was wrong.

Look at these stats from StackOverflow Trends:

We can see that Flutter tag on StackOverflow is more active than all other popular cross-platfrom tags combined. That’s impressive, but what’s surprising is that, while React Native’s growth stopped, it hadn’t actually lost in popularity since Flutter entered the picture. So, if React Native remains approximately as popular as in 2019, who adopts Flutter?

Well, look at this chart now:

Surprisingly, the number of new Flutter questions on StackOverflow is roughly equal to the number of new Android questions. Furthermore, there are already more Dart-tagged questions than Kotlin-tagged.

You might object that StackOverflow trends isn’t a good metric to rely upon. Fair enough. However, we need some metric to discuss technology trends, and this is the best I could find. Furthermore, while I couldn’t find other info to compare the popularity of Android Framework to Flutter, there are quite a few Programming Languages indices out there. Whether you look at TIOBE, or PYPL, or Spectrum, you get the same picture: Dart is growing very fast and, for 2022, loses to Kotlin in popularity by about a factor of just 2. Since Spectrum’s “trending” index gives Dart the ranking of 14.78 for 2022, while Kotlin’s is just 8.24, I fully expect Dart to close the gap to Kotlin in 2023.

So, what can we say about Android and Flutter in light of the above information? I’ll leave this part up to you to interpret and derive predictions, but one thing is certain: my skepticism towards Flutter was misplaced. Flutter team did an amazing job over the past couple of years and today, in some aspects, Flutter looks more as a competitor to Android framework, rather than a competitor to React Native.

Conclusion

So, these are my main takeaways from 2022 in the context of native Android development. If you think I missed something, or disagree with me, please feel free to leave a comment below.

Happy New Year everyone! Here’s to an amazing 2023!