Skip to main content
The cover image for "Thoughts on native Android development"

Thoughts on native Android development

5 min read (1170 words)


I love making apps. I like making stuff and it's even better when I can interact with the stuff I make. App development feels especially real as I can hold and touch what I made. So why don't I have many Android hobby projects? This article is a reflection on the projects I've worked on, the problems I have, and what I want to try in the future.

I love making apps. I like making stuff and it’s even better when I can interact with the stuff I make. App development feels especially real as I can hold and touch what I made. So why don’t I have many Android hobby projects? This article is a reflection on the projects I’ve worked on, the problems I have, and what I want to try in the future.

My background in Android dev #

Minetest Mods #

App screenshot, a list of mod titles and descriptions
Minetest Mods App

I learned native Android development in 2016 to create an app to install mods for Minetest. I published Minetest Mods to the Play Store and maintained it there for several years, unpublishing it only after I added built-in support for downloading mods inside Minetest.

I took great pride in ensuring the app followed Material Design and had a good user experience, and was rewarded with an average rating of 4.3 stars. The rating was reduced by the fact that it only supported mods, and not games or texture packs. There were also a lot of issues with flawed data, I created a new backend called ContentDB to solve this issue, ultimately leading to the obsolescence of the app.

First job #

App screenshot, a cow banner image and a list of news articles

My first job was doing Android, iOS, and backend development at a small software house alongside my studies. It was awesome to get paid for doing the thing I loved! Compare that to my job before, where I worked in hospitality for not much money.

I worked on six different client projects, including two iOS apps and five Android apps. Most of the team had a background in web design, so I was able to play a leading role in the technical direction of the projects including pushing for the adoption of best practices like continuous integration and improved authentication (OAuth2).

Hobby apps #

App screenshot, a pie chart and a graph showing spending
Analytics for Monzo

I did other hobby Android apps but ultimately didn’t complete them due to issues.

Analytics for Monzo was an app to show pretty charts for Monzo bank users, but I was unable to finish it due to a restricted API. With a banking API? Who would have thought?!

ForumMate was a forum aggregator for old-style bulletin board forums, but problems with getting it to work with all forums and concerns about legality led me to abandon the project. I started the project as an excuse to get back up to speed with the latest Android SDK constructs, so it did serve its purpose.

Current job #

My current project at work is an Android app used by millions of people. It’s written mostly in Java with a mixture of modern and legacy APIs. We are slowly rewriting the app into Kotlin.

One of the things that stands out about this project is that it’s the first time I’ve worked on something where I know people that use it. At previous jobs, I mostly worked on niche apps and internal tools for aerospace/transport.

The large user base also allows small changes to make a huge difference to users. I noticed a UX pain point in the app - an icon being used incorrectly. I proposed and implemented the fix for this, which increased the discoverability of an essential feature from a success rate of 26% to 92%. That’s a huge difference from such a small change.

So, what’s the problem then? #

I’m very project-driven; I’ve rarely learned technology just for the sake of it, it’s always because I have an idea I want to make. I learned React to create Renewed Tab because I couldn’t find a New Tab extension that worked how I wanted. The fact is that there are not many things that need an Android app rather than a web app. Web apps can be used on a much wider range of platforms, including phones. Web apps are also much easier to make.

This cross-platform issue is a big one - I rarely write applications for just Linux or Windows, I always prefer to use cross-platform toolkits. Even if I only publish to Linux, the platform I use, I still choose toolkits that are cross-platform. So why do I treat mobile app development differently?

Another issue is that the Android SDK is especially painful to deal with. It’s complicated and there are so many ways to do things; it’s not always clear which should be used. Java as a language leads to boilerplate code, the introduction of Kotlin made a big difference in cutting this down. I do enjoy native Android development, the costs are just high compared to other options.

To the future #

Cross-platform toolkits #

Cross-platform toolkits allow you to develop for Android and iOS from the same codebase. Some even allow targetting desktop as well. This is appealing as it lowers the development effort when creating apps and reduces the time to market.

I have historically been quite sceptical of cross-platform app development toolkits as I got the impression that they gave subpar results.

First, I saw these toolkits as being quite janky and hard to make a good user experience in. This may just be because my exposure has been with thin wrappers over webviews, on badly coded apps. Modern toolkits like React Native and Flutter make it much easier to create good user experiences.

Second, I didn’t think these toolkits would be able to match the appearance and functionality of native apps. This is something I’d like to look into, but I will note that it is very common for Android apps to break material guidelines and instead look like iOS apps. Companies like to avoid doing the same work multiple times. Just because an app is native doesn’t mean that it provides a perfect native experience, it may be easier to provide a good experience using cross-platform toolkits.

Flutter empowers you to create tailored experiences for iOS and Android users without compromise and with fewer resources.

Ideas that work well #

I need to look out for use cases and ideas I have that would suit an app. I don’t want to start making things just for the sake of it. Apps are best suited for ideas that require deeper integration with the device or a user experience that web apps are unable to provide.

In 2019, I started the ForumMate project as an excuse to get back up to speed with the latest Android SDK constructs - including MVVM, Room, repositories, Dagger, data binding, and Jetpack navigation. I choose this idea as it had enough complexity to be an interesting project.

Conclusion #

Hopefully this article wasn’t too negative, it’s not meant to be. I do enjoy native Android dev, but I am wary of the costs especially when working on projects by myself. Native development may still have its place on bigger projects.

The next time I have an idea for an app, I’ll use it as an opportunity to learn a cross-platform toolkit like React Native or Flutter. If you have any thoughts on React Native, Flutter, or other cross-platform toolkits, it would be great to see replies.


Leave comment

Shown publicly next to your comment. Leave blank to show as "Anonymous".
Optional, to notify you if rubenwardy replies. Not shown publicly.
Max 1800 characters. You may use plain text, HTML, or Markdown.