The state of Android development in 2013
I started Android development back in 2009 when the 1.6 platform was released. I decided to write a couple apps for fun that solved some of my problems. After launching two apps within a couple months, I took a hiatus from mobile to try my hand in web and backend development. Now, I find myself back developing on Android for Buffer. The switch back has given me some perspective on the state of being an Android developer that I’d like to share.
My work at Buffer so far
I released the new Buffer Android application a month and a half after joining. It was released early because it already had more features and improvements than the existing app, but was still lacking in several other major features. After the initial re-launch, I worked (and continue to work) fast to release updates with new features and bug fixes.
Iteration
After coming from web development, I was used to building and iterating as fast as possible, pushing out changes several times a day. At Fancite (the startup I previously founded), we strived to be lean by releasing features as tests and learning from users. I am a huge fan of the lean approach and believe every startup should execute this way. On the web, we would launch a test, and within a few hours we could make quick changes based on the results of the test. It’s no surprise that iteration is much slower on mobile. At Buffer we’ve decided to push out weekly updates, and in each update we learn from feedback and our own tests. This is the fastest we’ve found that we can execute. We can’t push an update every time I develop a cool animation or fix a bug because it’s an annoyance for users to update the native app. We have to batch features into one update, which I believe should be the old way of doing things. I really wish the native mobile app architecture would be similar to the web in that users always have the latest version. But because there is so much more overhead in deploying an app and updates, I believe someone figuring out product-market fit, should not go mobile first. I know that overhead on iOS is much worse than Android, so this especially true for an iOS app. Building for mobile, (especially for iOS) you’re expected to launch a “complete product.” I’ve always believed that if you try to launch a complete product before figuring out the product-market fit, you’re probably too late.
Android Development and Fragmentation
In 2009, I was just starting to experience some of the pains of fragmentation on Android. It wasn’t unbearable because there were just two API versions to deal with (1.5 and 1.6), and only a hand full of devices to support.
Today, the Buffer Android app can run on over 2200 different Android devices built by many different manufacturers. Each manufacturer puts different versions of Android on their phones and often makes their own modifications to the Android SDK. I test on 4 devices. It is pretty much impossible, and not worth it, to cover all of these devices in testing simply because it adds to the already high overhead of pushing out an update to the app. At Buffer, I make sure to test extensively on the four devices, and a few types of simulators before releasing. After pushing an update, all I can do is wait and see if a user is having problems via an email/tweet, or if I receive a crash report through Crittercism (which has been a lifesaver). In my short time after launching, I have fixed several device specific issues that I could not reproduce on any device in our stock. Those bugs are the worst to fix, as I am just shooting in the dark. The way I alleviate this, is I send a custom build of our app to users who experience device specific issues. Thankfully, Buffer users are extremely helpful and often provide great feedback. This workflow has been solid for me, but not ideal. It’s really the only way I can see myself being able to cover device specific problems. I hate giving a bad experience to a certain set of users, but I have no other option. You can either not support devices you miss in testing and reduce your potential user pool, or race to reduce problems in these uncovered devices over further updates. We’ve done the latter.
Here’s an example of how fragmentation is really hurting Android developers. Just this week, I’ve started developing a photo-sharing feature for the Buffer Android app. Using the camera SDK, I had tested this feature thoroughly on all four of my devices and it seemed to work well. I sent out a build to my buddy Tom who is working out of London and he tells me it’s not working. The photos he takes on his Galaxy S3 always appear landscape. I grabbed a few more devices to test but I just could not reproduce the issue. After a couple days of back and fourth remote debugging I finally resorted to buying an S3 from craigslist and see the problem for myself. Indeed on this one common Android phone, photos were not oriented correctly. When debugging on the actual device, I noticed that the Android ExifInterface API was broken and would not report the correct orientation of an image. I ended up importing an Exif Java library to read the image orientation for myself. This was the solution to a bug that should have never happened. And is probably manifested from Samsung’s modifications to the Android SDK. If Tom did’t have an S3, we would have missed this. I’m sure there are many more issues like this that we’ve missed. Google has been long aware of fragmentation issues and have started taking drastic measures to deal with these issues. They recently made a change to their TOS that device manufacturers cannot make modifications to the SDK. We’ll see what effect that has on easing some of the major fragmentation issues developers are dealing with.
Building apps on Android today is what I’d imagine building for the web was like in 1999.
Resources
Android development is barely four years old. Building apps on Android today is what I’d imagine building for the web was like in 1999. There are limited resources, many Stack Overflow questions yet to be answered, and various libraries that are not yet feature complete (or even stable, ehem Facebook). To me, it’s exciting because I look at the growth of Android, where it has been, and where it is going, and I see huge opportunity. In 2009, there were no third-party libraries to include, so you built everything yourself. If a user reported a crash, I used to ask them to email me the logcat. Returning back to Android, I see there has been significant progress. But I still find myself doing a lot from scratch. For me, it’s exciting because I enjoy building components from scratch. However, this creates a barrier to entry for most.
Looking Ahead
I am excited because I know Android can be a great developer platform. I’ve seen some pretty cool work done by individuals and organizations to help further the OS along. I’m really impressed with the engineering team at Square and their commitment and contribution to Android through open source libraries and tools. After a few months back on Android with Buffer, I am confident that I can help improve the experience of developing for Android in a similar fashion. My goal for 2013 is to help make Android a great developer platform.
Photo Credit: Lee Bull