Android First? Or HTML-First in the Enterprise?
- May 28, 2014
- 0 Comments
I’ve written several times before that if you’re writing a native mobile app, the right place to start is with iOS (in my opinion, your mileage may vary). First, there’s the fragmentation. An app developed for Android-based hardware has to target a lower common denominator because the actual addressable market for a “native feeling” app is so small (due to fragmentation).
Then there’s the recent stories about the compass and gyroscopes and accelerometers not even working similarly on different devices. This is the kind of not-so-subtle but app-defeating problem that you just can’t work around in any reasonable way.
Both of these are less of an issue for the Enterprise, where a good HTML5 app can work well on both iOS and Android, and use of gyroscope and accelerometer is less critical, for example. When you’re viewing, editing, and annotating enterprise data, the hardware features necessary tend to be more commonly available.
But, don’t take my word for it. Great article on TechCrunch on the real fallacy of going Android first (fallacy may be a strong word, but I imagine this article came out of quite a bit of immediate frustration for the author):
So we jumped in. We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013. We posted a public beta in July. And in October, we launched with terrific press coverage, including from a few folks who sang our praises specifically because we went Android-first. Android users are sick of watching new apps launch on iPhone, with Android as an often-underwhelming afterthought.
We launched Emu for iPhone on April 2, and we’ve pulled Emu for Android out of the Play Store. We hope we’ll return to Android someday, but our team is too small to innovate and iterate on multiple platforms simultaneously. We’ve concluded iPhone is a better place to be:
- Our decision to build on top of SMS/MMS involved huge, unanticipated technical hurdles.
- Even when you don’t support older Android versions, fragmentation is a huge drain on resources.
- Google’s tools and documentation are less advanced, and less stable, than Apple’s.
- Android’s larger install base doesn’t translate into a larger addressable market.
That last point… the install base doesn’t translate into a larger addressable market.
On a Galaxy S4 with Samsung’s Multi-Window feature enabled, Emu’s popup windows are squished by the keyboard. This doesn’t happen on the Galaxy S4 sold by Google, without Samsung’s software modifications; or with the Multi-Window feature on the Galaxy S3. We’ve investigated, but because it relates to Samsung-specific functionality, we probably can’t fix it without direct cooperation from them.
So… the author also correctly explains that it isn’t just the quantity of bugs, it is the effort to track them down, to understand them, reproduce them (how many android devices do you want to own? ), etc.
At BP3, we’ve since turned our focus to responsive HTML5 apps for mobile use, for reasons stated in other posts. But if we write a mobile app, rest assured we’ll start with iOS- partly because of data like the above- and we’ll worry about Android second. In a sense, HTML5 responsive apps is our first target, iOS second, Android third. That feels like the right answer for enterprise BPM, because we’ve been able to produce UI that we’re really proud of in HTML5.