As we approach the end of 2021, I’d like to take a moment to reflect on the state of the native Android development ecosystem and make predictions for the upcoming year.

Review of Last Year’s Predictions

At this point, I think I can call writing these “summary” posts a tradition. Last year, I wrote one too. So, before I take a look ahead, I’m really curious to review my past predictions and see whether they were any accurate.

On the practical side, if you look at the big picture that includes the entire ecosystem, Kotlin is still inferior to Java in Android.

Unfortunately, the situation hasn’t changed much since then. Just recently I discussed where we stand after 4 years of “official” support for Kotlin in Android and concluded that there are still way too many drawbacks and limitations. Kotlin isn’t “bad” language per se, but slower build times, crippled auto-completion, UI lags and other factors undermine its original promise of higher productivity.

However, said all that, I wouldn’t start a new Android project in 2021 using Java (unless I’d have a good reason to). Not because Kotlin is better, but because it surpassed the 50% mark and because Google will keep forcing it on us. As for existing Java projects, whether to introduce Kotlin into them is still a nuanced question which should be decided on case-by-case basis.

All these recommendations are still valid. In fact, I came to believe that for projects that managed to stick to Java so far, it might be best to avoid Kotlin for as long as possible. I’m aware that some Android developers won’t be willing to work on Java-only projects, which might be a major problem. However, I have a subjective feeling (not backed by any stats) that most Kotlin zealots moved on (into KMP lands, for example), so the climate today is more favorable to Java than one year ago. If you see different picture in your corner of the world, please let us know about that in comments.

I haven’t tried Compose yet, but I do plan to see what’s going on there in the coming months. That said, if you really care about productivity, stability and quality, I can already recommend avoiding spending much time on Compose in the coming year. You’ll hear many developers, bloggers and speakers claim that “if you don’t embrace Compose, you’ll be left behind”, but that’s also what people said about Kotlin three years ago. In practice, you could’ve been happily coding in Java all this time (sparing yourself a lot of headache), and you can even keep coding in Java if that’s what you want.

This one was spot on. I did want to try Compose this year in a pet project, but didn’t get to it because I didn’t feel it’s worth my time at this point (unless I’d want to create a course about this framework). That said, I did had one customer this year interested in Compose, but, even though it would be a great opportunity for me, I honestly told them that’s unfortunate idea.

If you’re a blogger or a conference speaker, on the other hand, the hype around Compose is going to be huge, so it’s an opportunity.

This one is kind of obvious, isn’t it?

In 2020, we started to see the first signs of KMP and Jetpack convergence. The most prominent one was the fact that it’s JetBrains who ports Compose to desktop, but there are additional signs as well. Therefore, if Compose indeed hits stable in 2021, I’m fairly confident that we’ll see a major push towards KMP from Google’s side.

Well, Compose indeed hit stable in 2021, but I’m not sure we saw “a major push towards KMP from Google’s side”. Maybe I’m missing something, but it feels like KMP is actually losing momentum. Again, if you think otherwise, you’re more than welcome to share your experience in comments.

I don’t see myself using Flow in professional projects in 2021, but I will keep an eye on it

It worked out exactly as predicted. You could ignore Flow in 2021 and wouldn’t miss a thing. I’m not that interested in Flow for professional coding in 2022 either, but, given how many students asked me to create a course about this framework, I might learn it just for that sake next year.

If, for example, you took my Dagger course and already architected your app according to my recommendations, there is almost nothing you can get out of Hilt (except for more risk due to immaturity and additional annotation processors). On the other hand, if you listened to Google’s recommendations two years ago and adopted dagger.android, I think it’s worth assessing the long-term ROI of migration to either “standard” Dagger, or Hilt.

Still holds for 2022, with a small correction that if you use the awful ViewModel in your code (I don’t), Hilt’s magic makes it much simpler to inject stuff into these components.

Meanwhile, while all these “cool” approaches came and went, I just used findViewById() and recommended everyone to do the same. Happy to report exactly 0 issues with this approach over the course of the last 6 years. Cumulative time spent on learning and debugging: on the order of one hour.

Yes! Simple is better. This year I took a closer look at ViewBinding framework and decided to avoid it as much as I can.

Recently I started a new pet project and decided to give some “new and shiny” tools a try, including Navigation Component. After implementing bottom tabs navigation using this library, I can say that it’s probably the worst navigation framework I’ve ever seen.

[…]

All in all, I’m really puzzled by Navigation Component. Clearly, a lot of effort went into it, but it’s not clear why we needed this addition to begin with.

Tried to use Navigation Component in a small app this year and, boy, it’s an abomination! Avoid at all costs!

In 2020, Google clearly made a big step in automotive direction with Android and I expect to see more news in this context in 2021.

The market of automotive infotainment systems definitely gets hotter every month, but I don’t remember seeing any major steps forward from Android. Did I miss something?

All in all, I’m quite satisfied with my predictions and recommendations from one year ago. Sure, many “higher-level” changes that I expected to see didn’t materialize (or I missed them), but when it comes to building and maintaining Android apps, I think my recommendations were solid.

Oracle vs Google Lawsuit Concerning Java APIs in Android is Over

I bet you’d expect the biggest news of 2021 to be about Jetpack Compose, KMP, Flutter or some other “new and shiny” tech or tool. Yet, the most important story of the year is the final decision in decade-long legal dispute between Oracle and Google over copyrighted Java APIs used in Android platform.

I won’t torture you with the description of this lawsuit (if you’re curious, I wrote an article about it a while ago). However, I believe that all developers need to know at least these two facts:

1. 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”.
2. SCOTUS did not address (and, consequently, did not change) the preceding rulings which had asserted that software APIs are copyrightable.

The first point above means that Google’s monopoly and iron grip over Android ecosystem will remain intact. In my opinion, these are bad news for the world in general, but very good news for Android developers because it means that Android is most probably not going anywhere. So, our jobs are probably secure. 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.

If you’re curious what could happen if Oracle would win, you can read this article, but make sure to put your tinfoil hat on beforehand. Frankly, given Google prevailed eventually, we are in “business as usual” situation, so all these articles lost from their practical relevance.

As for the second point, it has less practical implications, but is very interesting to discuss nonetheless. See, for many years, Google claimed that if APIs are deemed copyrightable, the software development, as we know it, will face some catastrophe. Many prominent and respectable members of software community authored so-called amicus briefs to the court, basically voicing the same concerns. Well, decade later, court’s decision, as it stands right now, is that software APIs are indeed copyrightable. And yet, the software industry is still here and nobody cares, except for curious nerds like myself and a bunch of lawyers. Nothing has changed and, most probably, nothing will change. All this fear-mongering was just Google’s PR campaign and had nothing to do with reality. Therefore, in my opinion, the main takeaway from this story is that we shall be very skeptical of catastrophic fear-mongering, even if it comes from “experts” in a particular field.

Jetpack Compose

The biggest tech-related announcement of 2021 was, of course, the release of version 1.0 of Jetpack Compose.

I haven’t tried Jetpack Compose yet, but, from what I heard, the current state of Jetpack Compose follows the standard Google’s nomenclature: 1.0 means “kind of working, but limited and needs mass QA by users”. I’m sure that the situation will improve going forward, but, as of today, I wouldn’t use it if I’d want to be productive.

At this point, many developers will jump to their feet and start shouting that Jetpack Compose saves so much time. Don’t bother. I already tried Flutter, so I understand the concept and the potential benefits (after all, Jetpack Compose is just Flutter wannabe in Kotlin). When Compose will support hot reload the way Flutter does, the trade-off might shift. However, currently, with its slow and cumbersome preview, Jetpack Compose is still very immature. As far as I know, proper hot reload is already in development, so, hopefully, Google will release something working and not buggy in 2022.

All in all, in terms of productivity, stability and maintenance, I wouldn’t recommend adopting Jetpack Compose for at least another 6 months. Many apps already use it in production, but they are early adopters. This means that they accept the productivity hit either explicitly or implicitly, or they’re just in denial. That said, there is nothing wrong with trying Jetpack Compose as an experiment if the timeline of your project allows that. Just be honest with yourself and your managers and don’t feed them lies. If you want to try this framework because you’re simply curious, just say so.

And if you do decide to try Compose, I fully concur with what Gabor Varadi (aka Zhuinden) recommended: use Jetpack Compose just for the UI layer, while implementing “screens” using Activities and/or Fragments like before. It’s way too early to bet on Compose navigation and thus, basically, make Jetpack Compose a cornerstone of your presentation layer’s architecture.

Compose Multiplatform

It’s not a secret anymore that Jetpack Compose is part of a larger effort of creating a multiplatform UI toolkit, in collaboration with JetBrains.

Prediction: Jetpack Compose will be multiplatform UI framework.
It needs to target Fuchsia, and competes with Flutter.

— Vasiliy Zukanov (@VasiliyZukanov) December 5, 2019

As I explained in the “conspiratorial” post linked above, Google was interested in this direction because they were preparing to switch from Android to Fuchsia if Oracle’s win in the court would become a threat to their monopoly in Android world. However, after Google won in the Supreme Court, I’m really not sure whether they have any incentive to invest into 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.

However, JetBrains, the company that created Kotlin programming language, definitely has a lot at stake when it comes to multiplatform development. This year, they released Compose Multiplatfrom 1.0. As far as I understand, that’s basically a UI toolkit built on the same foundation as Jetpack Compose, but which targets multiple platforms at once. Currently, Compose Multiplatform supports desktop, web and Android. The elephant in the room is, of course, support for iOS. In my estimation, if JetBrains want to have even slightest chance with this framework, targeting iOS is mandatory. I just don’t see a big market for Compose Mutliplatform, unless it can be used to write multiplatform mobile apps. Therefore, I expect to see some developments in this area in 2022.

Material You

Material You, aka Material Design v3, is the new set of guidelines and tools for UI design from Google.

To be honest, I’m not a “visual” person, so my design proficiency is very low. However, I do know that the best designers I’ve ever worked with haven’t relied on material design guidelines too much. And, for sure, after investing so much effort into choosing proper colors and branding, they wouldn’t accept the idea of changing the palette in response to some external assets. Furthremore, even if you’d find designers willing to try that, I’m pretty sure that product managers and business folks would snipe this initiative from afar.

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.

As for other aspects and tools of Material Design 3, I guess no harm will come from using them, if their default appearance aligns with what your designers envision. Or if you don’t work with designers at all and just want to get something basic out there quickly.

Kotlin Coroutines

One of the most surprising things that I noticed in 2021 was the slowing down of Kotlin Coroutines adoption. Yes, you read that right, I really do think that after the initial hype had passed, Coroutines aren’t doing that well.

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, give 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.

Now, let’s be honest here: there are many good reasons to be skeptical of Coroutines framework. As I wrote many times in the past, it’s the most complicated concurrency framework I’ve ever worked with. And I’m telling you that as a person who invested several months of his life to create a video course about Coroutines. So, no wonder developers are skeptical.

One might argue that I’m just extrapolating from my personal experience and nothing of this kind actually happens, so let me show you a quantitative evidence. According to StackOverflow Trends, while the proportion of Kotlin-related searches increases monotonically, the same metric for Coroutines flat-lined about two years ago:

The above isn’t a scientific proof, of course. However, in light of the fact that Coroutines is one of the most complicated frameworks in Kotlin, one would expect developers to have more questions about it. So, there is a signal there.

At this point, I still haven’t processed this situation entirely, so I don’t have any practical recommendations in this context. However, I think that Android developers should be aware of this trend, especially if they’re contemplating Coroutines adoption.

ViewModel

It’s not a secret that I think that Jetpack ViewModel is the biggest mistake in Android APIs ever. The harm from this framework exceeds the harm from AsyncTask, Loaders, SyncAdapter, DataBinding, etc., combined. ViewModel is an architectural abomination and, luckily, I managed to avoid using it almost entirely (except when clients’ codebases already had ViewModels inside).

I won’t go into more detail here because I predicted this outcome in my post from several years ago, so you can read that. The actual harm turned out to be much bigger, though. For example, I couldn’t even imagine that ViewModel will end up being so contagious and all dependency injection frameworks for Android will eventually increase their complexity to accomodate this awful component.

The good news (or the bad news, depending on your point of view) is that ViewModel seemingly has no place in Jetpack Compose world:

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

Conclusion

Evidently, it would be impossible to even mention all the developments and changes in Android ecosystem in one single post, let alone discuss them. Therefore, in this article, I only shared the most important and interesting points with you. All of that is just my opinions, of course, so feel free to let me know if you disagree or I missed something in the comments section below.

As usual, thanks for reading and let me use this opportunity to wish all of you Happy New Year! Last year, I hoped that 2021 will be normal and boring, but it didn’t work out quite well. So, I’ll make that wish one more time in a hope that this year we will get back to normal, boring life. See you in 2022.