In the summer of 2014, we started dabbling with the Android SDK to get a feeling of what it would mean to develop an Android adaptation of iA Writer. We discovered a dev-friendly world with scant traces of the Android horror stories we had in the backs of our minds.
The iOS people never stopped laughing at the growing stack of test devices in all colors and shapes hogging our developer’s desk. We did hit a few bumps further down the road. Still, Android has come a long way from the unsightly UX and low quality device mess it was just three years ago. Here’s what we have learned on the way to the release of iA Writer for Android.
Fragmentation Is A Choice
The Moto G, a smartphone for under $200 unlocked. The HTC One M8 will make many iPhone owners jealous. The nVidia Shield gaming tablet, complete with controller and stylus. The thin and brilliant Galaxy Tab S. The Yoga Tab 2 built to sit upright on a table. The compelling compromise of the Nexus 7. The square BlackBerry Passport that runs Android apps… By now, we wouldn’t be surprised if a beta user posted a screenshot from a pear-shaped iCarly tablet.
Next, the UI. Some manufacturers like nVidia stay close to vanilla Android while others go crazy (and weird—looking at you Samsung), rearranging and reshaping whatever they can get a hold on, which is plenty. Physical buttons or virtual ones? Always there or only on as an option? A hardware keyboard? One action bar, a split one, or none at all? There’s choice.
The user gets to leave their imprint too. You want to define Comic Sans as a system font? Yes you can. We have seen it all.
The core? Android is open source, so why not roll your own. Or buy a device that comes pre-modded, like the Geeksphone Revolution, or the OnePlus One with the Cyanogen Mod logo already on the back. We know this situation from Web development, and we know how to handle it: do not make assumptions about the physicality of the devices you are developing for.
It is risky to extend Android keyboards: No assumptions can be made regarding their shape and size. Don’t try to think in fixed screen layouts. However, a few no-gos aside, the SDK offers a reasonable abstraction of Android’s inherent complexity. With the approach we chose, the dreaded Android fragmentation issue was manageable, although we did hit some fragmentation problems in the beta process with exceptional devices or highly modified OS setups.
Solid Design Guidance
Having to follow the “carrot” approach inherent to the open source world (as opposed to Apple’s “stick” strategy), Google had to come up with design guidelines that are understandable even to the least designery developer. The pre-Lollipop “Holo” theme already brought UX stability to many app interfaces, and Material Design got the aesthetics right. The Material Design guidelines form a impressive, concise design framework.
Android didn’t do away with its no-design roots. Custom line heights no longer working in Lollipop is considered to be a minor issue. After all, we gave you elegantTextHeight. Fonts? Sorry, no, unless you do a bit of DIYing you only get to choose from serif, sans and monospace. So yes, as simple as the app looks now, it was not all sunshine and rainbows.
Stable APIs
The core APIs offered by the Android SDK have proven to be very stable. Lollipop is at its core a completely new OS with a new VM philosophy, but when we updated our first device, the app just continued to work. That’s an amazing feat. Whenever the iOS people took a break from laughing at the stack of test devices, they were toiling away updating their app to work with one iOS upgrade after the other.
Whatever madness has flown into the Android core APIs, it’s there to stay. That can be seen as the reverse side of the coin. Hanging indents are not rendered correctly? Yep, since 2011—it’s a feature by now. Want to handle a text larger than a few 1000 characters? Sorry, the guy who wrote the SpannableStringBuilder class is now enjoying early retirement in Malibu. The Android APIs are stable, but sometimes we’d have wished them to be less stubborn.
The Joy and Pain of Openness
Being able to debug-step through the source code of the SDK is a joy. Knowing that any script-kiddie can do more or less the same with your app’s code is rather disconcerting.
Android remains an open, hacker-friendly OS. Any app is bound to run almost unchecked by a central authority on an ant mountain of devices, many of which jailbroken, with close to no chance at solid license verification, reverse engineering, or tamper resistance.
If you are reverse engineering our app right now (hi!), we will have to… deal with it. There are worse things that can happen: apps get stolen and bundled with malware, then redistributed under a different or even the same name—not a good prospect if you’re just leaving Apple’s safe haven.
So far, the downsides of Android’s openness have been offset by the friendly, multifaceted culture around Android. Solid documentation from Google, the good people at Stack Overflow, our seven nation army of beta testers, the prospect of staged rollouts any time, a fully integrated testing process in the Play Store. Throughout our Android experience, we have seen a cheerful thankfulness towards developers long gone on the Apple ecosystem.
How Did We Do?
It is easier to replicate an existing product than to walk backwards through the dark tunnels of innovation necessary to create a new one. iA Writer for Android is a start—we like to compare it to the first Writer for iOS version released in 2010. With your positive feedback and—if Android continues to evolve at this pace—we see great things coming.
For quite some time, the Android OS has been the “Well, we do have to look at it from time to time, don’t we?” Now, with its partially contained jolly chaos, and its promise of full-featured computing in the palm of your hand, Android strikes us with the excitement of pushing new frontiers.
