My friend and former intern colleague Andrew Munn has raised quite a ruckus over the laggy behavior experience by users of Android. His original contention has been that Android lacks a dedicated UI thread, and thus is unable to compete with systems like iOS that offer such a thread as part of its graphics architecture. This claim has been rebutted by several critics, most comprehensively by Dianne Hackborn of the Android development team.
Yet, there is something still missing from this discussion. Why is it that Android still seems laggy after years of development? This is not a minor discussion, but goes directly to the quality of the user experience of the device. Dianne’s main argument (she has several of them) is that Android’s API model ensures that every app is sandboxed, and that the ability to optimize the graphics is difficult because the hardware is just not there.
I don’t buy that argument.
Instead, I think she nibbles on the right argument near the end of her piece. In the penultimate paragraph, she describes the similar experience between programming for iOS and programming for Android:
One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “Getting it up to sixty is more difficult-you may have to simplify the cell’s view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand.”
**There is a more fundamental reason why Android is laggy compared to iOS: culture and tools. **The iOS development culture is built around cool design. The Wow Factor is a major component of being highlighted on the front of Apple’s App Store, since the company loves to draw attention to new products with novel interfaces. This also comes out with the major awards Apple releases each year at WWDC: the Apple Design Awards. The mission statement alone makes this self-evident: “The Apple Design Awards 2011 recognize outstanding achievement and excellence in iPhone, iPad, and Mac app design. Each year, winning products set new standards for the developer community to follow. Read about what made this year’s winners stand out above the rest.” [italics added]
Yet, Apple doesn’t just encourage good design, they actively make it easier to attain it through their comprehensive and quality development tools. As TechCrunch recently discussed, Apple’s tools are vastly superior to the tools offered for the Android ecosystem. That means that more effort can be made at producing a high quality application, and less to just get the application off-the-ground and running. This doesn’t mean it is exactly a pleasure to learn Objective-C and its somewhat unique language features. Nonetheless, the lower bar to program Android with Java has not done it any immediate favors.
There is even a more fundamental point to be made though: both tools and culture are driven by the underlying model of both ecosystems. With Android, the goal of openness has meant that it is nearly impossible to develop quality applications for the full range of devices (and their enormous variety of features and capabilities) that run Android. How do you emulate an Android device for development and verify functionality and user experience for the vast majority of users?
Compare that to the walled garden of Apple: there have been a total of 5 iPhone models released in history. When one wants to emulate an app, it is easy to decide if the user experience will work for nearly all users. Thus, the model of the two companies has changed their development patterns, which by extension have affected the tools that are available from the two companies.
Recent reviews of Ice Cream Sandwich have shown some improvement to the issues of lag. Nonetheless, that is not going to change the model by which Android and iOS operate. The culture and tools are derivatives of the cultures chosen by Google and Apple, and hardware acceleration is really the last thing that is going to change this dynamic.
It is not too late to change this, and indeed, Google has emphasized that it wants to bring everyone on one platform. Now, it needs to follow through by building tools to streamline application development and emphasizing quality in its product highlights, awards, and other means of free publicity it offers developers. Google needs to thread the needle on this, and avoid getting bogged down in minutia over …. threads.