I have been doing the Android development for my personal finance app for the last 2 months. At the very least it’s bittersweet experience with respect to tooling. This is an opinionated blog post, so take whatever I write with a grain of salt.

The good parts

1. Android architecture components - Working with CursorLoaders and database was messy and convoluted in Android before the introduction of Room/LiveData and I have been burned by activity life cycle related issue many a time. Architecture components around lifecycle solve this problem tremendously. I can now confidently write, database related code with type safety around SQL and Java types, plus I don’t have to worry about threading issues for the majority of the time.
2. ConstraintLayout - I love ConstraintLayout and after working on iOS and its storyboard, I vastly prefer Android Studio’s UI Builder with ConstraintLayout and Navigation Editor to Xcode Storyboard. I miss ConstraintLayout on iOS.
3. Kotlin - Kotlin was such breath of fresh air. If you are working with API25 or less then you must learn Kotlin. Since Java 8 is available only above API25, you will not get all the goodness of stream, lambda if developing below API26. But Kotlin has all those things inbuilt. Extension function itself is a nice feature to switch to this language + type inference, data classes, make you write clear and concise code.
4. Emulator enhancements - Android emulator has become very fast, responsive and state save/reload feature is such a time saver. It is still buggy though. It crashes left and right and consumes loads of memory.

Not so good parts

1. Hot deploy - I really, really, really wanted to like hot deploy. But its totally broken for me. It sometimes works, and most of the time it just fails miserably and restarts the app. Sometimes, due to code weaving, app crashes with some indecipherable stack trace. Initially, I thought I made some mistake in development and spend nearly 1 hour to find what I did wrong. Then I just did normal deploy and it worked.
2. Firebase/Fabric - It’s not actually Android core feature, but using fabric and firebase for analytics and crash reporting is a pain in the neck. On the web, you just include one javascript code block and you are ready to go. On Android (and even for iOS) there are lots of fiddly configuration you have to do before you even get started.

Ugly

1. Memory Hog - Android studio easily consumes 13-14 GB of my 16 GB available RAM and makes my system totally unusable after using it for more than 15-18 hours. I have to keep restarting it. While working with the emulator, the problem gets exacerbated,
2. Library mess - On Android, there are loads of framework and core libraries to do the same stuff, and they keep changing and adding new stuff every new release. Granted they have those nice Google I/O sessions for every major change, but if you starting fresh and just want to check which libraries you can use for say background processing - You have to find out each case separately, whether you want to do in the foreground or background. Whether it can be done via Services. What are AlarmManager for. And half of the StackOverflow answers are useless because they keep changing everything every new version. To be frank I still don’t understand v4/v7 stuff, and hopefully, androidx will solve that problem.
3. Debugging - Debugging the problem if problem occurs on end-user device is such a horrible experience (This is true for even iOS development). You don’t have logs, you just have a crash report (if you have Fabric enabled) and most of the time stack traces are not good enough to understand the problem. I think there should be a framework level feature to enable filesystem logging so that we can ask the selected users to enable those logs and rerun the scenario. Most of the time user is willing to provide all the details. I have to write some buggy filesystem logging in my app so that my beta tester users can give me logs to debug.