idcThe Android Operating System (OS) has a larger share of the smartphone market than any other OS. Recent reports from IDC give Android a world-wide market share of over 80%. If you are developing for the growing market of mobile users, it is a platform you must consider. But, even with that overwhelming market share, there are a number of issues to consider in developing for Android. They are certainly not “showstoppers,” but they do require experience and thought before you begin your project.

One of those issues is “market fragmentation.” Simply put, there are a lot of active devices running a lot of versions of Android. Each of those versions is different and in most cases, it is specific to the device it runs on to some degree. The reason is simple – each carrier uses one or more manufacturers and each manufacturer has its own set of features in each device they market, based on their own standards. So, as an example, the tilt and accelerometer features in one device may have a different set of actions than others that is addressed in a slightly different way. Add that to the fact there are many form factors, from small to large, in the market with different screen sizes and ratios.  This gives buyers a lot of choices, at many price points, but for application developers – the situation can be daunting if their goal is to reach a very large market share with early releases.

opensignalsized

Device Fragmentation, Credit: OpenSignal – 2015

Open Signal released its latest Android Fragmentation report in August and it shows how this problem plays out in the market very well. Every little box in their chart represents the market share of a different device over the past year. This is based on active devices detected by their service, not sales reports from manufacturers or carriers. The report shows over 24,000 unique devices were detected over the past year.

A few points to consider:

  • At the brand level, Samsung is the market leader, but the market share it represents on the Android platform is steadily dropping. It now represents over a third of the market, but within that share, the active devices from Samsung are a fragmented market of their own.
  • At the next level of market share, LGE, Sony and Motorola each have about the same number of active devices in the field and together they, again, represent a number of different devices, form factors and feature sets.
  • The charts in the Open Signal report only hint at the difference when the problem is looked at across carriers and within national geographies. Some carriers may be more liberal about allowing OS updates, but most have versions of the OS they release with the phone “locked down” to some degree. Users can’t update to more current versions and quite often, are not given access to the latest security updates on their device. At the national level, the networks available in different areas may not support some features (like geolocation) to the same degree or at all. And in different markets, buyers will favor different smart phones, carriers, plans, and have different buying habits when it comes to upgrading their phones.

Given the situation, you would be forgiven if your first impression was that it is impossible to conquer this market with anything approaching a majority share, even in a limited geography. And you can begin to see why app developers try so hard to have their apps distributed with a device or in a carrier OS build, instead of flinging it out the door and hoping it lands in front of users that might not only want it – but who can use it on their device. How does anyone compete successfully in this market?

Know Your Market – and Limitations

To get the most recent experience I could, I spoke to our project managers and developers who are working or have worked on mobile applications recently. They reported pretty much what you might expect. New clients, with little experience in developing mobile apps, often came in with a list of Android OS versions they wanted to be able to address, features from device capabilities they believed their users would need, and in some cases, mockups to specific device form factors. But… few to none of these specifications were based on a survey of core target market users who would actually get value from the application.

Here’s the problem:

  • Each device and OS version you want to cover has a cost in development and testing effort. In some cases, bugs may not be exposed until the application is put into the field and variations in OS builds from carriers are exposed. The more width you want to cover in the marketplace, the higher the complexity and cost of your application will be. There will come a point, when covering a specific segment of the market will not yield enough return to cover the effort.
  • Once your app is in the field, as new devices are brought to market or your market reach increases, new issues can crop up. Support and its connection to application maintenance becomes a large factor and as your user base shifts to new devices or to a broader segment – you have to keep in constant touch with them to continue to be successful.
  • You have to have some insight, or at least be able to make some intelligent decisions based on your limitations, what your devices and carriers target users have, what their buying habits are and how long it might be before a significant number of them adopt your app, before you begin development.

What is our recommendation? Go Lean.

If you are not aware of it, Lean Software Development came about to meet exactly these problems and it is the method we advocate in mobile application development with our clients. It is based on the Toyota Lean Production system and agile software development methodology, with seven basic principles that address the types of issues we face in the mobile market:

  1. Eliminate Waste: Don’t spend time developing features or addressing groups of users you don’t know will have value in the end application. This usually leads a beta release of what is referred to as the Minimum Viable Product (MVP) – the product that will have the highest return on investment versus risk. This implies having a group of target users who can validate your assumptions and help you see opportunities for providing them greater value early in the development cycle.
  2. Amplify Learning: This depends on two factors – early testing in the development cycle to ensure time spent is expended on workable code and early user validation to assure the effort is producing actual value for users. The use of agile methodologies and continuous, test-driven development are key factors – but there is nothing that can substitute for actual customer feedback during the development cycle to the product owner and development team.
  3. Decide as Late As Possible: Prioritization of complex and effort consuming features along with agile approaches to the breakdown of functional components in iterative development cycles improves flexibility and lowers risk in development. It allows the development team to expose parts of a proposed feature early and ask users what functions would increase value for them – without the cost of actually building the “complete” function. Once the outlines of the functionality are understood, they can be put into a mock-up that will take the validation to the next level, with as minimal amount of effort. These steps continue to lower wasted effort and increase learning with less risk.
  4. Deliver as Fast as Possible: Incremental, iterative development using agile makes it possible to get functionality in front of users in small, regular releases they can see and give focused feedback on. As with the other elements of this approach, this is linked to all the other parts of the methodology – not a standalone. Rapid, incremental releases without feedback is nice to have, but it does not validate the team is on the right track.
  5. Empower the Team: In a typical organizational relationship, managers and clients tend to assign work and expect the development team to complete assignments without question.  In an agile team, individuals are expected to make commitments to tasks and to raise issues and impediments that could have an impact on their ability to meet their commitments. Teams are also expected to look for opportunities to increase their ability to deliver value efficiently, even when they take a somewhat different approach. Empowering them to pass this feedback on gives product managers a better view of what is possible and warns them of issues before they impact releases.
  6. Build Quality In: Quality in this sense is much more than a lack of “bugs.” It covers the integrity, the usability, and the sense of purpose that carries from the user interface, through the workflow and to the entire user experience using the application. Again, continuous, automated testing is key but at this level coverage and integration are critical. There should not be three ways to accomplish the same thing in different parts of the application. The user interface should have standards and common approaches that bring users to do the repetitive and ordinary tasks without thinking about them. These concerns have to be addressed early and continuously – they cannot be afterthoughts.
  7. See the Whole: Along with #6, this is a critical part of team interaction during development. Understanding what part a function plays in the application, the functions that depend on it, ones that are similar, as well as what the user is trying to accomplish is a contextual understanding of the whole.

How does this play out?

  • Early releases are generally for a very limited range of devices and OS versions that match the needs of a group of target users.
  • Early in the development cycle, much more time is spent on verifying user needs than trying to widen the device and OS version coverage.
  • When a viable application is released, that produces a level of value for users that they will stay with and advocate to others, making the application available to a wider market can be considered. But, even at that point, feedback from users continues to be critical and in most cases more effort continues to be spent on improvements and maintenance than adding more device coverage.
  • As new devices are released and users buy up to new models, some devices will fall below the level where they are viable to support. So, throughout the product lifecycle, decisions have to be weighted toward newer devices, versions and features. This keeps the application ahead of the competition, but it will inevitably leave some users behind. The important point in this is to keep users clearly informed about what is supported and when it is likely to reach “sunset” so users can plan.

The point of this article is to open the discussion about how to deal with the fragmentation of Android, not how to run a lean, agile software development project, so I won’t go deeper at this point. I think you should be able to see the outlines. Naturally, Scio is an avid practitioner of the methodology, not because it is cool or the latest thing, but because it helps our customers be successful – part of our DNA. Let us know if we can help you with your mobile project – and to find a more practical approach to product development for mobile applications.