In my previous post on this topic, I discussed how iOS has emerged as the de facto standard for mobile. While fragmentation remains in the HTML5 context of iOS, the platform has evolved to a state that every publisher must have a presence. Given the support of HTML5, the maturation of the native application ecosystem, and forward-looking capabilities such as AirPlay, iOS should remain the focal point of a publisher's mobile strategy.
iOS doesn't have the largest platform. iOS doesn't have the fastest growth.
So what about the rest? What about the trusty feature phone? [RIP, dear RAZR; I annoyed every New York City cab driver watching three-minute clips on V CAST during my cord-cutting years].
Best in Breed: Native Applications on Android 4.x
No one likes to be second, though Android seems to have adopted Avis' now defunct motto of "We try harder." No one can dispute the broad adoption of Android devices on a global basis (800MM+), activation rate (over 1MM/day), the growth of native applications (700K+), or the ability to support potential game changers such as Facebook Home. The Android ecosystem suffers from the harsh reality of fragmentation, though, and not only by Android OS but also by the hardware (e.g., performance, video protocols and encoding profiles). And, yes, Facebook Home works only on some devices.
What about Mobile Flash?
Even though mobile Flash was an option, performance had always been lacking. With the ashes of mobile Flash still warm, publishers that require adaptive bitrate streaming should move to a native application strategy.
But HTML5 Works ... Doesn't It?
For publishers that only need to deliver baseline video via progressive download, HTML5 is an option - albeit with a considerable amount of effort to workaround the fragmented experiences due to event and logic inconsistencies - for a mobile Web experience.
However, most publishers will want to support adaptive bitrate streaming and content protection (e.g., encryption) to some degree. The most obvious desire is to utilize the existing HLS encoding and delivery workflow. Android 3.x supports only limited HLS and its market share is insignificant at best. HTML5 and HLS on Android 4.0, 4.1, and 4.2 is still problematic. Not only is video still limited to baseline profile, but there remain enough playback issues that HTML5 and HLS on Android is not a viable choice in context of consistent and reliable advertising, measurement, and playback. Publishers should only consider this approach with extreme caution and expectations of hardship.
Publishers need to be on Android, but only native applications will provide the flexibility and control most publishers need to create a compelling video experience for their users. While non-Android 4.x still commands a healthy audience, publishers should focus on Android 4.x from performance and playback perspectives - building for the leaders, not the laggards.
Additional Thoughts
A number of third parties have developed proprietary libraries that support HLS on Android 2.x devices. Publishers should think carefully about this option as the cost premium may not justify the audience. But for those that have the will and the budget, it's a desirable approach.
Additionally, Adobe AIR is another alternative for providing adaptive bitrate streaming for native Android applications (and other platforms as well). This has the benefits of leveraging existing Flash-oriented skill sets and infrastructure, but the dependency on Adobe should be considered.
Netflix recently announced support for DRM-protected content in an HTML5 environment via "HTML5 Premium Video Extensions:" Media Source Extensions, Encrypted Media Extensions, Web Cryptography API. It's refreshing for the industry to see a powerhouse such as Netflix flex its innovation muscles for the benefit of all. Given this is only supported on the Samsung ARM-Based Chromebook, time will tell whether this can grow broadly and fight the weeds of fragmentation.
Second Class Citizens: Put Them in the Corner
After iOS and Android (native apps), there are a handful of platforms that sit decidedly on a clear second tier. It may seem painful to ignore these audiences, but unless there is a clear and compelling business reason (e.g., a platform may offer "incentives"), these mobile platforms have decreased value due to their declining audiences or their nascent status: Android (HTML5, 2.x native applications), Blackberry, Nokia, Windows Phone 7, Windows 8, and all feature phones.
There Can be Only One (or Two)
It's no surprise that iOS is the mobile platform of choice. Based on the consumer expectations for iOS (and its maturity as an app ecosystem from the perspectives of the developer, publishers, and end user) and the growth potential for Android (despite its fragmented landscape), mobile strategies will not be effective without these native application cornerstones. Everything else should be considered with the requisite level of expectation, whether it's the reduction of audiences due to a platform evolution (e.g., Android 2.x), the potential end-of-life of a platform (e.g., Blackberry), or an X-factor such as Windows 8. Despite the billion plus dollars in advertising for Windows 8, adoption has been light, and only time will tell if the demographics are compelling (or will it be dominated by corporate?) and if the platform opens up to supporting HLS (similar to the Xbox, after a lengthy delay) or DASH.
Until then, publishers will need to make the hard and smart decision to play favorites. Parity of mobile platforms doesn't exist today, and to delight the consumer, publishers will have to leverage the device platforms that offer an ecosystem with the greatest and most mature capabilities rather than settling for the lowest common denominator.
The long tail is alive and well, but for those publishers that must make compromises when budgeting their digital dollar, mobile is a game of keeping up with the digital Joneses. iOS is now table stakes, and Android is not far behind. The feature phone is dead - long live the (iOS) tablet.