9 reasons why I gave up on being a Mobile Developer
Back when I was in university, Android and iOS were still rather new platforms and everybody was excited about them. When there was some kind of coding workshop you almost certainly ended up building a small Android app. That is how I took my first steps in the Android ecosystem and probably also the reason why I became a Mobile Developer right after.
In this article, I want to share the frustrating experiences I’ve had with the Android SDK and Flutter. Some of the points that I address also apply to the iOS SDK. I stopped working as a Mobile Developer a few years ago and hope that many things have changed for the better. But even back then I found the mobile ecosystem to be so misguided that I had to look for an alternative career path.
Fragmentation
The biggest pain point for every Android developer is the huge variety of device configurations. I never quite understood why the better part of the SDK (especially the UI portion) was not a dependency of my app but embedded into the device. That basically forced me to work with the support libraries and debug my app for every targeted API level. In addition to this I constantly experienced random Samsung or Huawei devices crashing on code that worked just fine on the Emulator or my test devices.
Material Design
When I read comments on HackerNews or Reddit about Google’s Material Design, I sometimes feel like I’m the only person that actually likes it. I find it visually appealing and generally enjoy the user experience. The official documentation website came a long way and I consider it a prime example for great documentation. I was super excited when it was announced for Android! That being said, the transition from Holo to Material Design on the Android platform was not a smooth ride at all. It felt like the release was rushed. Very basic widgets were missing from the official Material Design support library for years to come. Even though you could sometimes admire them in Google’s own apps, they didn’t find their way into the support library. Developers were forced to build their own or grab an alternative implementation on GitHub of questionable quality. Along with a fair amount of visual inconsistency and implementation bugs the Material Design support library experience was probably the first time I paused to really think about and question the ecosystem.
Best practices that nobody bothers to follow
It’s a challenging task to build a rock solid Android app. That is mostly because the SDK is developer hostile. It’s amazing that in theory an Android app can idle in the background indefinitely, consuming no system resources and pop back right into its previous state when the user desires. That is at least the case if the developer has successfully implemented the state and lifecycle management.
Developer Hello internet, my app crashes on orientation change how do I fix that?
Internet It’s simple, just disable orientation changes
Ouch. But this is unfortunately quite common.
Did you ever work with Threads in Java? That stuff is super tough in an imperative code base with mutable variables all over the place. Well, guess what: it’s even more difficult with the Android SDK. If you want to manage a Thread from an Activity, you’re basically asking for a bad time. Luckily we got retained Fragments eventually that made this somewhat easier. But only at the price of getting Fragments in the first place.
During my career as a Mobile Developer I interviewed quite a few Senior Android Developers who, with very few exceptions, struggled to get these topics right.
I always wished that Google did more to acknowledge these issues and worked with the community to solve them. The situation has probably improved with Kotlin, but the questionable foundations of the Android ecosystem are still lurking underneath.
Design patterns and annotations for abstractions that don’t work
Developers realized quickly that it is impossible to build a real world application on top of the abstractions provided by the Android SDK. The solution were new design patterns that are probably still popping up on a weekly basis: MVC, MVP, MVVM and MVI are the ones I remember. And since we could not use ordinary constructor calls to manage dependencies, we had to scatter annotations all over the code base. None of this should have been necessary. Java, and even more so Kotlin, are expressive enough to model all of these things in a transparent and straightforward way. But Android prefers huge XML definitions and reflective instantiation, so developers have to obfuscate their code with annotations and questionable design patterns. I honestly don’t have the words to express how bad this is.
Unused advantage of owning the platform
In a way, native iOS and Android development compete with the web as a platform. However, they have the enormous advantage of belonging to a single corporation, whereas the web has many stakeholders who want to influence its development according to their needs. Yet the web is a more vivid and innovative ecosystem. Just take a look at the success story of React: it’s undeniable that the component based approach to user interfaces is the sanest abstraction we came up with so far. Android managed to sleep through this trend for years until finally announcing “Jetpack Compose” which is still only available as a developer preview. Pretty much the same thing happened in the iOS world. So here we are, still inheriting from a 15k LOC android.view.View class with dozens of lifecycle methods while somehow trying to inject our merge XML file. iOS and Android could be the true pioneers and driving force here, but instead the competition has completely left them behind.
With that in mind, congratulations Android!
UI development: please leave your expectations outside
The key to a beautifully crafted app is the user interface. Now I’ve already complained quite a bit about components still not being a thing in the section above, but there is more to that topic. Did you ever debug a glitch on a website? Open the dev tools of your browser, click the affected element and play with the CSS and HTML properties until everything looks right. In comparison to this, Android is an inaccessible blackbox. To be honest, I never fully groked the Android theming and styling mechanics and the tooling around it always seemed utterly useless compared to the accessibility of the web.
Want a drop-shadow around this box? Sure, use this wacky
.9.pngfile or rely on API level 21 where you can render shadows properly (convex shapes only though 😀).Sorry, you forgot to implement one of the four constructors in your custom View. But I’m not stopping you with a compile error, I’d much rather crash at runtime instead!
There are now phones with this super high density. Could you add the respective xxxhpi assets to your app, please? No, vector graphics are not supported, we don’t do this around here.
— Monologues with the Android SDK late at night
Vector graphics
Before Android 21 (5.0), proper vector graphics were simply not supported. The reasoning behind this was that the diversity of Android devices requires graphics that are carefully adjusted to the needs of every density level. Naturally, pragmatic developers created tools that turned my logo.svg into an ldpi/logo.png, mdpi/logo.png, hdpi/logo.png, xhdpi/logo.png, xxhdpi/logo.png and of course xxxhdpi/logo.png. Luckily Google changed their mind eventually and blessed us with VectorDrawable which supports a subset of SVG and has poor backwards compatibility. Granted, it was good enough to relieve the pain back then. However, it still boggles my mind how a development environment that prides itself of running on arbitrary device configurations could even exist without support for vectors for so long.
Dead end
Over the years, I started to worry more and more that my knowledge would become obsolete in the foreseeable future. Most of the things I learned were very specific to Android and only rarely applicable in the larger field of software development. Given its quirks I do not believe that native mobile development is here to stay in the long run and so I started to worry about the usefulness of the skills I acquired.
Flutter
When Flutter was announced, I got excited immediately. It promised to solve some of the major Android SDK flaws while giving me cross-platform support for free. So we actually started migrating our native Android app at my previous job to Flutter. And I got to say: Flutter keeps its promise.
- Android fragmentation issues are completely eliminated by Flutter’s embedded rendering pipeline
- Right from the start it had an exhaustive library of high quality Material Design widgets
- The snappiness of the hot reloading feature blew my mind
- You get an unprecedented high quality look & feel cross-platform experience
But unfortunately it wasn’t all great. And it’s a pity because the issues Flutter suffers from could have been easily avoided by a greenfield project.
- Dart is terrible: it’s a comparatively young language but it repeats a lot of the mistakes of its elderly predecessors (bad language design,
null, statements instead of expressions, …) - Questionable design decisions in the Flutter SDK: instead of creating a better React, they made it worse. What could have been a simple function call tends to be solved by stateful OOP machinery (I recall the routing and handling of dialog widgets as especially painful here).
Conclusion
At some point it was evident to me that this is not the kind of tech I want to spend my time with. I promised myself I would never program for mobile platforms again. A well-designed, responsive website gets you pretty far these days and so this is my default option. It’s a single code base and just works on every client. If I absolutely had to create a mobile app, I would still choose Flutter, even if I only targeted Android. Working with the Android SDK is out of the question for me.
That being said, I got to clarify that I highly admire and appreciate a well-crafted native application (on mobile as well as desktop). I have the utmost respect for the developers that create those with the tools available. I just don’t want to be one of them anymore.
This article is also available as a German translation
