Fragmentation of Mobile Applications


It can take up to nine months to deploy an entertainment (mobile) application, But that's the duration of a cell phone in this market.
-Craig Hayman, IBM (source).


Fragmentation is the inability to "write once and run anywhere". This article analyzes various aspects of fragmentation of mobile applications (sometimes called device fragmentation), such as the reasons behind it, the current state-of-the-art in tackling it, and the directions we can expect it to evolve in the future. The article is intended for both practitioners and academics seeking a reasonably in-depth understanding of fragmentation in mobile applications.


What is it?

Fragmentation is the inability to "write once and run anywhere".  More formally, it is the inability to develop an application against a reference operating context (OC) and achieve the intended behavior in all OCs suitable for the application.  An operating context (OC) for an application is the external environment that influences its operation. While fragmentation can affect any type of application, in this article we focus on the fragmentation of mobile applications. Note that by "mobile applications" we mean installed applications, not SMS applications or Mobile Web applications.

Causes of fragmentation

Fragmentation stems from the diversity in OCs, which can be classified as follows:

As we can see from the above, one OC can differ from another due to many factors. Let us call these factors fragmentors.  i.e., a fragmentor is a factor, diversity of which causes fragmentation. 

The fragmentation of mobile applications is often referred to as device fragmentation, because most of the fragmentors can be traced to a particular device model. However, this is a misnomer, as fragmentation can be caused by fragmentors outside the device (e.g., branding by carrier).

Why should we care?

Application users, developers, content providers and distributors, network operators and device manufacturers are all affected by fragmentation. Here, we look at how fragmentation affects an organization developing mobile applications.

Fragmentation complicates all disciplines (disciplines as defined in the IBM Rational Unified Process) of a mobile software project. Some examples are given below.

As a result of these complications, fragmentation increases the required effort in almost all aspects of software life cycle, driving up the cost, and lengthening the time-to-market. Other side-effects are:

What can we do about it?

In the current state of the practice, it is almost impossible to write a single version of a mobile application that can run on every (or at least a majority of) mobile device available. Practitioners say that sometimes one can end up having 400 or more different versions for a single application [source: De-frag2006]. It is also generally accepted that fragmentation is a complex issue that cannot be solved easily, or completely [sources: De-frag2006, JW2004]. Since it is the diversity that drives fragmentation, a closer look at diversity may provide us with clues as to how to deal with fragmentation. Diversity can be thought of as belonging to one of the two types below.

Above analysis hints that one approach to reduce fragmentation is the elimination of accidental diversity. Measures such as better standardization (e.g., less optional APIs, more detailed specifications), stricter enforcing of the standards (e.g., using API verification initiatives, Technology Compatibility Kits) can help in this regard. Major players in the mobile application industry (such as platform vendors, device manufacturers, and operators) have a critical role to play in this front of the war against fragmentation. Such an effort in the Java ME arena is the Mobile Service Architecture (see  [MSA] for more info).

On the other hand, essential diversity is here to stay. The pragmatic response here is to find ways to reverse the resulting fragmentation. Let us call this de-fragmentation. Note that de-fragmentation is NOT eliminating diversity. Rather, it is the process of making the application behave as intended, on all target OCs.

A quick guide to the rest of this document

Different approaches to de-fragmentation

This section summarizes how today's mobile developers go about de-fragmenting applications. Click here for a more detailed version of this section, with graphical illustrations of each approach.


The most primitive de-fragmentation technique is by manually developing distinct versions to suit each different OC. Let’s call this approach MANUAL-MULTI. These distinct versions will be largely similar, but also different in subtle ways, in response to subtle variations in the OCs. Copy-paste-modify techniques are commonly used to “port” the application to various OCs.

MANUAL-MULTI approach results in duplication of work , thereby increasing the required effort in many aspects of software development (e.g., imagine fixing a bug in 400 different versions!). There are two alternatives that try to minimize such extra effort:
1. Derive OC-specific versions from a single code base (DERIVE-MULTI)
2. Use a single version to serve multiple OCs (SINGLE-ADAPT)


In this approach we derive OC-specific versions from a single code base. This derivation may happen in three ways: selective packaging, using meta-programming, or using a domain-specific generator.

a) Selective packaging (SELECTIVE): Variations are localized into interchangeable components (e.g., classes, files, etc.). A build script (or a linker) creates one version for each OC, picking out only the components required for that particular OC.

b) Using meta-programming (META): This approach uses meta-programming (and similar code manipulation techniques) to specify how to derive OC-specific versions of the application. There are two ways of achieving this: the EMBED approach and the INJECT approach.

The EMBED approach embeds OC-specific variations in the source files using meta-programming directives/tags. A preprocessor derives multiple versions by processing these directives/tags.

The INJECT approach requires the developer to write the OC-specific instructions separated from the application code. A preprocessor combines the generic application code with the OC-specific instructions to derive OC-specific versions.

c) Automatic generation (GENERATE): In this approach, multiple versions are automatically generated by a generator that knows how to adapt a software (written in a generic way) to suit a specific OC. Instead of merely following directives embedded by the programmer, generator uses its inbuilt knowledge in the generation process, requiring less manual coding than the META approach.


The essence of this approach is that we build a single version that can work on multiple OCs. This approach can be further sub-divided into two: FITS-ALL and ALL-IN-ONE.

a) FITS-ALL: Develop a one-size-fits-all application that sidesteps all variations between OCs. There are two ways to accomplish this:

i) AIM-LOW: Use only the features supported in the same way in all OCs. For example, the UI will be designed to fit the smallest screen size of the targeted device range. This approach is sometimes referred to as the "lowest common denominator" approach.

ii) ABSTRACTION-LAYER: Use an abstraction layer that hides variations. The application will be developed using the API of the abstraction layer.

b) ALL-IN-ONE: Make the software adapt at run-time to a given OC, using one of the following two techniques.

i) SELF-ADAPT: The application discovers information about the OC and adapt itself to the OC at run-time

ii) DEVICE-ADAPT: The software is written in an abstract way, and the device decides how to adapt it to the prevailing OC, at run-time. This approach is commonly applied when dealing with fragmentation in the UI part of an application.

Other facets of the fragmentation problem

Fragmentation in traditional applications

Arguably, traditional applications (i.e., desktop applications, web applications/sites) have to deal with more diversity in OCs than mobile applications. For example, if resizing is allowed, a traditional application can have many more screen sizes (here, screen size = area occupied by the application) compared to available screen sizes in mobile devices. However, one does not hear about an equivalent of a fragmentation problem in the traditional application domain. Possible reasons for this include:

Fragmentation and product lines

While we do not hear about a fragmentation problem in traditional applications, we could still end up with multiple versions of a traditional applications, called a product line. Some de-fragmentation approaches also result in mobile application product lines (MAPL for short). However, MAPL could be different from a traditional product line in the following ways.

Issues: Should we treat MAPL different from a traditional product line? What lessons can we learn from traditional product line world that we can apply to an MAPL?

Fragmentation in the Mobile Web and SMS applications

The Mobile Web is the Internet (both web sites and web applications) as accessed from mobile devices connected to a public network. Web site contents (usually in XHTML or WAP) may get fragmented, due to diverse display capabilities of devices. Mobile-Web applications, when compared to non-Web (i.e., local) mobile applications, has the advantage that most of the processing is done on the Web server, unaffected by the diversities in the OC. The application UI still operates on the device, and prone to fragmentation just as any other mobile application. Since the UI is generated by the Web server on-the-fly, a mobile-Web application has the option to use a run-time form of the DERIVE-MULTI approach, where the OC-specific version is generated on-the-fly and sent to the device. One interesting avenue to explore is the applicability of UI=Markup+Stylesheet approach used in Mobile-Web to manage UI fragmentation in local mobile applications.

SMS applications too live on the server-side, accessed via SMSes sent from phones. Therefore, the fragmentation of SMS applications is less compared to installed mobile applications.

Java Vs non-Java applications

Theoretically, a Java ME application is able to run on any Java-enabled mobile device. This means a Java ME application can target a much wider range of OCs as compared to non-Java applications, making it susceptible to more fragmentation. In addition, the "freedom for differentiation" (which is not entirely a bad thing) allowed in Java ME world is another reason behind the high-level of fragmentation of Java ME applications.

As non-Java platforms (e.g., Symbian) are created for a smaller range of devices, platform vendor can have tighter control over aspects such as implementation diversity, reducing the fragmentation within the platform. However, developers may still have to develop a Java ME equivalent as well, if a wider range of OCs is to be targeted. Another problem area for non-Java applications is that unlike Java ME applications which run on an abstract virtual machine,  non-Java applications directly access the underlying firmware/hardware, and could fragments more due to diversity in the hardware/firmware.

Fragmentation in the Android platform appears to be less at the moment, but this could be simply because it is not yet used in a wide range of OCs. The Open Handset Alliance (OHA), who is backing Android, have signed a "non-fragmentation agreement" [source]. Depending on the details of this agreement, this could stop various implementations of Android being incompatible, taking away one of the causes of fragmentation (I stress, just one) .

Future of the fragmentation problem

These are some of the observations that might affect how we face the fragmentation in future:

What others say...

Here are some notable/interesting opinions about fragmentation, voiced by those interested in the problem...

From the panel discussion at Java mobile and embedded developer day session [JMEDD08]:

"Part of our skill set as a company is that we understand and can deal with fragmentation issues. This is for both application development and the provisioning side of things but it still drives me mad. Sometimes the choices the manufacturers and network operators make seem retarded and I end up very frustrated."
          --From the blog: Jason Delport's Mobile Observations

... this guy stood up and said "but... err, some of us have a real business based on and thanks to fragmentation"
          -- C. Enrique Ortiz,  (in Jason Delport's Mobile Observations blog)

"Device fragmentation makes our products (not only games) a lot more expensive than say Web Flash Games. The energy we had to put into our porting solution and the extra work during development is at least as much as the raw game development time. Hence our pricing cannot compete with pricing for web development. Plus it is a huge, unnecessary hurdle for newcomers. Due to device fragmentation, setting up a store for mobile games and applications needs deep knowledge of the matters. It's not like everyone can create software and sell it through their homepage (or wap page). Also, most tried and tested concepts (shareware, demoware...) fail due to device fragmentation, the inability to copy free software from one device to another (which is again due to device fragmentation and to a certain extent to DRM locks) and an easy to use and fair worldwide payment system"
          --Reto Senn (Bitforge)

"One aspect I like about this document is the acknowledgment that device fragmentation exists, it is here to stay to a large extent and people from the academia can deal with it (instead of making believe that the problem does not exist as W3C has obviously been doing for 3 years now)"
          --Luca Passani (in Oxford University Next Generation Mobile Applications Panel)

"I like to remind myself why is fragmentation actually an issue;  Because it impacts on the developer's ability to make money.  If as a developer I could focus on a single handset that had sufficient volume, and get a decent price for my application that the end user is looking for, all would be great, and why would I care about fragmentation. (Some developers are doing this with the Series 60 environment) Or, if as a developer, I actually got to keep 50% of the revenues, rather than 10 -25% I might have a chance. Unfortunately, neither of these cases look like they will be changing anytime soon"
          --Richard Mardon (in Oxford University Next Generation Mobile Applications Panel)

" a typical development cycle, porting and testing can consume from 40 to 80 percent of your time, depending on your level of experience and on the number of devices you need to support."
         --Bruno Delb (in [DevXPP2006])

"... This problem (of fragmentation due to platform diversity) is not unique to Java ME – it exists in many other areas of the standards world – and the solution is well understood: an “umbrella specification” needs to be created that will define a minimum set of component APIs that must be included in compatible implementations and that will also eliminate optionality from the component specifications"
       --Patrick Curran (in [JDJMES08])

"... I think I've experimented with all the techniques. I personally think that the DERIVE-MULTI techniques are well adapted for one-shot products, like Games, while the SINGLE-ADAPT are more adapted to long term product that require constant evolution."  
      -- Thomas Landspurg (in TomSoft blog)

Tom Godber (in [TMF2008], on the importance of customization): "...For a professional installed application that will see frequent and prolonged use, optimizations are 100% critical to the project's success. The interface must react exactly how the user expects it to, looking and feeling familiar whilst also presenting an attractive, professional and branded appearance."

“Some mobile application vendors take a chance claiming compatibility with a wide range of devices, and then handle possible issues via technical support and free-of-charge software upgrades.”
    -- Anders Borg (in an email response to this article)

Related resources



1. This list is not exhaustive. If you know of another tool that should be in the list, please do let me know.
2. Above descriptions are based on the information provided by the website of the respective tools.

Online articles


Data sources

Some statistics



About this article

How it came about, and where it is going...

Originally, I wrote this article for the benefit of my students starting research projects in the area of mobile application fragmentation. In realizing the wider applicability of the article contents, I have now evolved it to a form intended for anybody with an interest in application fragmentation issues, but particularly for developers entering the mobile application development arena, and for researchers venturing into research in this area.

I plan to continuously evolve and expand this article as my research in this area progresses. Among other things, I plan to do a comprehensive evaluations of the tools/techniques currently used to manage fragmentation.

Giving feedback

I would love to hear from you about what you think about this article; Any tools/techniques/approaches/observations I have missed? Any point above you disagree with? Please follow this link to post your feedback, or to see what others had to say... All feedback will be gratefully acknowledged in the article.
You can also contact me directly at damith[at]


About the author

I'm Damith C. Rajapakse. I work as a lecturer at National University of Singapore, School of Computing. My research interests include various aspects of engineering mobile applications. My home page is

[share this on: Reddit |  Digg | |  Fark |  Slashdot |  Stumbleupon]

web tracker

[ - All rights reserved - Version 2.6 - 28th April 2008]