About twice a year, I get involved in a project that requires me to do some Android development; so, about twice a year, I re-launch Google’s so-called integrated development environment, Android Studio, with fingers crossed… and twice a year I find myself wincing with bitter disappointment, as I rediscover that it still has all the elegant, intuitive simplicity of a Rube Goldberg machine.
Let me hasten to stress that I’m not an OS partisan, or, to the extent that I am, I’m inclined toward Google. All my own smartphones have been Androids. I’ve been writing Android apps, both professionally and for fun, since 2009, when I first bought an HTC Magic. All my phones since have also been Android: Galaxy S2, Nexus 4, Moto X and my shiny new Pixel.
But, I also write iOS and tvOS apps; and despite my abstract disapproval of Apple’s hegemonic attitude toward software, whenever I launch its IDE XCode, I breathe a little easier. It’s fast. It’s slick. And even when it fails to be helpful, it rarely actually gets in my way — something which, as far as I can tell, is Android Studio’s fundamental core competency.
For instance: I have never actually succeeded at using its visual tools to lay out elements on a screen. I’m sure it’s theoretically possible; but every time I’ve tried, I’ve gotten so frustrated that I’ve just given up and written raw XML layout files instead. I have it on good authority that I am not alone in this. In XCode, conversely, I drag and drop with abandon and glee.
Out of the box, Studio doesn’t auto-import Java classes for me; the setting for doing so is buried deep within its impenetrable labyrinth of menus. Out of the box, Studio doesn’t tell me how to load any of the zillion support libraries I probably need, nor how to get Android’s (still painfully slow) emulator running. The secrets to both of these things are buried, believe it or not, in the “Android” submenu under the “Tools” menu. Think about that for a moment. Why does Google’s flagship Android development tool have a “Tools / Android” menu? Isn’t the whole thing an Android tool? Shouldn’t these key elements be first-class citizens?
One problem, of course, is that Android Studio was not built from scratch; it’s based on the long-in-the-tooth IntelliJ IDEA platform, a Java IDE… and, well, you can tell. It feels like fifteen-year-old software, and it’s all too apparent that it was adapted to, rather than built for, Android development. (Again: “Tools / Android.”) And, of course, it’s written in Java, which makes it multi-platform… but slow.
It’s true that the Android ecosystem itself is clumsy and complex, fragmented into a dizzying plethora of versions of various libraries and SDKs. It’s true that, for instance, the Gradle build tool is famously developer-hostile. (Although building is just hard; Apple’s build tools don’t exactly hold your hand either.) But a better-designed IDE could at least mitigate this. It’s true that XCode only has to run on one operating system, Apple’s, whereas Android Studio must be multi-platform. But surely Google, of all companies, has the resources to support native code on multiple platforms.
It is truly remarkable that a hypermonied behemoth the size of Google decided to go this slow, kludgy, ugly route for a flagship development environment for its mobile platform with well over a billion active installs. The negative effects are numerous. Better tooling is one reason iOS development is faster and more efficient. Developers comfortable in both ecosystems prefer iOS to Android because it’s easier to work with, and so we help influence much smartphone software to be iOS-first, with Android as a second-class after thought. Android apps famously tend to be buggier than iOS, and it’s hard to believe that the IDE has nothing to do with that.
Most of all, though, albeit most selfishly, if Google’s IDE were better, it would push Apple’s to improve. XCode is far from perfect. It crashes. It hangs. But even with those flaws, iOS development is so much less painful than Android development that there is really no comparison. (Well, until you try to deploy. Then, Android is painless; Apple’s improved-but-still-all-too-often-Kafkaesque process for building, signing, uploading, submitting and waiting for approval for even beta test builds is one that frequently inspires deep rancor and resentment in every iOS developer I know.)
Of late, though, I say with a kind of skeptical anticipation, for the first time in years, there is some real competition. This has long been true for .NET programmers, courtesy of Xamarin, recently acquired by Microsoft, which lets you write .NET code and build native apps for both Android and iOS. But nowadays, Facebook’s React Native is becoming a realistic solution for building cross-platform native apps without having to write (much) native code… and, therefore, without having to use either Android Studio or XCode.
I’m not saying either will go away. But it’s nice to see somebody at least trying to elbow their way past Apple and Google’s de facto developer gatekeepers. They, especially the latter, have grown complacent for lack of competition. Let’s see how they react to React.
Comment