All Things Mobile

The Latest News & Knowledge

A Mobile Platform Analysis

Screen Shot 2013-02-13 at 1.51.58 PM






When a business or an individual makes a conscious decision to pursue a mobile application strategy a common assumption is that an app needs to exist on as many platforms as possible. In an ideal world, time, money, and human resources would be of no concern and it would be possible to create a native app that leverages the very best features and capabilities of each targeted platform.




In reality, we are all constrained by time, money, and human resources and we are forced to make objective decisions that will maximize our return on investment.



Web Apps



If true platform independence is a primary goal for your app you may want to consider a mobile website (web app); however, platform independence is not without disadvantages. The new HTML 5 standard makes it possible to develop fantastic web apps that run on a majority of mobile devices. Unfortunately web-based apps generally are not able to take full advantage of the features and capabilities of the mobile device itself such as accelerometers, gyroscopes, GPS units, local data storage and integration, and even user interface interaction.



Technological advances in mobile device CPUs, graphics processors (GPUs), memory, and other components have little to no impact on a mobile website or web app leaving most of the potential virtually untapped. Furthermore, mobile websites may be rendered differently depending on the mobile device or web browser making it difficult to fully control the user experience.



These factors lead to a “lowest common denominator” approach to web app development which compromises the user experience and results in an app with limited functionality generalized to run in as many browsers on as many devices as possible.



Native Apps



Conversely, native apps facilitate the best possible user experience by fully leveraging all of the device capabilities; however, it can be cost prohibitive to custom develop and maintain an app for every major mobile platform.



This forces many clients to make an objective decision about which platforms to target for their native apps. When selecting a platform to support it is important to maximize your reach while minimizing cost to achieve the greatest ROI.



Android



There are some significant platform differences between iOS and Android which impact the true reach, the cost of development & maintenance, product quality, and user experience.



For example, Apple Inc.’s proprietary sotfware development kit (SDK) ensures that with minimal effort an iOS app will run similarly on all iOS devices including iPhones, iPads, and iPod Touches.



The open source nature of Android’s operating system allows each mobile device manufacturer to create multiple devices with varying technical specifications and wireless carriers to customize the features of the operating system in order to achieve a competitive advantage. This creates a highly fragmented environment which is either non- existent or greatly reduced with iOS.



Release Fragmentation



When Apple releases a new OS version all supported devices have immediate access to seamlessly update the device to the new version through iTunes. Recent benchmarks show that nearly 90% of iOS devices run the current version of iOS. The remaining 10% are most likely comprised of jail-breakers who are constrained by the need for a jailbreak and/or unlock and must wait until a hack is publicly available.



With Android, updating the OS isn’t as seamless. The wireless carriers, not Google, have the primary responsibility for providing OS updates to devices. Since many carriers have customized and branded the standard Android release it may take a carrier months to update their custom branded version of Android, if they deem it worthy to do at all.



An unfortunate pattern has emerged in which carriers stop providing OS updates to users of low cost or older device models in an effort to migrate them to a newer device and/or sign a new contract. This renders many users “stuck” at a particular Android version until they purchase a newer device.



With five (soon to be six with the release of Honeycomb) major releases of Android this creates additional challenges.
A recent diagram released by Google shows the distribution of OS version usage. At the onset of Honeycomb (3.0), less than 1% of users are running the current version of Android (2.3). Slightly more than half of the users are one revision behind and another good majority are two revisions behind.



From a development perspective this forces us to choose which set of users to target: the majority or the current version. This may dramatically reduce your reach, increase your development and maintenance costs, and/or sacrifice user experience.



Hardware Fragmentation



Apple has designed the iOS software to operate specifically on the device in which it is running. However, Android’s open source approach allows it to run on many different devices. Different devices mean different CPUs, memory, screen sizes and resolutions, form factors, etc.



These differences combined with the number of different device offerings make it extremely difficult and very costly to properly design, develop, and test apps on all supported devices thus sacrificing user experience and quality.



Rovio, the maker of the popular game Angry Birds has struggled to keep its product functional on all Android devices. They have announced they will be creating a second version of the game targeting lower-end Android devices citing “severe performance issues”.



The makers of TweetDeck have released a pie chart illustrating the hardware fragmentation issue by showing the number of different Android devices running a particular version of TweetDeck.



Distribution Channel Fragmentation



Google’s Android Market is not the only Android “app store” in town. Verizon, Amazon, Sony, and others have announced plans to release their own versions of the market/ app store.



Having additional distribution channels further reduces reach and increases costs. All of these markets will have their own submission processes, DRM and licensing schemes, development agreements, support requirements, etc. Managing and submitting app updates to multiple stores will be no easy task for developers.



For users, shopping from multiple stores will require multiple accounts and payment methods. Users may be completely shut out of some stores while left favoring the perceived top two or three stores.



User Experience Fragmentation



With each new Android device, OS version, or marketplace the user experience is further diluted making it more and more difficult to reach as many people as possible and for as low cost as possible.
The various versions of the operating system and plethora of hardware devices with differing technical specifications make it a daunting challenge for developers to produce and maintain a quality software product.



The ability of each device manufacturer and wireless carrier to alter the user experience through hardware or software differences results in an inconsistent user experience when using the same app across multiple devices.



Screen Shot 2013-02-13 at 1.55.00 PM



Decision



We are often asked to develop for Android, Blackberry, and other mobile platforms. Since we have a finite number of resources available we too must make an objective decision as to which platform we will invest our talents in and which platform will benefit clients the most.



Currently we target only the iOS platform which has the largest global presence and volume of users with the widest demographic giving you access to the most customers possible. We also believe the iOS platform provides a better user experience and is the most cost effective to develop and maintain. Simply put, the iOS platform provides the best return on investment.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>