COMPARING CROSS-PLATFORM DEVELOPMENT

APPROACHES FOR MOBILE APPLICATIONS

Henning Heitkötter, Sebastian Hanschke and Tim A. Majchrzak

Department of Information Systems, University of Münster, Münster, Germany

Keywords:

App, Mobile application, Cross-platform, Multi-platform.

Abstract:

While smartphones are rapidly gaining popularity, they do not (yet) rely on a standardized platform. At least

ﬁve operating systems are considered important. Developing mobile applications (apps) is thus challenging.

Since native development for several platforms requires extreme effort, we designed criteria to assess cross-

platform development approaches. We applied our criteria to Web apps, to apps developed with PhoneGap

and Titanium Mobile, and – for comparison – to natively developed apps. Particularly the two frameworks

are interesting from a Web developer’s perspective since they bridge the gap between Web development and

mobile information systems. Our ﬁndings are presented as reference tables. Furthermore, we generalize our

results. Our criteria have proven to be viable for follow-up evaluations. With regard to the approaches, we

speciﬁcally found PhoneGap viable if very close resemblance of a native look & feel can be neglected.

1 INTRODUCTION

Smartphones, i.e. mobile phones combining a range

of different functions such as media player, cam-

era, and GPS with advanced computing abilities and

touchscreens, are enjoying ever-increasing popularity

(Gartner, 2011). They enable innovative mobile infor-

mation systems, often referred to as apps. However,

the market of mobile operating systems for smart-

phones is fragmented and rapidly changing. Accord-

ing to Gartner (2011), Google’s Android, Nokia’s

Symbian, Apple’s iOS, and RIM’s Blackberry all

have at least a 10 % market share, with Microsoft’s

Windows Phone expected to increase in popularity as

well. As all platforms differ signiﬁcantly from each

other, software developers that want to reach a large

potential audience of users would be required to de-

velop their apps for each platform separately.

Cross-platform development approaches emerged

to address this challenge by allowing developers to

implement their apps in one step for a range of plat-

forms, avoiding repetition and increasing productiv-

ity. On the one hand, these approaches need to offer

suitable generality in order to allow provision of apps

for several platforms. On the other hand, they still

have to enable developers to capitalize on the speciﬁc

advantages and possibilities of smartphones.

Our paper analyses and compares existing cross-

platform approaches based on Web technologies like

HTML, CSS, and JavaScript. As these differ in their

general architecture and their capabilities, it is not ob-

vious which to prefer. We will outline criteria that are

important when making a decision as well as evaluate

the popular approaches mobile Web apps, PhoneGap

and Titanium Mobile according to these criteria.

Our work makes several contributions. Firstly,

it gives a comprehensive overview of current ap-

proaches for cross-platform app development. Sec-

ondly, it proposes a framework of criteria for eval-

uation. They are not only applicable in this paper

but can be used for future assessments. Thirdly,

we present a detailed analysis of the considered ap-

proaches. Fourthly, we discuss and generalize our

ﬁndings in order to provide decision advice.

This paper is structured as follows. Related work

is studied in Section 2. Section 3 gives an overview of

existing approaches. We then introduce our catalogue

of criteria in Section 4. The evaluation follows in Sec-

tion 5. In Section 6 we discuss our ﬁnding. Eventu-

ally, we draw a conclusion in Section 7.

2 RELATED WORK

Much related work can usually be identiﬁed for an ar-

ticle that compares various technologies. However, if

it deals with cutting-edge technology, the number of

similar papers shrinks dramatically. General papers

299

Heitkötter H., Hanschke S. and Majchrzak T..

COMPARING CROSS-PLATFORM DEVELOPMENT APPROACHES FOR MOBILE APPLICATIONS.

DOI: 10.5220/0003904502990311

In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 299-311

ISBN: 978-989-8565-08-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

Table 1: Criteria of the infrastructure perspective.

I1 License and Costs

This criterion examines whether the framework in question is distributed as free software or even open source, the license

under which it is published, if a developer is free to create commercial software, and whether costs for support inquiries

occur.

I2 Supported Platforms

Considers the number and importance of supported mobile platforms, with a special focus on whether the solution sup-

ports the platforms equally well.

I3 Access to advanced device-speciﬁc features

Comparison of features according to application programming interface (API) and Web site. Most frameworks support

standard hardware (e.g. the camera), hence more advanced hardware features like NFC (near ﬁeld communication) chips,

accelerometer, and the support of multi-touch gestures are evaluated.

I4 Long-term feasibility

Especially for smaller companies the decision for a framework might be strategic due to the signiﬁcant initial investment.

Indicators for long-term feasibility are short update cycles, regular bug-ﬁxes, support of newest versions of mobile op-

erating systems, an active community with many developers, and several commercial supporters steadily contributing to

the framework’s development.

I5 Look and feel

While the general appearance of an app can be inﬂuenced during development, it does matter whether a framework

inherently supports a native look & feel or whether its user interface looks and behaves like a Web site. Most users seek

apps that resemble native apps. Furthermore, this criterion tries to ascertain how far a framework supports the special

usage philosophy and life-cycle inherent to an app. Apps are frequently used for a short amount of time, have to be

“instant on”, and are likely to be interrupted, e.g. by a call. When returning to the app, a user does not want to repeat her

input but wants to continue where she left the app.

I6 Application Speed

Tries to compare the application’s speed at start-up and runtime, i.e. its responsiveness on user-interaction. For evaluation,

instead of measuring the performance, we assess the subjective user-experience.

I7 Distribution

Evaluates how easy it is to distribute apps created with the respective framework to consumers. One part is the possibility

to use the app stores of mobile platforms, since client’s often want to use this distribution channel. However, solely

relying on app stores also has disadvantages; a framework offering additional channels also has merits. Furthermore, this

criterion assesses whether updates are possible.

on the technologies dealt within this paper are cited

in the appropriate sections, particularly in Section 3.

Thus, this section assesses existing work that com-

pares two or more approaches for cross-platform app

development.

Until recently, papers only discussed mobile plat-

forms – or rather operating systems – for mobile de-

vices. An example is the paper by Cho and Jeon

(2007). Comparison papers such as by Lin and

Ye (2009) only marginally help developing multi-

platform apps. The same applies to very specialized

papers. They usually rather concern the business per-

spective than deal with technology. An example is a

study of mobile service platforms (Tuunainen et al.,

2011). But even technically-driven papers that ad-

dress multiple platforms do not necessarily help to

develop cross-platform apps. For instance, a study of

smartphone malware (Felt et al., 2011) only roughly

hints to platform particularities.

Anvaari and Jansen (2010) havecompared the pre-

dominant mobile platforms with regard to the open-

ness of their architectures. Their approach takes a

very close look at one aspect and thus can be seen

as complementary with our work. Charland and Ler-

oux (2011) compare the development of native apps

and Web apps. In contrast to our approach, they do

not take a cross-platform perspective.

A comparison of iPhone and Android develop-

ment is presented by Goadrich and Rogers (2011).

Despite the topic, which is similar to our work, their

aim is different. In fact, they try to answer which

platform should be used for the education of students.

Another study deals with mobile cloud apps (Laksh-

man and Thuijs, 2011). While the authors deal with

cross-platform development, they focus on native thin

clients that access cloud services.

A number of publications address more than one

platform (David, 2011; Anderson and Gestwicki,

2011; Firtman, 2010). While these publications fos-

ter a better understanding of the platforms, they do

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

300

Table 2: Criteria of the development perspective.

D1 Development environment

Evaluates maturity and features of the development environment typically associated with the framework, particularly

the tool support (IDE, debugger, emulator) and functionalities like auto-completion or automated testing. The term “ease

of installation” summarizes the effort for setting up a fully usable development environment for a framework and a

desired platform.

D2 GUI Design

This criterion covers the process of creating the graphical user interface (GUI), especially its software-support. A sepa-

rate WYSIWYG editor and the possibility to develop and test the user interface without having to constantly “deploy” it

to a device or an emulator are seen as beneﬁcial.

D3 Ease of development

This criterion sums up the quality of documentation and the learning-curve. Therefore, the quality of the API and

documentation is evaluated. This part of the criterion is well-fulﬁlled if code examples, links to similar problems,

user-comments, etc. are available. The learning curve describes the subjective progress of a developer during his ﬁrst

examination of a framework. Intuitive concepts bearing resemblance to already known paradigms allow for fast success.

This can have a signiﬁcant impact on how fast new colleagues can be trained and how much additional, framework-

speciﬁc knowledge a developer needs to acquire.

D4 Maintainability

The lines of code (LOC) indicator is employed to evaluate the maintainability (Kassinen et al., 2010, p. 53f.). The choice

of this indicator is based on the assumption that an application is easier to support when it has less LOC, because e.g.

training of new developers will be shorter, source code is easier to read etc. While more sophisticated approaches could

also be justiﬁed as relevant indicators, these are hard to apply, especially in case of complex frameworks and for apps

composed of different programming and markup languages.

D5 Scalability

Scalability is based on how well larger developer teams and projects can be conducted using the respective framework.

Modularization of framework and app are highly important as this allows increasing the number of concurrent developers

and the scope of the app’s functionality.

D6 Opportunities for further development

Determines the reusability of source code across approaches and thereby assesses the risk of lock-in, which would be

increased if a project started with one framework could not later be transferred to another approach.

D7 Speed and Cost of Development

Evaluates the speed of the development process and factors that hinder a fast and straightforward development. Costs

are not explicitly estimated because they are taken as being dependent on the speed of development, assuming that one

can abstract from differences in salary of a JavaScript or Java developer.

not really compare the different approaches. Rather,

they explain how to use a technology on a multitude

of platforms or devices. Due to the high relevance for

practitioners, the topic is also recognized in technol-

ogy weblogs (Newman, 2011; Behrens, 2011). Al-

though such articles give valuable advice, they cannot

be compared to our structured approach.

3 OVERVIEW OF APPROACHES

When developing native applications, developers im-

plement an application for one speciﬁc target plat-

form using its software development kit (SDK) and

frameworks. The app is tied to that speciﬁc environ-

ment. For example, applications for Android are typ-

ically programmed in Java, access the platform func-

tionality through frameworks provided by Android,

and render its user interface by employing platform-

provided elements. In contrast, applications for iOS

use the programming language Objective-C and Ap-

ple’s frameworks. In case multiple platforms are to be

supported by native applications, they have to be de-

veloped separately for each platform. This approach

is the opposite of the cross-platform idea and will

serve as a point of reference in this paper. Users will

install native apps from the platform’s app store or

other platform-provided installation means. They re-

ceive an app that, by its very nature, has the look and

feel of the platform.

On the other hand, mobile Web applications (Web

apps) capitalize on the good browser support of mo-

bile platforms and the standardization of Web tech-

nologies. Using this approach, developers implement

their application as one Web site optimized for mo-

bile devices. The optimization has to account for the

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

301

Table 3: Evaluation of mobile Web applications – Infrastructure perspective. The last column denotes the grade.

I1 License and Costs

Fees may apply for using speciﬁc JavaScript frameworks. Although most of these are open-source (jQuery Mobile,

2011; Sencha Touch, 2011), there are some examples that require commercial licenses (Sencha Ext JS, 2011). Most

communities are very active and usually answer questions in community boards, which might be seen as some kind of

free support. Nevertheless, selling support packages is a typical business model for open-source software. Moreover,

costs may occur from hosting (storage and trafﬁc) a Web site.

I2 Supported Platforms

All smartphone platforms have their own native browser. Additionally, there are several alternatives, e.g. Mozilla

Firefox or Opera Mini. Hence, support of the different platforms does only differ in browser-quality. Most native

browsers use the WebKit library, but their implementations differ slightly resulting in minor variation of displaying the

user interface (Koch, 2009).

I3 Access to advanced device-speciﬁc features

JavaScript does not permit any hardware access on smartphones. HTML5 offers “WebStorage” to locally store appli-

cation data. This concept, however, is in most browsers limited to 5 MB (Pilgrim, 2011). Playback of video and audio

ﬁles and the use of multi-touch gestures are no longer a problem.

I4 Long-term feasibility

HTML, CSS, and JavaScript are well established techniques undergoing steady improvement and development. The

decision for a speciﬁc JavaScript framework can however turn out to be problematic because changing the framework

later-on is in most cases expensive. Nevertheless, there are some popular and wide-spread frameworks that can be

assumed future-proof due to a very active development, regular bug-ﬁxes, and a large community.

I5 Look and feel

The usage of native UI elements from within the browser is not possible; design and layout of apps depend on CSS.

There are several projects trying to imitate the design of a speciﬁc platform, e.g. CSS Theme for iPhone (2011). jQuery

Mobile does not follow this approach and manual work is necessary. CSS3 facilitates simple and fast development of

user interfaces. There are major differences in the usage philosophy of a Web site and an app. The browser can be

closed at any time and does not have to notify the Web site of this event. Whenever the users returns to a Web app, the

app should have memorized settings and input, which, thanks to HTML5, has become possible. By using a manifest

ﬁle (W3C, 2011), a Web site can request to keep an ofﬂine copy, concepts like WebStorage allow Web sites to save data

in the local storage.

I6 Application Speed

Due to the fact that a Web app has to be loaded via the Internet, launching the app may be slow. WebStorage and the

manifest ﬁle (as described in I5) limit this phenomenon to the ﬁrst start of an app. This is comparable to the installation

of a native app from an app store. At runtime, Web apps proﬁt from the fact that today’s smartphone browsers are

highly performance-optimized. Still, the authors’ experiments with this approach have shown that especially with a

high number of animations and large amounts of content an app can easily reach the limit of a smartphone’s CPU.

I7 Distribution

Distributing a Web app is simple. Users only need to know its URL and they will automatically get the most recent

version. Using app stores is generally not possible. One could package the Web app via PhoneGap or Titanium;

however, this is not permitted in Apple’s app store as there is no additional beneﬁt compared to loading it in a browser

(Apple, 2010).

different screen size and usage philosophy of mobile

devices. Support is provided by several frameworks,

e.g. jQuery Mobile (2011) or Sencha Touch (2011).

Due to the standardized technologies, the Web site

can be accessed in a similar way by mobile browsers

on all platforms. However, mobile Web apps cannot

use device speciﬁc hardware features such as camera

or GPS sensor. They usually cannot be installed on

the mobile device but are retrieved via an URL. Typ-

ically, these Web apps will at least partially look and

behave like common Web pages, differing in appear-

ance and behavior from the native UI elements pro-

vided by the platform.

To resolve the lack of hardware functionality but

to still satisfy the desire to employ common Web

technologies, hybrid approaches emerged as a com-

bination of Web technologies and native functional-

ity. The most prominent exponent of this approach

is PhoneGap (2011). PhoneGap was originally cre-

ated by Nitobi Software, which has been acquired

by Adobe (Adobe, 2011), and is developed as open

source under Nitobi’s leadership by a diverse commu-

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

302

Table 4: Evaluation of mobile Web applications – Development perspective.

D1 Development environment

There are several development environments for developing with HTML, CSS and JavaScript. They provide almost all

desired functionality such as auto-completion. Installing the software development kit (SDK) of the desired platform

is mandatory for the use of an emulator, although, for a ﬁrst impression, a desktop-browser might be enough. In

summary, the maturity of development tools is high. Software support for debugging and testing is excellent; in most

cases tools like Firebug (2011) can be employed in addition to a regular browser.

D2 GUI Design

Most tools for Web UI design offer WYSIWYG editors. These need to have special settings for e.g. display size and

resolution to be helpful when developing smartphone apps. As the Web app can rapidly be reloaded on the target

device without having to recompile it, GUI design is comparably fast.

D3 Ease of development

As the quality of documentation (again depending on the framework used) is very high and as concepts used in HTML,

CSS and JavaScript are intuitive, the ease of development is higher than with any of the other frameworks. Besides

having to know the underlying programming and markup languages (HTML, CSS, and JavaScript), a programmer does

hardly need any further knowledge. He has to be aware of characteristics and limitations of a smartphone (display size,

Web storage, limited CPU and GPU speed (Dornbierer et al., 2011)) and can then start developing.

D4 Maintainability

A good JavaScript framework enables short and elegant code. Functionality like sorting of data can sometimes be

inserted by using a single keyword. The underlying framework will then supply all necessary methods. The LOC

indicator for the prototype application was lowest for the mobile Web application.

D5 Scalability

Web apps in general can easily be split into a large number of small ﬁles that ﬁt into the overall design. This might

again depend on the framework employed. Project using jQuery, for example, tend to become confusing from a certain

size (Murphey, 2010), while others support modularization very well.

D6 Opportunities for further development

A project started as a Web app can easily be ported to PhoneGap if access to the native API should become necessary.

It might also be packaged with a WebView control in Titanium Mobile or as a native application, although both would

contradict the “native” character of these apps and not provide all of the advantages of these approaches. Altogether,

opportunities for further development are excellent.

D7 Speed and Cost of Development

In comparison to all other frameworks, developing the prototype as a Web app has taken the shortest amount of time.

Development tools are technically mature, debugging and testing and the design of the user interface can therefore be

carried out fast and cost-efﬁcient.

nity, including developers from major software ﬁrms

like IBM or Microsoft (About PhoneGap, 2011). Us-

ing PhoneGap, developers still employ the same set

of Web technologies to implement their application.

Additionally, PhoneGap provides a JavaScript API to

access hardware features. The Web pages are not

supposed to be displayed in a browser but packaged

with a speciﬁc engine. This engine displays the page

in a regular Web view and provides a bridge from

JavaScript to native functionality. This bridge routes

PhoneGap API calls to the corresponding native func-

tions. The PhoneGap engine is speciﬁc for each sup-

ported platform but the apps developed on top of

PhoneGap work cross-platform. They only need to

be packaged with the PhoneGap engine for each re-

spective platform. Users can install these apps like

native ones. As long as no additional measures are

taken, their look and feel resembles that of Web apps.

Appcelerator Titanium Mobile (2011) follows a

different approach. It does not use HTML and CSS

to create the user interface. Instead, the UI is im-

plemented completely programmatically. Developers

use JavaScript to build the interface and to implement

logic and data, extensively using the Titanium API.

The code is then packaged with Titanium’s engine. At

runtime, this engine interprets the JavaScript code and

creates the user interface. Similar to PhoneGap, apps

can then be distributed via app stores. However, their

look-and-feel resembles the typical platform appear-

ance more closely; the UI is made up of native ele-

ments. Titanium Mobile is a product of Appcelerator,

which leads development of the basic platform pro-

vided as open source (Titanium Mobile Open Source,

2011) and sells additional features and support.

The remainder of the paper will analyze and eval-

uate mobile Web apps, PhoneGap, and Titanium as

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

303

Table 5: Evaluation of PhoneGap – Infrastructure perspective.

I1 License and Costs

Both PhoneGap and jQuery Mobile are open source software (distributed under BSD/MIT, respectively GPL/MIT

license). Commercial software can be created free of charge. Nitobi, the company behind PhoneGap, earns money by

selling support packages from USD 25 to ≥ USD 2000 per month, including bug ﬁxes and private telephone support

(PhoneGap License, 2011).

I2 Supported Platforms

PhoneGap supports seven mobile platforms (iOS, Android, HP WebOS, BlackBerry OS, Windows Phone 7, Symbian,

Bada); apart from Web apps this is the highest number of different platforms. The amount of supported features differs

slightly, even among different versions of the same operating system. According to Nitobi’s roadmap full support of all

features is planned (PhoneGap Roadmap, 2011). As PhoneGap uses a WebView and the WebKit library to display the

user interface, JavaScript frameworks that are intended to be used in addition to PhoneGap need to work on WebKit.

This holds for the combination of PhoneGap and jQuery Mobile as analyzed here (Original Graded Browser Matrix,

2011).

I3 Access to advanced device-speciﬁc features

PhoneGap gives easy access to advanced device-speciﬁc hardware like accelerometer or NFC chips (so far, the latter

only for Android (PhoneGap Plugin NFC, 2011); NFC is not available for iOS). Using multi-touch-gestures is also

possible. Even more sophisticated functionality, e.g. scanning of barcodes, can easily be added via plugins.

I4 Long-term feasibility

As both PhoneGap and jQuery Mobile are comparatively young projects, with their ﬁrst version released in August

2008, respectively October 2010, long-term feasibility is hard to estimate. The acquisition of Nitobi by Adobe (Adobe,

2011), the support from IBM (About PhoneGap, 2011), becoming an Apache project (Apache Callback, 2011), and

regular bug ﬁxes and updates all are in favor of PhoneGap. The same can be said about the active community, which

can be seen in the numerous plugins and community boards offering support. This also applies to jQuery Mobile.

I5 Look and feel

In contrast to apps developed with Titanium Mobile or natively but similar to Web apps, PhoneGap does not use native

user interface elements. Using CSS to imitate the native appearance of a platform requires a high amount of manual

work. jQuery Mobile’s standard stylesheet tries to imitate the iOS look and feel but does not succeed completely. For

example, small icons tend to look pixelated on large screens. The life-cycle of an app is far better implemented in

PhoneGap than it is in Web apps. PhoneGap offers events that are triggered for all relevant changes in an app’s status,

e.g. pause or resume.

I6 Application Speed

Launching a PhoneGap app is fast and user interaction is smooth. Even a large number of tasks did not inﬂuence the

prototype’s performance, which is comparable to a native app.

I7 Distribution

Although Apple reserves its right to decline apps that are primarily Web apps, this does not apply to apps developed

with PhoneGap, insofar its API is used to access hardware or platform-speciﬁc features (MacFadyen, 2010). Hence,

PhoneGap apps and updates can in general be distributed via app stores.

cross-platform development approaches. These so-

lutions have been chosen because they are popu-

lar among developers

and represent different ap-

proaches to cross-platform development. Together,

they make up the largest part of the decision space

relevant when thinking about cross-platform develop-

ment for mobile devices. Native apps serve as a point

of comparison.

Other solutions and approaches not covered here

are, for example, Rhodes (2011), a hybrid approach

PhoneGap counts more than half a million down-

loads and thousands of applications built with the frame-

work (Adobe, 2011). Numbers from Appcelerator indicate

30,000 applications using Titanium (Appcelerator, 2011).

similar to PhoneGap, and model-driven approaches.

The latter category has not been included because ex-

isting model-driven solutions like iPhonical (2010) or

applause (2011) are still in early stages or not relevant

in general practice.

4 CRITERIA

In the following, we will elaborate on a list of cri-

teria for evaluating cross-platform development ap-

proaches. In Section 5, this set of criteria will be

used to compare and review the solutions outlined

in the previous section. The selection of these cri-

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

304

Table 6: Evaluation of PhoneGap – Development perspective.

D1 Development environment

As is the case with Web apps, the developer is not limited in his choice of a development environment when using

PhoneGap. However, not all IDEs offer auto-completion for PhoneGap’s API. PhoneGap Build is a service that

compiles an app for different platforms in the cloud, so that developers do not have to install the platform SDKs

(PhoneGap:Build, 2011). After providing the source of a PhoneGap app, apps are compiled and signed for all chosen

platforms and can easily be downloaded.

D2 GUI Design

As for Web apps, designing the graphical user interface can largely be done using a standard browser and WYSIWYG

editors like Adobe Dreamweaver.

D3 Ease of development

PhoneGap’s documentation is clearly structured. It provides numerous examples – in most cases one quick and one

full example – and in some cases mentions problems with speciﬁc methods on a certain platform. This is not the

case with the documentation of jQuery Mobile. Although it presents all elements and design options, hardly any code

example can be found, so that in most cases further research is required. Almost no further knowledge is required in

addition to these APIs.

D4 Maintainability

Except for additional code that accesses the hardware, hybrid apps do not require more lines of code than comparable

Web apps. Implementing our prototype with PhoneGap, we got the impression that the source code is short and clearly

structured, largely due to the use of jQuery Mobile.

D5 Scalability

The evaluation of Web apps with respect to this criterion applies without modiﬁcation. 2

D6 Opportunities for further development

A project using PhoneGap can, as long as no device-speciﬁc features are used, also be run as a mobile Web site. This

enables a company to reach even those customers that do not own a smartphone with an operating system supported

by PhoneGap or that do not want to download and install an app.

D7 Speed and Cost of Development

This is more or less equal to those of a Web app, with only little additional time required for implementing access to

hardware functionality.

teria is based on and has been inﬂuenced by various

sources. An initial set of criteria emerged from dis-

cussions with practitioners and domain experts from

small- to medium-sized software ﬁrms. They out-

lined their requirements for mobile development ap-

proaches. These have been augmented through liter-

ature research (“15 Most Important Considerations”,

2009; Pfeiffer, 2011; Lukasavage, 2011) and a com-

pilation of typical problems apparent in online de-

veloper communities. Furthermore, important experi-

ences regarding necessary features have been gained

from developing prototypical apps.

For a better overview, the consolidated list of 14

criteria has been structured into infrastructure and de-

velopment perspective. The infrastructure perspective

sums up criteria relating to the life-cycle of an app,

its usage, operation and functionality/functionalrange

(see Table 1). The development perspective covers

all criteria that are directly related to the development

process of the app, e.g. topics like testing, debugging

and development tools (see Table 2).

5 EVALUATION

We have evaluated the four solutions described in

Section 3 according to the criteria of Section 4. The

evaluation draws on an analysis of the solutions in-

formed by own research and experiences as well as

opinions from experienced developers. The expe-

rience was mainly gathered by developing a proto-

typical task management app employing all four so-

lutions. Typical problems arising when using these

solutions were compiled from observing the respec-

tive developer communities and completed the back-

ground information for the evaluation. In addition to

a textual evaluation, we assessed a solution’s fulﬁll-

ment of each criterion on a scale from 1 to 6, with 1

meaning “very good” and 6 “very poor”. This allows

for a quick overview. Due to space restrictions we

present the results in tabular form, with two tables per

solution, one for the infrastructure and one for the de-

velopment criteria, and summarize the main ﬁndings

for each solution in the following subsections. Sec-

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

305

Table 7: Evaluation of Titanium – Infrastructure perspective.

I1 License and Costs

While Appcelerator provides a community edition of Titanium Mobile free of charge and as open source, this edition

is limited in functionality. Additional functionality is available in proprietary, closed-source modules, which are only

available with a subscription, starting at USD 49 (Titanium Plans, 2011). Subscription packages include support, while

basic documentation is available in Appcelerator’s developer center. In general, the Titanium ecosystem is less open

than the other solutions.

I2 Supported Platforms

As of November 2011, Titanium supports iOS and Android. Blackberry support is in a closed beta state. Different

importance is given to various platforms, with iOS receiving the highest one. Consequently, a large number of API

methods are “iPhone only”. While this enables developers to use the latest iOS API, it harms cross-platform compati-

bility, as platform-speciﬁc code might be necessary in certain circumstances.

I3 Access to advanced device-speciﬁc features

Titanium’s spectrum of functionality can be compared to that of PhoneGap. As with PhoneGap, usage of NFC chips is

only possible via a plug-in, which, however, is still in development.

I4 Long-term feasibility

Appcelerator’s Web site explicitly mentions its large community with numerous developers and projects. Neverthe-

less, the community seems to be less active than PhoneGap’s. Some posts in Appcelerator’s bulletin board remain

unanswered for weeks. This might be explained by the comparatively less open nature of Appcelerator. Appcelerator

tries to embed current trends into their framework, e.g. using latest functionality of the operating systems. Updates

and bug-ﬁxes occur continuously. However, as Titanium Mobile is driven by a single company, the long-term outlook

depends largely on their corporate strategy.

I5 Look and feel

Instead of using HTML5 and CSS3, Titanium uses native UI elements to create an app’s user interface (Titanium Native

Apps, 2011). At ﬁrst sight this approach seems to be less intuitive. Even drawing a label or a button requires relatively

much knowledge (e.g. on compulsory versus optional arguments). Ultimately, creating a user interface that resembles

a native app requires far less time and effort than with Web apps or PhoneGap. The usage lifecycle of an app can easily

be implemented.

I6 Application Speed

At start-up, the Titanium prototype did not differ from those created with other frameworks. At runtime, our prototype

started to noticeable stutter as soon as many objects and thus a large amount of view elements had to be handled. As the

prototype is rather simple, programming errors can quite certainly be ruled out. It is more likely that this stems from

the interaction of operating system and Titanium’s JavaScript interpreter.

I7 Distribution

Titanium apps can be distributed via the different app stores without difﬁculty. 2

tion 6 draws a comparison between the solutions and

provides decision support.

5.1 Web App

Table 3 and Table 4 present the evaluation of mobile

Web apps as a cross-platform development approach.

Web apps can be accessed from all smartphones via

the platform’s browser. They are based on open and

mature standards and enable easy and fast develop-

ment. The disadvantage of this approach is its lack of

hardware access and that the look and feel resembles

Web sites. While Web apps can easily be accessed

via their URL, it is not possible to use the distribu-

tion and marketing facilities of app stores. This limits

their feasibility for commercial applications.

5.2 PhoneGap

Table 5 and Table 6 present the evaluation of Phone-

Gap 1.2 in combination with jQuery Mobile 1.0 as a

hybrid cross-platform development approach. Phone-

Gap offers generic access to device-speciﬁc features

on all major mobile platforms. Because it is based on

Web technology, development is only slightly more

complicated compared to Web apps. However, as a

consequence, the visual appearance and, to a lesser

extent, the behavior do not reﬂect a native look and

feel but rather that of a Web site.

5.3 Titanium Mobile

Table 7 and Table 8 present the evaluation of Tita-

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

306

Table 8: Evaluation of Titanium – Development perspective.

D1 Development environment

Using Titanium Mobile forces programmers to use Appcelerator’s IDE Titanium Studio, which is based on Eclipse. Ti-

tanium Studio is offered in a standard and a premium version: the whole functionality is only accessible to subscribers.

Debugging is one of the subscription features. As the IDE is especially tailored to Titanium, it offers auto-completion

for the whole Titanium API. Furthermore, Titanium Studio ships with a feature called “fastdev server”, which enables

developers to dynamically reload JavaScript source and resources from an external server, instead of recompiling and

deploying the application over and over again. As of November 2011, fastdev is only available for Android and has

some minor bugs, for example losing the connection between emulator and server, making a restart necessary (Tita-

nium Fastdev, 2011). Setting up the development environment for Titanium is straightforward but the platform SDKs

still have to be installed separately.

D2 GUI Design

Titanium Mobile does not offer a WYSIWYG editor to create the interface. Especially as Titanium uses native UI

elements and thus requires quite a lot of API commands, this would be useful and save time.

D3 Ease of development

The quality of Titaniums’s documentation is good. There are numerous, although minimalistic code examples. Never-

theless, initial progress and accustomization to the framework is relatively slow, as a high degree of framework-speciﬁc

knowledge has to be acquired.

D4 Maintainability

The prototype developed with Titanium has comparatively many lines of code. Anyhow, the app still remains main-

tainable as Titanium apps can easily be modularized

D5 Scalability

The aforementioned ability to easily modularize a Titanium app also enables better scalability. Separate ﬁles can be

included using Ti.include() and it is possible to have different windows run in completely separate JavaScript contexts,

even though passing data or objects between windows is quite slow.

D6 Opportunities for further development

Source code of apps written for Titanium, at most with the exception of an application’s inner logic, can in general not

be used with other approaches due to the fact that a large amount of Titanium-speciﬁc functions is used. This creates

dependencies on the future development of Titanium (compare I4).

D7 Speed and Cost of Development

Developing with Titanium requires a lot of framework-speciﬁc knowledge, and does therefore demand a lot of experi-

ence. The “fastdev” server is an interesting approach to increase speed of development. Still, especially as designing

the user-interface is only possible within an emulator or on a device, this cannot change the overall impression of a

slow development process.

nium Mobile 1.7.2 as a cross-platform development

approach. As its main advantage, apps built with Ti-

tanium Mobile inherently have the look and feel of

nativeapps. Titanium only supports iOS and Android;

the entire ecosystem is less open. Advanced features

often require a subscription. Developing apps with

Titanium requires a high amount of Titanium-speciﬁc

knowledge, which, together with the programmatic

GUI creation, slows down development.

5.4 Native App Development

Table 9 and Table 10 present the evaluation of native

development for Android and iOS. Apps developed

speciﬁcally for each platform using their APIs and

following their conventions inherently results in a na-

tive look and feel. However, this has to be done sep-

arately for each platform and thus does not represent

a cross-platform development approach. Abstracting

the results from the concrete platforms it can be said

that native developmentbeneﬁts from the best support

but requires very speciﬁc knowledge.

6 DISCUSSION

This section offers a synthesis of the evaluation and

provides general advice for choosing a suitable cross-

platform approach. Although native apps beneﬁt from

an optimal integration into the respective mobile oper-

ating system and good developer support, the analysis

showed that cross-platform approaches are a viable

alternative. As soon as mobile apps have to be devel-

oped for multiple platforms under tight budgets, with

small developer teams, and in a short time frame, a

cross-platform approach is necessary. However, these

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

307

Table 9: Evaluation of native applications for Android and iOS – Infrastructure perspective.

I1 License and Costs

Android is distributed as open source by the Open Handset Alliance led by Google under a combination of the Apache

Software License version 2 and GPL (Google, 2011). In contrast, iOS is only available in combination with Apple’s own

hardware and is published under a proprietary end user software license agreement, with some components distributed

under GNU GPL and Apple Public Source License. A membership in Apple’s developer program for at least USD 99

per year is necessary to be able to deploy apps to end devices or upload them to the app store (Apple, 2011; Chudnov,

2010). Both frameworks can be used to create commercial software.

I2 Supported Platforms

Developing apps natively requires to do so separately for each platform, because programming language and APIs

differ. Hence, this approach does not support cross-platform development.

I3 Access to advanced device-speciﬁc features

Access to device-speciﬁc features is not limited for native development. 1

I4 Long-term feasibility

Studies on the future of the smartphone market forecast that both operating systems will remain to be popular. Devel-

opers can rely on large communities, regular bug-ﬁxes and updates.

I5 Look and feel

Full support of the platforms usage philosophy and the employment of native UI elements are self-evident. By deﬁni-

tion, everything that can be done with cross-platform approaches is possible natively as well.

I6 Application Speed

The native prototypes are as fast as the prototype developed with PhoneGap. It might be surprising that they are not

faster, but this is likely due to heavily optimized implementations of the WebKit library allowing efﬁcient display of

Web pages.

I7 Distribution

Native apps can be distributed within the platform-speciﬁc app stores, taking into account the provider’s – especially

Apple’s – policies concerning appropriate apps.

approaches are more than a second-best alternative.

Developers might prefer using a cross-platform solu-

tion even in the absence of these constraints.

Mobile Web apps constitute an ideal starting point

for cross-platform, because they do not require ad-

vanced knowledge and enable developers to start im-

plementing the app right away. Web apps are a sim-

ple approach beneﬁting from good support by mobile

browsers on all platforms. Furthermore, they can be

easily ported to other cross-platform approaches.

As soon as device-speciﬁc functionality not avail-

able from within the browser has to be accessed or if

distribution via app stores is deemed important, other

approaches are necessary. Both PhoneGap and Tita-

nium Mobile fulﬁll these requirements. Their main

difference lies with the look & feel of apps developed

with these approaches. If it is a strict requirement that

an app’s user interface should appear like a nativeapp,

Titanium is to be preferred. However, Web apps or

apps built with PhoneGap merely tend to look slightly

different from native apps and more like Web sites,

which might even be desirable. This should be kept in

mind before postulating native look & feel as a must-

have, especially as the look & feel criterion (I5) is the

only one where Titanium performs better than Phone-

Gap. The main disadvantages of Titanium are that it

supports only two platforms – albeit the most impor-

tant ones –, its less open business model, and a more

complicated development process. Thus, if there are

no hard requirements regarding look & feel or if these

might be loosened, the evaluation showed PhoneGap

to be the preferable option for cross-platform devel-

opment.

However, these are only general guidelines that

have to be adapted and interpreted for each project in-

dividually. The results of our evaluation can be used

to support such decisions, for example in semi-formal

multi-criteria decision methods like the weighted sum

model (Fishburn, 1967). Basic decision support can

be obtained by weighing the criteria according to

the requirements of a given project and calculating a

weighted grade. Carefully interpreted and analysed

for sensitivity, the result might yield ﬁrst insights on

which solution best matches the requirements at hand.

7 CONCLUSIONS AND FUTURE

WORK

In this paper, we presented a comprehensive set of

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

308

Table 10: Evaluation of native applications for Android and iOS – Development perspective.

D1 Development environment

Android apps can be developed with any Java-enabled IDE. Most developers will probably use Eclipse with the corre-

sponding Android plugins. iOS developers require MacOS and Xcode. Xcode is available as part of Apple’s developer

program or from the app store for EUR 3,99. Both development environments are mature, although the “ease of in-

stallation” is slightly higher when targeting iOS provided there is access to Apple hardware, as no separate installation

of an SDK or plugin are required.

D2 GUI Design

Both Android and iOS come with a WYSIWYG editor, enabling user interface design without repeatedly having to

deploy to an emulator or smartphone. Especially the iOS editor is very mature, concepts like storyboards offer the

possibility to visualize and create large parts of the application without having to write a singe line of code.

D3 Ease of development

As expected, the documentation of both operating systems is very comprehensive and of high quality. Both provide

numerous examples. Getting-started guidelines support beginners, Google regularly publishes blog posts and develop-

ers can additionally resort to the very active community. Programmers that already know the underlying programming

language can progress rapidly although they need to acquire additional knowledge about the mobile operating system.

D4 Maintainability

In terms of LOC, both native prototypes are the most comprehensive. This is due to the very detailed and object-

oriented implementation with Java and ObjectiveC in contrast to the concise JavaScript code. As they use object-

oriented constructs and separate the code into classes, native apps are (in comparison) easy to maintain, although they

might appear to be more heavyweight than their pendants developed in scripting languages.

D5 Scalability

In both Android and iOS, program logic and GUI can easily be separated from each other. Furthermore, each view

of an app can be developed on its own. This and the object-oriented concept of classes enable development teams to

scale even better than with the other frameworks.

D6 Opportunities for further development

Code written for one native platform can in general not be ported to another platform. Due to different APIs this would

also hold if they used the same programming language.

D7 Speed and Cost of Development

Developing natively requires the highest degree of speciﬁc knowledge and experience. Particularly as an application

has to be repeatedly developed for every platform, costs of development are much higher than with cross-platform

approaches.

criteria for evaluating cross-platform development ap-

proaches for mobile applications. Results have been

compiled in tables, which can be used as references.

The following analysis of several cross-platform so-

lutions according to these requirements showed that

PhoneGap is to be preferred, unless the interface nec-

essarily has to resemble native apps as closely as pos-

sible. Mobile Web apps offer a quick and simple en-

try into cross-platform development. In summary, the

maturity of these approaches reveal that native devel-

opment is not necessary when implementing mobile

information systems. Even if only a single platform is

to be supported, a cross-platform approach may prove

as the most efﬁcient method due to its low barriers.

Low barriers are mainly owed to usage of Web

technologies. HTML, CSS, and JavaScript in align-

ment with Web paradigms are highly suitable for de-

veloping cross-platform apps because they are stan-

dardized, popular, reasonably simple but powerful

and well-supported. Combined with additional mea-

sures to utilize the special capabilities of mobile de-

vices, they fulﬁll the requirements of most mobile

scenarios. However, particularly for user interfaces

future research will have to scrutinize the current pos-

sibilities. Interfaces of games are an exemplary ﬁeld

where available approaches might fall short.

The list of criteria and the subsequent evaluation

was based on input from domain experts. This guar-

antees a high practical relevance of our work. Fur-

thermore, it hints at promising future improvements

in cross-platform development approaches for mobile

applications. Future research topics include

• keeping track with progress in mobile develop-

ment frameworks and reassessing existing tech-

nologies as the platforms evolve,

• checking whether Web technology can similarly

be used for application to different media,

• verifying our results empirically,

• observing how important device-speciﬁc func-

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

309

tions might become available through standard-

ized APIs,

• extending and proposing our framework for eval-

uations in similar contexts, and

• preparing to provide decision advice based on

companies’ requirements for app developers.

Our future work will speciﬁcally address the re-

ﬁnement and evaluation of our approach in close con-

tact with app developers.

ACKNOWLEDGEMENTS

This paper has been written in cooperation with

viadee Unternehmensberatung GmbH, Germany. We

would like to thank them for continuous support and

fruitful exchange regarding the development of mo-

bile applications.

REFERENCES

“15 Most Important Considerations” (2009). “15 Most

Important Considerations when Choosing a Web

Development Framework”. Retrieved Nov. 23, 2011,

from http://net.tutsplus.com/tutorials/other/15-most-

important-considerations-when-choosing-a-web-deve

lopment-framework/

About PhoneGap (2011). About PhoneGap. Retrieved Nov.

23, 2011, from http://phonegap.com/about

Adobe (2011). “Adobe Announces Agreement to Ac-

quire Nitobi”. Retrieved Nov. 23, 2011, from http://

www.adobe.com/aboutadobe/pressroom/pressreleases

/201110/AdobeAcquiresNitobi.html

Anderson, R. S. and Gestwicki, P. (2011). Hello, worlds:

an introduction to mobile application development for

IOS and Android. J. Comput. Sci. Coll., 27:32–33.

Anvaari, M., & Jansen, S. (2010). Evaluating architectural

openness in mobile software platforms. In Proc.ECSA

10 (pp. 85-92). ACM.

Apache Callback (2011). Apache Callback. Retrieved

Nov. 23, 2011, from http://incubator.apache.org/

projects/callback.html

Appcelerator (2011). Appcelerator Press Release Novem-

ber 1, 2011. Retrieved Nov. 23, 2011, from http://

www.appcelerator.com/ 2011/ 11/ appcelerator-raises-

15-million-in-funding/

Apple (2010). iOS Overview. Retrieved Nov.

23, 2011, from http://developer.apple.com/library/ios/

#referencelibrary/ GettingStarted/URL_ iPhone_ OS_

Overview/ index.html

Apple (2011). iOS Developer Program. Retrieved Nov. 23,

2011, from http://developer.apple.com/programs/ios/

Applause. (2011). Retrieved Nov. 23, 2011, from https://

github.com/applause/

Behrens, H. (2011). Cross-Platform App Development for

iPhone, Android & Co. Retrieved Nov. 23, 2011,

from http:// heikobehrens.net/2010/ 10/11/cross-plat

form-app-development-for-iphone-android- co-%E2

%80%94-a-comparison-i- presented- at- mobiletech

con-2010/

Charland, A., & Leroux, B. (2011). Mobile application de-

velopment: web vs. native. Commun. ACM, 54, 49-53.

Cho, Y. C., & Jeon, J. W. (2007). Current software plat-

forms on mobile phone. In Proc. ICCAS

07 (p. 1862-

1867).

Chudnov, D. (2010). A mobile strategy web developers will

love. Computers in Libraries, 30(4):24–26.

CSS Theme for iPhone. (2011). Retrieved Nov. 22, 2011,

from http://www.predic8.com/ iphone-css-layout-the

me.htm

David, M. (2011). Flash Mobile: Developing Android and

iOS Applications. Focal Press.

Dornbierer, C., Ong, J., and Boon, P. (2011). Cross-

Platform Mobile Application Development. Re-

trieved Nov. 23, 2011, from http://www.adnovum.ch/

pdf/slides/adnovum_ jazoon2011_ mobile_ engineer

ing.pdf

Felt, A. P., Finifter, M., Chin, E., Hanna, S., and Wagner, D.

(2011). A survey of mobile malware in the wild. In

Proc. SPSM ’11, pages 3–14. ACM.

Firebug. (2011). Retrieved Nov. 23, 2011, from http://get

ﬁrebug.com/

Firtman, M. (2010). Programming the mobile web.

O’Reilly.

Fishburn, P. C. (1967). Additive utilities with incomplete

product sets: Application to priorities and assign-

ments. Operations Research, 15(3):pp. 537–542.

Gartner (2011). Market Share: Mobile Communica-

tion Devices. Retrieved Nov. 23, 2011, from

http://www.gartner.com/it/page.jsp?id=1848514

Goadrich, M. H., & Rogers, M. P. (2011). Smart smart-

phone development: iOS versus Android. In Proc.

SIGCSE

11 (pp. 607-612). New York, NY, USA:

ACM.

Google (2011). Android Open Source Project. Retrieved

Nov. 23, 2011, from http://source.android.com/

iPhonical. (2010). Retrieved Nov. 23, 2011, from http://

code.google.com/p/iphonical/

jQuery Mobile (2011). jQuery Mobile. Retrieved Nov. 23,

2011, from http://jquerymobile.com/

Kassinen, O., Harjula, E., Koskela, T., and Ylianttila, M.

(2010). Guidelines for the implementation of cross-

platform mobile middleware. International Journal of

Software Engineering and Its Applications, 4(3).

Koch, P.-P. (2009). There is no WebKit on Mobile. Re-

trieved Nov. 23, 2011, from http:// quirksmode.org/

blog/archives/2009/10/there_is_no_web.html

Lakshman, T. K. and Thuijs, X. (2011). Enhancing en-

terprise ﬁeld productivity via cross platform mobile

cloud apps. In Proc. MCS

11, pages 27–32, New

York, NY, USA. ACM.

Lin, F., & Ye, W. (2009). Operating system battle in the

ecosystem of smartphone industry. In Proc. of the

2009 int. symp. on information engineering and elec-

tronic commerce (pp. 617-621). IEEE CS.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

310

Lukasavage, T. (2011). Adobe & PhoneGap: Makes

Sense, Mostly. Retrieved Nov. 23, 2011, from

http://savagelook.com/blog/tag/phonegap

MacFadyen, J. (2010). PhoneGap and the Apple developer

license agreement. Retrieved Nov. 23, 2011, from

http://blogs.nitobi.com/jesse/ 2010/04/ 14/ phonegap-

and-the-apple-developer-license-agreement/

Murphey, R. (2010). On jQuery & Large Applica-

tions. Retrieved Nov. 23, 2011, from http://blog.

rebeccamurphey.com/on-jquery-large-applications

Newman, B. (2011). Are Cross-Platform Mobile App

Frameworks Right for Your Business? Retrieved

Nov. 23, 2011, from http://mashable.com/2011/03/

21/cross-platform-mobile-frameworks/

Original Graded Browser Matrix (2011). Original Graded

Browser Matrix. Retrieved Nov. 22, 2011, from http://

jquerymobile.com/original-graded-browser-matrix/

Pfeiffer, D. (2011). Which Cross-Platform Frame-

work is Right For Me? Retrieved Nov. 23,

2011, from http://ﬂoatlearning.com/2011/07/which-

cross- platform-framework-is-right-for-me/

PhoneGap. (2011). Retrieved Nov. 23, 2011, from http://

www.phonegap.com/

PhoneGap:Build. (2011). Retrieved Nov. 23, 2011, from

https:// build.phonegap.com

PhoneGap License (2011). PhoneGap License. Retrieved

Nov. 23, 2011, from http://phonegap.com/about/

license/

PhoneGap Plugin NFC (2011). PhoneGap Plugin NFC.

Retrieved Nov. 23, 2011, from https://github.com/

shokai/phonegap-plugin-nfc

PhoneGap Roadmap (2011). PhoneGap Roadmap. Re-

trieved Nov. 23, 2011, from http://wiki.phonegap.

com/w/page/28291160/roadmap-planning

Pilgrim, M. (2011). Dive Into HTML5: Local Storage.

Retrieved Nov. 23, 2011, from http://diveintohtml5.

info/storage.html

Rhodes. (2011). Retrieved Nov. 23, 2011, from http://

rhomobile.com/products/rhodes/

Sencha Ext JS (2011). Sencha Ext JS. Retrieved Nov. 23,

2011, from http://www.sencha.com/store/extjs/

Sencha Touch (2011). Sencha Touch. Retrieved Nov. 23,

2011, from http:// www.sencha.com/products/touch/

Titanium Fastdev (2011). Titanium: Fastdev Refer-

ence for Android. Retrieved Nov. 23, 2011, from

http://wiki.appcelerator.org/ display/guides/Fastdev%

20Reference%20for%20Android

Titanium Mobile Application Development. (2011). Re-

trieved Nov. 23, 2011, from http://www.appceler

ator.com/products/titanium- mobile- application- deve

lopment/

Titanium Mobile Open Source (2011). Titanium Mobile

Open Source Project. Retrieved Nov. 23, 2011, from

https:// github.com/ appcelerator/ titanium mobile

Titanium Native Apps (2011). Titanium: The Na-

tive Advantage. Retrieved Nov. 23, 2011, from

http://www.appcelerator.com/products/native-iphone-

android-development/

Titanium Plans (2011). Titanium: Plans & Pric-

ing. Retrieved Nov. 23, 2011, from http://

www.appcelerator.com/ products/ plans-pricing/

Tuunainen, V. K., Tuunanen, T., and Piispanen, J. (2011).

Mobile service platforms: Comparing nokia ovi and

apple app store with the iisin model. In Proc. ICMB

’11, pages 74–83. IEEE CS.

W3C (2011). HTML5: Ofﬂine Web applications. Re-

trieved Nov. 23, 2011, from http://www.w3.org/

TR/html5/ofﬂine.html

COMPARINGCROSS-PLATFORMDEVELOPMENTAPPROACHESFORMOBILEAPPLICATIONS

311