Not too long ago, the whole iOS/Android battle was viewed through much the same lens as the VHS/BetaMax wars. For those too young to remember, there were two competing formats from video cassette recorders in the ‘80s, JVC’s VHS and Sony’s Betamax. VHS ultimately won, leaving many owners of Sony technology in the lurch. It happened again when DVDs evolved into the next generation. There was a battle between Sony’s BluRay and Toshiba’s HD DVD. This time Sony emerged victorious, leaving a wake of useless HD DVD players behind it.
This history is relevant because as Apple and Google battled for smartphone supremacy, people sat back and waited to see which platform would dominate. This prevented other technology companies from embracing mobile as a strategic delivery model for all kinds of digital content. Had we the foresight to envision the “Bring Your Own Device” environment of today, complete with responsive/adaptive web design, we may be much further along the patch of mobile computing than we are.
It is certainly true with learning technology. Companies and solution providers alike are just now coming around to embracing mobile as a legitimate learning delivery method, nearly a decade after the first iPhone debuted. But the advent of HTML5 and responsive/adaptive web design has made it possible to create experiences that translate on any device, making the mobile operating system debate relatively moot.
Yet, there is a distinct difference between how Apple’s iOS and Google’s Android platforms work that is still creating problems. Even though we are about to see the 7th iPhone, all of Apples phones have essentially looked and worked the same way. That is because Apple makes the software and the hardware, allowing almost total homogeny.
Google, on the other hand, only develops the software. Multiple different manufacturers make Android handsets, and some run different versions of Android – even within the same manufacturer. These devices have also historically been physically different. There were keyboards, buttons, trackballs, rockers, fingerprint sensors, etc. And just to muddy the waters further, handset manufacturers and mobile network carriers are able to create their own versions of Android. All of this leads to fragmentation – the fact that the Android experience can vary widely from one device to the next. This led to iPhones becoming the standard corporate handset, even while Android was dominating the consumer market. Companies like standardization for security and simplicity. Apple provided that.
Times have changed a bit, but despite the relative homogenization of Android devices regardless of manufacturer (they all essentially physically look and work the same way at this point) and the advance of multi-device authoring, fragmentation still rears its head for Android.
Salesforce.com – probably the best known corporate cloud-based technology – just announced it will only provide support for very specific Android devices. If you do not have a Samsung Galaxy handset or one of Google’s Nexus devices (handsets built by select manufacturers to Google’s specs, running a “stock” Android experience), you will still be able to install the Salesforce app, but won’t get any bug/glitch support.
With a powerhouse like Salesforce taking this stance, it could lead others to follow. It can be resource intensive to develop and test software to make sure it works on the endless myriad of Androids available. This position allows Salesforce.com to free up valuable development time, without really losing much in terms of customer loyalty.
This could bring in a new era when developing for Android could become much more streamlined. However, it could also have enough impact to change “Bring Your Own Device” to “You Better Have One of These.”