Java is slowing Android’s growth and Kotlin is not the answer

I am sitting in my study, it’s dark and completely silent, I am in the creative flow, typing away the last lines of code for my new Chromecast game. I hit build and strange sound fills the room. This strange sound might fool someone into thinking that I am about to make serious breakthrough in molecular physics. But in reality my Macbook Air is trying to build 200 unique lines of code wrapped in megabytes of Android libraries. My flow is gone, and I am left with flashbacks of Android development from five years ago.

I remember that it used to be quite normal to wait 7 minutes for Android emulator to boot and then keep it open at all costs. When you had spent that much time waiting, additional 2–4 minutes of build time seemed quite reasonable. Things improved when I was actually able to afford a device I was writing apps for. But this was five years ago. Now it is 2017, we have self-driving cars and Web Assembly implemented on all major browsers. Somehow development on Android still sucks. Google has set out to reach next billion consumers, but cost of entry for new creators seems as high as ever. If you ask me, I think Java is slowing Android’s growth and more CPU cycle burning sugar (Kotlin) is not going to make things any better.

Java is verbose

I tried reading Android documentation on implementing Cast Remote Display Service and in-app purchases. I gave up shortly afterwards and just copy/pasted code from the demo apps. The true essence of what I was trying to implement was usually hiding in two method calls. But to do it “Java way”, I first needed to OOP the hell out of my solution and run code generation, because even Google thinks that’s the only way to make the in-app purchase API bearable. When you take a language, where you can’t implement a callback without creating a class and a platform which heavily relies on asynchronous behavior, you get a bloated mess.

I think, Kotlin does help tackling code verbosity with modern language constructs, but solution is partial. Android APIs are still built to be used from Java. To be fair, Google is working on Java 8 support with Android Studio 3.0, but it will take many years before Android platform fully embraces Java 8 features.

Slow nature of Java influenced over-engineered application lifecycle

Android activity/fragment/service lifecycle events are way too complex. Developers don’t understand it and you can’t expect that everyone takes time to implement it correctly. Without this, the perfect story of efficient platform, where every app tries to minimize its energy footprint, falls apart. If not Java, Android could have ended up with simpler lifecycle events resembling IOS or Windows Phone.

Kotlin adds more overhead to the runtime, which in turn will require even more engineering to compensate. But maybe the new Android reactive libraries with automated app lifecycle handling will be the over-engineering we have been waiting for.

Heavy build process makes quick iteration impossible and prevents Android from being truly open and accessible to everyone

If you want your app to utilize Google APIs, Firebase and some third party libraries and still keep a decent iteration speed, better find a workstation with powerful CPU and SSD configuration. Google is continuously investing in Java build process optimization with Gradle and improving live app reload, but it’s still not good enough to be used on commodity hardware. It’s easy to push the weight of the platform towards developers and expect that they will keep buying the latest hardware to keep up to speed. But this encourages an elitist platform where only the privileged ones can create content and everyone else is left out (looking at you Apple). In my opinion, software giants shouldn’t keep people from developing countries waiting for software solutions being created for them. They should decrease the cost of becoming a creator, so anyone can start creating software they truly need.

Kotlin support libraries have a build cost too. It will be one more thing which needs to built and optimized. At least now, Google has some commitment to contribute to the optimization process.

Web Apps FTW!

The big assumption here is that Android native apps are still relevant. I am a strong believer in mobile web applications and was very pleased to see new Android web app integrations announced during Google I/O. I think, Google is realizing that platform lock-in strategy is no longer working. In order to sustain Android’s growth, Google has to fully embrace web apps on Android.

I simply don’t see a future, where we are still writing apps in Java or Kotlin. But at the same time, I understand Google’s commitment to the developer community to support and improve existing tools without completely breaking compatibility. I can only hope that turn for the web is going to happen sooner than later. Because anyone with a Raspberry Pi can be a web app developer.