Mobile Application Development

Framework with key criteria for choosing native or cross-platform application

development
Mobil Applikationsutveckling
Ramverk för att välja native eller cross-platform applikationsutveckling

Mårten Aurelius

Faculty: Humanities and Social Sciences

Subject: Information Systems
Points: 15 ECTS
Supervisor: Sana Rouis Skandrani
Examiner: John Sören Pettersson
Date: 2020-06-11
Serial number:
Abstract
To develop mobile applications, developing companies can use different platforms.
One approach is to use a native development environment targeting a specific
operating system that gives access to all device functionalities. Another approach
is to use a cross-platform development tool that allows developers to use a single
code base targeting several operating systems, but often comes with limited
standard features for accessing device functionalities. Each approach has its
benefits and shortcomings.

Multiple factors contribute to the selection of the developing platform. Thus, it is

of big importance to use clearly defined criteria to make the decision that fits best
the need of the final customer, but also that fits with the business and technological
preconditions that the developing company can fulfil. Based on existing literature,
and consolidating our takeaway with quantifiable, as well as additional business
related criteria, this thesis work presents a framework to help decision makers in
developing companies decide whether they will develop applications using a native
or a cross-platform approach. A number of experienced professionals assessed the
compiled list of criteria and attributed respective weight of each criterion in the
framework. The decision makers in companies will use this framework, applying a
formula, and thereafter calculating a score for each approach. The score will load
then to determine whether to choose native or cross-platform development
approach. The results show how we assign the final weight and, in the conclusion,
we discuss limitations and future research directions for research.
Acknowledgement
I would like to express my special thanks to my supervisor, senior lecturer Sana
Rouis Skandrani, for her outstanding help with this thesis. Without her input,
assistance and dedication, I would not have accomplished what I have done.

My appreciation also goes to Professor John Sören Pettersson who has been very
helpful and making it possible for me writing this thesis.

I also would like to thank Eric Sohls, my classmate for his valuable input during the
writing.

Last, but not least, I would like to thank Sean McCreanor the CEO of Assignar, who
helped me recruit mobile application development experts to conduct my survey.
Table of Content

Abbreviations ........................................................................................................................ 1
List of Figures ........................................................................................................................ 2
List of Tables.......................................................................................................................... 3
1. Introduction .................................................................................................................. 4
2. Theoretical Background .............................................................................................. 11
2.1 Mobile Development Technologies .................................................................... 11
2.1.1 Mobile Operating System Characteristics ................................................... 11
2.1.2 Mobile Application Native Development .................................................... 12
2.1.3 Mobile Application Cross-Platform Development ...................................... 14
2.2 Existing decisional frameworks ........................................................................... 18
2.2.1 Dalmasso et al. (2013) and Heitkötter et al. (2013) .................................... 18
2.2.2 Rieger et al. (2016) and Rieger et al. (2019) ............................................... 24
2.3 Comprehensive Decisional Framework for Native vs Cross-Platform
Development ................................................................................................................... 35
2.3.1 Takeaway from Pre-existing Models ........................................................... 35
2.3.2 New Decisional Framework......................................................................... 36
2.3.2.1 Business environment perspective ......................................................... 37
2.3.2.2 Infrastructure perspective ...................................................................... 40
2.3.2.3 Development perspective ....................................................................... 42
2.3.3 List of criteria for selecting native vs cross-platform .................................. 43
2.3.4 Summary earlier research and contribution made by this thesis ............... 51
3. Empirical Study ............................................................................................................ 55
3.1 Data Collection .................................................................................................... 55
3.2 Analysis and Results ............................................................................................ 58
3.3 Discussion ............................................................................................................ 68
4. Conclusion ................................................................................................................... 78
5. References................................................................................................................... 83
6. Annexes ....................................................................................................................... 87
Abbreviations

Abbreviation Full description

API Application Programming Interface
APK Android Package
AR Augmented Reality
B2B Business-to-Business
B2C Business-to-Consumer
CPU Central Processing Unit
CSS Cascading Style Sheets
GPS Global Positioning System
HR Human Resources
HTML HyperText Mark-up Language
IDE Integrated Development Environment
IP Internet Protocol
LOC Line of Code
MVC Model-View-Controller
OEM Original Equipment Manufacturer
OS Operating System
RAM Random Access Memory
SDK Software Development Kit
UI User Interface
UX User Experience
VR Virtual Reality
WORA Write Once, Run Anywhere
WYSIWYG What You See Is What You Get

1
List of Figures

Figure 1 Mobile Operating System Market Share Worldwide from Aug 2012 – Jan 2020
(Statcounter, 2020). Reprinted with permission from Statcounter. .................................................... 5
Figure 2 Cross-platform mobile frameworks used by software developers worldwide as of 2019 (Liu,
2019) ................................................................................................................................................... 7
Figure 3 Matrix suggesting best approach from level of customization compared with number of
customizations done in the app ........................................................................................................ 40
Figure 4 Min, max and mean value for the 22 criteria for the Entire sample ................................... 69
Figure 5 Min, max and mean value for the 22 criteria in the sample of Developers ....................... 70
Figure 6 Min, max and mean value for the 22 criteria in the sample of Decision makers ................ 70
Figure 7 Min, max and mean value for the 22 criteria in the sample categorized as Both developers
and decision makers.......................................................................................................................... 71
Figure 8 Min, max and mean value for the 22 criteria in the sample of Developers including the
sample that answered Both developers and decision makers .......................................................... 72
Figure 9 Min, max and mean value for the 22 criteria in the sample of Decision makers including
the sample that answered Both developers and decision makers .................................................... 72
Figure 10 Min, max and mean value for the 22 criteria in the sample of 15 Years or more of
experience ......................................................................................................................................... 73
Figure 11 Min, max and mean value for the 22 criteria in the sample of 10 Years or more of
experience ......................................................................................................................................... 73
Figure 12 Years of Experience vs Be Agile in HR and Be Agile in Budget which both are from the
Business Environment perspective .................................................................................................... 74
Figure 13 Weight of each criterion from the sample of Developer based on years of experience ... 74
Figure 14 Weight of each criterion from the sample of Decision Makers based on years of
experience ......................................................................................................................................... 75
Figure 15 Weight of each criterion from the sample of Both based on years of experience ............ 75
Figure 16 Years of Experience vs Position vs Provide support for required system integration, Deliver
needed access to device specific hardware or device API and Deliver needed access to device
specific hardware or device API ........................................................................................................ 76
Figure 17 Years of Experience vs Position vs Outliers. ...................................................................... 77
Figure 18 Rounded mean, rounded median and mode for each criterion in the entire sample ....... 79

2
List of Tables

Table 1 Comprehensive decisional framework for native vs cross-platform development............... 46

Table 2 Comparison of previous work and contribution made by the thesis work ........................... 53
Table 3 Survey ................................................................................................................................... 58
Table 4 Distribution of Position among the sample .......................................................................... 59
Table 5 Distribution of weight in criteria Agility in HR management ............................................... 59
Table 6 Distribution of weight in criteria Agility in budget ............................................................... 59
Table 7 Distribution of weight in criteria Deploy competence already available in the company .... 60
Table 8 Distribution of weight in criteria Deploy competence available in market recruiting
developers ......................................................................................................................................... 60
Table 9 Distribution of weight in criteria Provide support for required system integration (back-end
and cloud) needed in the app............................................................................................................ 60
Table 10 Distribution of weight in criteria Deliver needed access to device specific hardware or
device API .......................................................................................................................................... 61
Table 11 Distribution of weight in criteria Needed application performance................................... 61
Table 12 Distribution of weight in criteria Perform customization with core code changes of the
application requiring a heavy technical expertise ............................................................................. 62
Table 13 Distribution of weight in criteria Handle high number of customizations done frequently of
the application which also impact maintenance of the application ................................................. 62
Table 14 Distribution of weight in criteria Meet pricing model in license ........................................ 62
Table 15 Distribution of weight in criteria Handle restrictions of needed modifications in the
framework ......................................................................................................................................... 63
Table 16 Distribution of weight in criteria Migrate existing software platform into an app ............ 63
Table 17 Distribution of weight in criteria Deliver the application to targeted/needed operating
system(s) ........................................................................................................................................... 63
Table 18 Distribution of weight in criteria Provide technical support............................................... 64
Table 19 Distribution of weight in criteria Offer new features in the application delivered by OS
manufacturer .................................................................................................................................... 64
Table 20 Distribution of weight in criteria Handle the risk of OS manufacturer will drop support for
development tools used in selected approach .................................................................................. 65
Table 21 Distribution of weight in criteria Test fragmented platforms supported by the app ......... 65
Table 22 Distribution of weight in criteria Support testing tools used by the company ................... 65
Table 23 Distribution of weight in criteria Support advanced GUI features in the application such as
3D rendering components and AR/VR components .......................................................................... 66
Table 24 Distribution of weight in criteria Support continuous delivery in automate building, testing
and deployment ................................................................................................................................ 66
Table 25 Distribution of weight in criteria Provide continuous application store integration .......... 66
Table 26 Distribution of weight in criteria Handle customizations in the core code changes level
without affecting pace of development ............................................................................................ 67
Table 27 Distribution of weight in outlier Support internationalization and adding multiple
languages .......................................................................................................................................... 68
Table 28 Distribution of weight in outlier Support theming and different user privileges................ 68
Table 29 List of criteria selecting native vs cross-platform approach with weight as rounded mean
value from the empirical study using entire sample ......................................................................... 81

3
 1. Introduction
The present thesis work develops a functional framework for selecting native vs
cross platform approach in mobile applications development. The new framework
presents a list of tangible and measurable criteria and brings more precision and a
clear definition for criteria borrowed from Rieger et al. (2019). The new framework
also develops a new dimension, “the Business Environment”, that covers the
business context for the developing company and major requirements in its today’s
market.

With this research work, we aim to help the decision makers to make the trade-off
for developing applications in native or in a cross-platform environment.

1.1 Background

The number of mobile application downloads has increased from 140.7 billion in
2016 to 204 billion 2019 with a worldwide revenue of 462 billion USD (Clement,
2019). Mobile applications benefit to several industries such as transport,
ecommerce, net banking, travel, retail and enterprise services (Dalmasso et al.
2013, p 1).

An application can be a B2B application or B2C application (Cortimiglia et al., 2011,

p 2). B2C applications fulfil individual customers’ need and would be content-,
marketing- or service-oriented aps. Content-oriented applications target individual
needs for information, entertainment, communication, productivity and
socialization. Companies mostly use Marketing-oriented applications for brand
advertising or promotion. Service-oriented applications let users perform tasks like
check a train schedule or book theatre tickets (ibid, 2011, p 2). B2C applications are
applications usually used by the public and sold or made accessible via the
applications’ store. They are costlier to implement and maintain due to the need of
frequent updates in response to user feedback and user interface since the user
experience is of big importance for these applications in genre (Long, 2017). B2B
applications support a company’s internal business process such as warehouse
management, sale-force automation or customer-relationship management
(Cortimiglia et al., 2011, p 2). The B2B application is most often restricted by either
login credentials in the application to access its UI or only available to a specific
company’s employees where downloads are strictly limited (Long, 2017). Long
(2017) also describes one of the big differences that a B2B application is distributed
on a more limited basis whereas the most B2C applications are distributed to the
public.

Besides from developing the actual application and identify the segment, B2B or
B2C, there is a challenge when selecting which OS to target.

4
The smartphone market has exploded during the last 10 years. According to Holst
(2019) the global smartphone shipments has increased from 173.5 million units in
2009 to 1 404,9 million units in 2018. During this period there have been different
mobile operating systems, for example Android, Blackberry, iOS, Symbian and
Windows. Today the market is dominated by two contenders – Android and iOS
(Statcounter, 2020). It may be a difficult decision to take which OS to focus on for
companies developing mobile applications. Even if the market today is dominated
by Android and iOS there might be another contender dominating the market in
the future. As seen in Figure 1, the OS market share has shifted during the last 8
years. This is the unsecure circumstances companies must take into consideration
when choosing strategy for their mobile application development. The mobile OS
dominating the market today might not dominate the market in 5 years.

Figure 1 Mobile Operating System Market Share Worldwide from Aug 2012 – Jan 2020
(Statcounter, 2020). Reprinted with permission from Statcounter.

Making the selection of OS for application development is not only based on market
share or targeted industry. Lamhaddab et al. (2019) presents four factors for
deciding which OS is suited for enterprise requirements:

1. Audience: Android has the bigger market share and for the first quarter of
2019 the Google Play Store pulled 22 billion applications worldwide, the
Apple Application Store only drove 8 billion.
2. Monetization: While Android has more downloads, Apple has nearly twice
lead when it comes to gross consumer spend.
3. Project timeline: Developing applications for Android is 30-40 % slower than
iOS in average.

5
 4. Budget: The cost to develop a mobile application depends on the scope and
complexity of the project but also devices and OS versions support,
marketing effort, team and cross department involvement,
maintenance/upgrade etc.

Developers target one specific platform using its software development kit (SDK)
and frameworks when developing native mobile applications. The application is tied
to that specific environment (Heitkötter et al. 2013, p 3). Developing native
applications for Android is done using Android Studio with Android SDK and native
applications for iOS is done using XCode with iOS SDK. This means one development
environment and source code for each OS (Monus, 2019). The diversity of mobile
platforms and SDKs and other tools cause unique challenges as choice of SDK, user
experience, stability of framework, ease of updating cost of development for
multiple platforms and time to market an application (Dalmasso et al. 2013, p 1).

Native applications must be developed separately for each platform if there is a

need for supporting multiple platforms. Instead of separate native development,
cross-platform development allows the developers to implement an application
using a single code base that can be executed on multiple platforms (Heitkötter et
al. 2013, p 3).

Liu (2019) presents the 10 most used cross-platform frameworks in 2019 illustrated
in Figure 2. The most used framework is ReactNative with a usage of 42% among
developers using cross-platform tools. The following four frameworks have almost
the same share of users with a usage between 26-30%. In chapter 2.1.3 the main
characteristics with pros and cons are presented for ReactNative, Xamarin, Flutter
and Adobe PhoneGap because they represent different shares of usage and have
different technical characteristics and therefore an interesting comparison. Some
companies will prefer one over another based on what each cross-platform tool
have to offer and is the best fit for the competence already existing in the company
and the characteristics of the application to be develop.

6
 Cross-platform mobile frameworks used by
software developers worldwide as of 2019
50%
40%
30%
20%
10%
0%

Figure 2 Cross-platform mobile frameworks used by software developers worldwide as of

2019 (Liu, 2019)

Choosing a cross-platform approach might look at the obvious choice since you can
have a single code base for several OS making the development and maintenance
faster, easier and cheaper. This is, however, not always the case. According to
Biørn-Hansen et al. (2019, p 8) cross-platform frameworks has limitations making
them less capable for application development than the native development
approach and is hard to integrate with device application programming interface
(API). They also conduct that cross-platform development tools are not as easy to
test and debug as native development tools.

The choice of native or cross-platform development approach is therefore not an

easy decision to take. We plan to answer this problem statement in the present
research work. More precisely, we tend to answer the research questions:

1. Which criteria should a functional and measurable framework for native

vs cross-platform decision making include?
2. Which level of importance should be allocated to each of these criteria?

1.2 Purpose and aim

As described, there are many variables to take into consideration when developing
an app. What market does the company target? Does the customer need
integration to device API? What OS does the application need to be available for?
Does the application need to be available for multiple OS? Depending on the
outcome of these questions, a number of other key technical considerations, as well
as contextual considerations, either native or a cross-platform approach may be
appropriate.

7
Dalmasso et al. (2013, p 1) is presenting nine criteria and Heitkötter et al. (2013, p
6-7, p 15-16) identifies 14 criteria for helping decide whether to take a native or a
cross-platform approach when developing mobile applications. Heitkötter et al.
(2013, p 6) divides these 14 criteria in two perspectives, Infrastructure and
Development, with seven criteria for each perspective. These criteria are not up to
date since the technology and market has emerged since then and therefore the
demands on the criteria are different today. The lists of criteria are also too broad
with limited perspectives and there is a need for a more detailed level for decision
makers to be able take the decision based on these criteria. Rieger et al. (2019, p
180-186) expands the perspectives identified by Heitkötter et al. (2013, p 6) and
add additional two, leading up to four perspectives for evaluating different cross-
platform frameworks. These four perspectives cover more up to date demands but
do not cover the decision on whether to choose a native or a cross-platform
approach since the criteria only aims to identify different characteristics when
selecting a cross-platform framework. This thesis work is using the perspectives
presented by Rieger et al. (2019, p 180-186) as a reference for the list of criteria
selecting native or cross-platform approach.

This thesis work expands previous list of criteria from Dalmasso et al. (2013, p 1)
and Heitkötter et al. (2013, p 6-7, p 15-16) by updating the list, detail the criteria to
achieve a measurement level and complete it with new criteria that are related to
the company’s profile. This thesis uses the Infrastructure and Development
perspectives defined by Heitkötter et al. (2013, p 6) and then further developed by
Rieger et al. (2019, p 180-186). Rieger et al. (2019, p 193) got feedback from experts
that some generic criteria, such as Pace of Development found in Development
perspective, need to be scrutinized, which is provided in this thesis and in the
context of decision between native or cross-platform application development.

In this thesis, an additional perspective, Business environment, is added with criteria

such as when (in time), company profile, needed competence, B2B or B2C, etc.
Rieger et al. (2019, p 194-195) suggests that further research can be done with the
criterion of integration to for example cloud services when selecting cross-platform
framework. We add the “Business environment” as a new dimension criterion in
this thesis since that support can be important depending on intended functionality
of the application to be develop.

1.3 Target group

The primary target group of this thesis is the decision makers in companies choosing
strategy of their mobile application development. The decision makers most
probably work in companies developing mobile application software or using

8
consultant companies developing the software for them. By providing criteria for
choosing native or cross-platform development approach, the established new
framework will support the decision among the two approaches.

1.4 Problem statement

Selecting whether developing mobile applications using native or cross-platform

approach might not be based on a theoretical framework or even by doing a
preparatory study investigating the company’s needs. Making such selection must
be done from many different aspects and multiple inputs. Some applications and
companies might be best suited for cross-development approach whereas others
might benefit from native development. The decision might even be from a time
perspective when it is time to switch from one approach to another. According to
Blair (n.d.) a multi featured enterprise application can cost around $50 000 - $
150 000 to develop depending on chosen technology and demands of the app. A
complex application can even cost up to $250 000 if developed in USA (Pratap,
2018). Developing an application means a lot of money and time invested in the
process and by minimize the risk of taking the wrong decision, need to re-write the
application in a different approach investing the same amount of money again,
there is of big importance to use well defined criteria to make the right decision.

1.5 Delimitations

Since the market for mobile OS today is dominated by Android and iOS
(Statcounter, 2020), the native development perspective in this thesis is only
focusing on these two OS. The list of criteria is based on the perspective of
Infrastructure and Development introduced by Heitkötter et al. (2013, p 6) and
further expanded by Rieger et a. (2016, p 8-14) and Rieger et al. (2019, p 180-186).

Not all cross-platform frameworks put weight in platform-agnostic UI aspects

leaving it per individual implementations per platform (Rieger at al. 2019, p 182).
This thesis is only considering cross-platform approach as the development of a
single based source code that can be run on multiple OSs and do not have to make
specific changes on UI dependent on target platform.

1.6 Ethical considerations

This thesis work adapts the ethical considerations presented by Leedy et al. (2015),
described in more detail this chapter.

Leedy et al. (2015, p 120) state that most ethical issues in research fall into one of
the categories 1) Protection from harm, 2) voluntary and informed participation, 3)
right to privacy and 4) honesty with professional colleagues.

9
Protection from harm
A researcher should treat all participants in a courteous and respectful manner. The
risk involved in participating in a study should not be greater than the normal risks
of day-to-day living (Leedy et al. 2015, p 120).

Voluntary and informed participation

Participants should be told the nature of the study to be conducted and given the
choice of participating or not. Sometimes a dilemma arises how informed the
participants should be, a reasonable compromise is to give the participants a
general idea what the study is about to give them sufficient information to make
reasonable judgement whether they want to participate or not (Leedy et al. 2015,
p 121-122).

Right to privacy
Under no circumstances should a research report be presented in a way that
anyone could be aware of how an individual participant have responded or behaved
unless the participant has granted permission in written for this to happen (Leedy
et al. 2015, p 123).

Honesty with professional colleagues

Researchers must report their findings without misrepresentations or intentionally
misleading others about the nature of the findings. A researcher should under no
circumstances fabricate data to support a particular conclusion, such an action
constitutes scientific fraud. Appropriate credit should be given where credit is due
and using another person ideas or words demands full acknowledgement (Leedy et
al. 2015, p 123).

The conducted survey in this thesis is anonymous and voluntary. The responses are
treated with confidentiality and no identifying information such as name, e-mail
address or IP address are collected.

10
 2. Theoretical Background
Mobile applications are developed targeting a specific OS which can be done by
either using native or cross-platform development. This thesis is reviewing different
mobile development technologies, mobile operating system characteristics, mobile
native development, mobile cross-platform development and previous literature
with existing decisional framework for selecting native or cross-platform approach.

2.1 Mobile Development Technologies

A developer requires extensive knowledge of Java or Kotlin for developing
applications on Android and Objective-C or Swift for iOS. Deploying applications on
both platforms, the native application development process would require a big
investment in time, money and effort and there is a need to re-write the code to be
run in different runtime environments. Therefore, many companies are using a
cross-platform approach (Shah et al. 2019, p 1).

Cross-platform frameworks are offering developers a tool for developing mobile

applications without the need of extensive knowledge in either Java or Swift.
Developers can use C# with Xamarin, Java Script with React Native, Dart with Flutter
or even web technologies with Adobe PhoneGap. These are competences
companies might already have inhouse and therefore a cross-platform approach
might be a suitable selection. This will be detailed further in section 2.1.3.

Cross-platform approaches does not give the same user experience as a native
approach. A native touch and feel, can only be achieved using truly native
components inside the app. A deep integration with the device and improved
performance are important parameters to take into consideration when developing
an app. (Shah et al. 2019, p 7).

According to Shah et al. (2019, p 6) native applications are to prefer when it comes
to performance-related parameters like access to native device APIs, ease of
update, rendering UI and providing the better user experience. Native applications
require platform specific knowledge which are often cost intensive. Shah et al.
(2019, p 7) conclude that despite the disadvantages in a cross-platform approach,
they often are the preferable approach except when developing high performance
applications.

2.1.1 Mobile Operating System Characteristics

Today the market is dominated by two contenders – Android and iOS (Statcounter,
2020) which has different characteristics and is of interest to know before
developing an app.

11
2.1.1.1 Android OS
Android’s primary purpose is to create an open software platform available for
carriers, OEMs and developers to introduce a product that improves the mobile
experience for users. Android is designed so no industry player controls or restricts
the innovation of another resulting in product with source code open for
customization and porting. To prevent uncontrolled customization that can lead to
incompatible implementations, the Android Open Source Project, led by Google,
maintains the Android Compatibility Program that spells out what it means to be
Android compatible and what’s required of device builders have to achieve that
(Android Source, 2019).

Android is an open source Linux-based software stack. Using a Linux-kernel allows

manufacturers to develop hardware drivers for a well-known kernel. A hardware
abstraction layer provides interfaces to device hardware capabilities with the Java
API Framework (Android Developer Platform, 2019).

Android applications cost $25 to host on Google Play and developing an application
for Android is easier compared to iOS since the guidelines are not as strict as iOS
(Pratap, 2018).

2.1.1.2 iOS
The iOS OS, originally called iPhone OS, is the mobile operating system developed
by Apple Inc for devices manufactured by Apple. Originally developed for iPhone,
iOS was later extended to be implemented for other Apple devices such as iPad and
Apple TV. iOS is a Unix-like OS with four levels of abstraction: the operating system
kernel, the core services level, the media level and the user interface (Novac et al.
2017).

iOS applications cost nearly $200 to host on Application Store and to get approval
from Apple may take some time since the guidelines are strict (Pratap, 2018).

2.1.2 Mobile Application Native Development

When developing native mobile applications, developers target one specific
platform using its SDK and frameworks. The application is tied to that specific
environment (Heitkötter et al. 2013, p 3). The native application development
approach for the two mobile OS dominating the market today, Android and iOS
(Statcounter, 2020), is hereby presented.

2.1.2.1 Android Native Development

Applications for Android can be written using Koitlin, Java or C++ programming
languages. The Android SDK tools compile the source code, data and resource files
into an APK that contains all the content of an Android application and is the file
that Android-powered devices use to install the application (Android Developer

12
Fundamentals, 2019). Each application has only access to the components required
to do its work and cannot access parts of the system for which is not given
permission (ibid, 2019). According to Android Developer Fundamentals (2019) each
application lives in its own security sandbox protected by the following Android
security features:

 Android operating system is a multi-user Linux system where each

application is different user
 The system assigns each application a unique Linux user ID and only the user
ID assigned to that application can access the files that the system has set
permission for.
 Each process has its own virtual machine, so an app’s code run in isolation
from other applications
 Every application runs in its own Linux process. The Android system starts
the process when any of the app’s components need to be executed and
shuts down the process when it is no longer needed, or the system must
recover memory for other applications.

An Android application must declare all components it is using in a manifest file,

AndroidManifest.xml including the permissions the application requires, minimum
API-level, declare hardware or software features such as camera and declare the
API libraries the application needs to be linked with (ibid, 2019).

The entire feature-set of the Android OS is available using Java APIs enabling
building UI, access to non-code resources, notifications, activity manager to provide
a common navigation back stack and content providers to access data from other
applications . With this framework, developers have full access to the same
framework APIs that Android system applications such as email, SMS, calendars,
internet browsing etc are using (Android Developer Platform, 2019).

2.1.2.2 iOS Native Development

Developing native applications for Mac, iPhone, iPad, Apple Watch and Apple TV is
done using the XCode IDE. XCode communicates with the Apple Developer website
so that a developer can enable services such as Game Center or Passbook. XCode
also bundle and submit the application to the Applications tore when it is ready.
Test driven development is a part of the workflow with XCode where a developer
can use Test Navigator to jump into any test in the project, perform individual test
or a group of tests (Apple Developer XCode, 2020). Applications for macOS, iOS,
watchOS or tvOS is done using the programming language Swift that gives the
benefit of automatically managed memory without the overhead of a garbage
collector. Swift is a successor to both the C and Objective-C languages (Apple

13
Developer Swift, 2020). Strings are Unicode-correct and use UTF-8 based encoding
to support international languages and emoji (ibid, 2020).

2.1.3 Mobile Application Cross-Platform Development

Developing native applications for different platforms means different
programming languages for each platform, different API’s and different IDEs. Cross-
platform development tools have been developed with the purpose of writing an
application source code once and run it on different OS’s (Palmieri et al. 2012, p
180).

Shah et al. (2019, p 2) presents the following advantages and disadvantages

developing using a cross-platform approach:

Advantages

 WORA, which is the primary advantage. The application is implemented

using a single code base but can be deployed to multiple platforms.
 Cross-platform tools usually use well known programming languages and
syntaxes
 Major tools have a large community-driven open source platform. New
features and modules are continually added, updated and revised.
 Cost-cutting can be done effectively since development is simpler compared
to multiple platforms
 Updates and bug fixes can be rolled out for every platform affecting all
platforms at once.

Disadvantages

 Native applications are designed to work flawlessly for the specified

platform with better performance compared to cross-platform
counterparts.
 Native applications have a deeper integration with device API for all
features.
 Native applications provide a rich UX. Rendering of high-end graphics is only
effectively possible with native application development.
 Deployment to application store of the respectively platform is usually
lowered compared to cross-platform applications. Some applications which
simply inject HTML and JavaScript code inside a container are rejected from
getting published.
 Complex applications increase the risk of the application freezing and
crashing because support of all devices is practically infeasible with cross-
platform solutions.

14
The market today offers several different cross-platform frameworks. In the
following sections the main characteristics of Xamarin, ReactNative, Adobe
PhoneGap and Flutter is presented.

2.1.3.1 Xamarin
Xamarin is an open source platform from Microsoft for developing mobile
applications targeting iOS and Android using C# and .NET. enabling developers to
use base libraries for working with strings, dates and files/IO. Xamarin has a big
community with more than 60 000 contributors from more than 3 700 companies.
(What is Xamarin, n.d.).

Developers must use Xamarin.Forms for building applications targeting both

Android and iOS with a single shared codebase, where they can design and build
mobile applications from a single API. Xamarin.Forms is an application framework
for building mobile applications including cross-platform navigation, animation
APIs, dependency service, messaging center etc. With Xamarin.Forms the
developers can access native user interface features for each platform such as iOS
Safe Area and Android elevation. The Visual API gives the application a consistent
Material Design look and feel across iOS and Android applications (Xamarin.Forms,
n.d.).

Haberl (2015, p 49) conclude that since Xamarin implement a layer over the native
environment, there is no real control of what is generated as the final code to be
run on the device. This can lead to a lot of workarounds within the codebase.

Pros:

 Share more than 75% of the code across platforms (Manchada, 2019)
 Strong community with over 60 000 contributors and more than 3 700
companies (Manchada, 2019)
 A single tech stack for faster development using Visual Studio and C#
(Leuschenko, 2018)
 Applications for all platforms where developers can create applications for
mobile and desktop experiences simultaneously (Leuschenko, 2018)

Cons:

 License is free for individuals and startups but is expensive for enterprises
with $250 - $5 999 annual fee (Manchada, 2019)
 Not recommended for applications with heavy graphics (Manchada, 2019)
 Limited access to certain important libraries (Manchada, 2019)
 Slow debugging process, especially on Android (Manchada, 2019)

15
  Does not support all available 3rd-party libraries for Android and iOS without
specific wrapper (Leuschenko, 2018)
 Larger application size adding 2-5 Megabytes for the release and around 20
Megabytes for debug builds (Leushenko, 2018)

2.1.3.2 React Native

React Native is an open source framework released by Facebook in 2015, in 2018 it
had the 2nd highest number of contributors for any repository in GitHub. The
programming language is Java Script and renders the UI into native components
giving applications developed in React Native a native look and feel. The UI is built
with platform agnostic components like View, Text and Image that map directly to
the platform’s native UI building blocks (React Native, n.d.).

Pros:

 Share more than 80% of the code across platforms (Manchada, 2019)
 Preview results right away and ready-to-apply elements (Manchada, 2019)
 Hot reloading features allowing developers see changes made within
seconds (Manchada, 2019)
 UI rendering giving a highly responsive interface (Manchada, 2019)
 Reliable and stable applications (Ganguly, 2018)
 Ready-made components achieving simple functionalities making
development process faster (Ganguly, 2018)
 Growing community where developers can get help (Ganguly, 2018)

Cons:

 Not a fully cross-platform framework. To use native components there must

be separate code for iOS and Android (Manchada, 2019)
 Since the framework is not built in conjunction with iOS or Android, it
sometimes lags behind the native platforms (Manchada, 2019)
 Lacks consistency when it comes to releasing updates (Manchada, 2019)
 Slow debugging process, especially on Android (Manchada, 2019)
 Ready-made components collection is quite small limiting programmers and
the component quality can lack in reliability when they are not official
releases (Ganguly, 2018)
 Application performance lacks compared to native application (Ganguly,
2018)
 Java Script programming language making applications with low security
and poor memory management (Ganguly, 2018)

16
2.1.3.3 Adobe PhoneGap
Adobe PhoneGap is an open source framework built on top of Apache Cordova.
Developers is using web technologies like HTML, CSS and Java Script to build mobile
applications but still have access to native device APIs like camera, GPS and
accelerometer (Adobe PhoneGap, n.d.).

Pros:

 Possible to share application with the team to get their feedback

(Manchada, 2019)
 Cloud solution to create an application directly (Manchada, 2019)
 Third-party tools, a large community and a large number of plugins
(Manchada, 2019)
 Uses an intuitive desktop as for mobile application development and serves
the application created on the desktop to mobile devices connected to it
(Manchada, 2019)

Cons:

 No recommended for high-performance applications and hardware

intensive applications due to its poor performance and lack of UI widgets
(Manchada, 2019)
 Dependent on iOS SDKs to build an application which requires a Mac
(Manchada, 2019)
 Low performance applications compared to native applications (Manchada,
2019)

2.1.3.4 Flutter
Flutter (first released Dec 4th, 2018) is an open source framework by Google for
creating native compiled mobile applications that can be run on both iOS and
Android. Flutter is using the object-oriented programming language Dart with
widgets optimized for 2D graphics. Developers can use the same design on both iOS
and Android. Flutter provide access to some native device API, like camera,
geolocation, network and storage but Flutter do not intend to build support for all
native services and APIs (Flutter FAQ, n.d.).

17
Pros:

 Hot reloading features allowing developers see changes made within

seconds (Manchada, 2019)
 Can build applications quickly that looks native on both Android and iOS
(Manchada, 2019)
 Based on Dart programming language that developers have found easy to
acquire skills for (Manchada, 2019)
 Widgets as Google Material Design and Apple style with Cupertino pack
(Manchada, 2019)
 High speed animation and is simple to create and integrate into the
application (Fitzgerald, 2019)
 Single language for layout and backend (Fitzgerald, 2019)

Cons:

 Flutter does not offer support for Android TV and Apple TV (Manchada,
2019)
 Lacks with respect to native development (Manchada, 2019)
 Since Flutter applications is using built-in widgets instead of platform
widgets the size of the application is usually bigger (Manchada, 2019)
 Limited libraries and often developers must build functionality themselves
(Fitzgerald, 2019)
 Not an extensive or easy support for continuous integration (Fitzgerald,
2019)

2.2 Existing decisional frameworks

There is no commonly adopted decisional framework helping to decide whether a
native or cross-platform mobile development approach are best suitable for the
company. Previous work from Dalmasso et al. (2013, p1) and Heitkötter et al. (2013,
p 6-7, p 15-16) compares native and cross-platform development from different
criteria but is lacking the detailed level and perspective of deciding based on them.
Rieger et al. (2016, p 8-14) and further developed by Rieger et al. (2019, p 180-186)
expands the work introduced by Heitkötter et al. (2013, p 6-7) and presents a
framework for deciding which cross-platform framework fulfils different criteria the
most, but it’s not a framework for deciding native or cross-platform development.

2.2.1 Dalmasso et al. (2013) and Heitkötter et al. (2013)

Dalmasso et al. (2013, p 2-5) is presenting a comparison and evaluation of cross-
platform development tools and present a comparison between native and cross-

18
platform development. Heitkötter et al. (2013, p 6-7, p 15-16) is presenting criteria
for comparing native and cross-platform approach based on the Infrastructure and
Development perspective.

2.2.1.1 Comparison by Dalmasso et al. (2013)

Dalmasso et al. (2013, p 1) make a comparison between native and cross-platform

application development approaches with nine criteria which is further described
in Annex 1:

1. Quality of UX
2. Application development cost
3. Time-to-market
4. Supportability
5. Ease of updating
6. Potential users
7. Quality of applications
8. Security of app
9. Application extension

 Quality of UX
Measures the quality of the user experience. The native approach is described as
Excellent and cross-platform approach as Not as good as native applications.

 Application development cost

Indicates the cost of developing applications in each approach. The native
development is described as High and cross-platform approach as Medium to low.

 Time-to-market
Measures the how fast an application can be developed. The time-to-market for a
native application is considered High and with a cross-platform approach Short.

 Supportability
How easy an application is to support is evaluated within each approach. An
application developed with a native approach is considered Complex and with a
cross-platform approach as Medium to complex.

 Ease of updating
How easy an application is to update and keep updated is evaluated here. An
application developed with a native approach is considered Complex and with a
cross-platform approach as Medium to complex.

19
  Potential users
Measures the number of potential users when selecting approach. The native
approach limits potential users to a particular mobile platform whereas the cross-
platform approach has a large number of potential users since it is reaches to users
on different platforms.

These first six criteria are all supportive when selecting native or cross-platform
approach. They need to be scrutinized and further developed but would in general
serve as a helpful criterion. Quality of UX is different in native or cross-platform
applications given that native development provides full support for all UI elements
whereas cross-platform is restricted to the framework. Application development
cost and Time-to-market can all be related to the competence available in the
company and would also be an important criterion. Supportability could be
measured how well the chosen approach is easy to maintain and support needed
functionality of the app. Ease of updating is a part of continuous integration and
continuous application store integration which also are important criterion when
selecting approach. Potential users as described above is the essence of selecting
native or cross-platform approach, the number of platforms the company need to
target and is therefore also an important criterion.

The last three criteria, 7) Quality of applications , 8) Security of application and 9)

Application extension, are not as important when selecting approach since the
cross-platform tools has been developed since this paper was published in 2013
and therefore not as critical as a criterion when selecting approach.

These criteria are limited to a very few decision factors and it is not elaborated what
each criterion means and what long term effects that have in the selection of
approach. Dalmasso et al. (2013, p 1) does not make any distinctions between B2B
or B2C approach, the need of device API or different perspectives of the application
lifecycle. The way of judging each criterion is also very vague using meanings like
Excellent, Medium, Not good etc. There is no explanation how the different
evaluation factors of the criteria should be interpreted or used within an
organization judging the outcome of the criteria.

Heitkötter et al. (2013, p 6-7, p 15-16) is presenting criteria for comparing native
and cross-platform approach based on the Infrastructure and Development
perspective. Heitkötter et al. (2013, p 6) defines the perspectives as “The
infrastructure perspective sums up criteria relating to the life-cycle of an app, its
usage, operation and functionality/functional range” and “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”.

20
These criteria are not a framework for deciding if native or cross-platform approach
is the most suitable for the company but serves as a comparison tool between the
different approaches. This comparison is more comprehensive than the work by
Dalmasso et al. (2013, p 1)

2.2.1.2 Infrastructure perspective by Heitkötter et al. (2013)

Heitkötter et al. (2013, p 6, p 15) identifies the following seven criteria for
comparing native and cross-platform approach from the infrastructure perspective
which is further described in Annex 2:

1. License and cost

2. Supported platforms
3. Access to device-specific features
4. Long-term feasibility
5. Look and feel
6. Application speed
7. Distribution

 License and cost

Native: Android is open source where iOS is only available with Apple’s own
hardware with an end user software agreement. A membership in Apple developer
program is necessary.

Cross-platform: Is the framework distributed as free software or open source? Are

the developers free to develop commercial software?

 Supported platforms
Native: Is done separately for each platform because programming language and
API differ.

Cross-platform: The number of mobile platforms that are supported and the
importance of them.

 Access to platform-specific features

Native: Direct access to all features

Cross-platform: Access to device hardware like GPS, camera and notifications.

 Long-term feasibility
Native: Studies show that both Oss [Android and iOS] will remain popular.
Developers can rely on large communities, regular bug-fixes and updates.

21
Cross-platform: For small companies, this criterion can be of importance due to the
initial investment. Indicators are short update cycles, regular bug-fixes, support of
newest versions of mobile operating systems etc.

 Look and feel

Native: Full support of platform specific UI elements. Everything that can be done
in cross-platform can be done natively.

Cross-platform: Does the framework support native look and feel? Most users seek
applications that look like native applications.

 Application speed
Native: Native prototypes are not slower than cross-platform. Equal to cross-
platform tool PhoneGap.

Cross-platform: Compare application speed at start-up and runtime from the

subjective user experience.

 Distribution
Native: Within platform-specific application stores

Cross-platform: How easy is it to distribute update and applications with the

respective framework?

All seven criteria are important when selecting between native or cross-platform
approach. License and cost include the pricing model affordable by the company
and if there are any restrictions in the framework limiting needed modifications.
Supported platforms is the essence of selecting native or cross-platform approach,
the number of platforms the company need to target and is therefore also an
important criterion. Access to platform-specific features is also an important
criterion since the native approach gives access full access to all device features
whereas cross-platform most often only provide a subset of all features by default.
Long-term feasibility, besides the rapidity in releasing bug-fixes and new OS
features, also implies the risk of selecting one approach over another and is also a
criterion that needs to be taking into consideration when selecting approach. Look
and feel with the meaning of accessing different UI-components is also an
important criterion since native development provides full support for all UI
elements whereas cross-platform is restricted to the framework. Application speed
could be different depending whether the application is developed natively or in a
cross-platform environment. The importance and impact of this is very dependent
on what type of application that is developed and for some applications the
performance is essential. As for the last criteria, Distribution, is also important since

22
support for continuous application store integration could be an important criterion
for the company.

2.2.1.3 Development perspective by Heitkötter et al. (2013)

Heitkötter et al. (2013, p 7, p 16) identifies following seven criteria for selecting
native or cross-platform approach from the development perspective which is
further described in Annex 3:

1. Development environment
2. GUI design
3. Speed and cost of development
4. Maintainability
5. Opportunities for further development
6. Ease of development
7. Scalability

 Development environment
Native: Android applications with Java-enabled IDE such Eclipse with corresponding
plugins. iOS developers require Max OS and XCode

Cross-platform: Evaluates how well the development environment is functioning

and the features associated with the framework (IDE, debugger, emulator).

 GUI Design
Native: Both Android and iOS support WYSIWYG editor.

Cross-platform: The process of creating GUI and its software support like editor or
emulator.

 Speed and cost of development

Native: Native development requires specific knowledge and experience. An
application needs to be repeatedly developed for each platform which leads to cost
of development native is higher.

Cross-platform: Speed of the development process and factors that could hinder a
fast development. Cost are related to the speed of development and the salary for
the competence needed for a developer in each framework.

These three criteria are important when selecting native or cross-platform

approach. Development environment from the aspect of how testing tools used by
company are integrated into the environment and GUI Design in terms of how well
each approach support the GUI components needed by the app. Speed and cost of

23
development is important from the perspective in what approach the company can
maintain and develop changes in the application without affecting the speed.

The remaining four criteria, 4) Maintainability, 5) Opportunities for further

development, 6) Ease of development and 7) Scalability is hard to quantify and get
measurable aspects from to decide between native or cross-platform development
approach. Ease of development is also dependent on the competence existing in
the company.

2.2.2 Rieger et al. (2016) and Rieger et al. (2019)

Rieger et al. (2016, p 8-14) presents a framework for decision making in what cross-
platform framework to select. This is not criteria for selecting native or cross-
platform, only for selecting cross-platform framework. They categorize the criteria
based on the perspective of development they take. They expand the previous
perspectives presented by Heitkötter et al. (2013, p 6) (Infrastructure and
Development) by adding additional two perspectives – Application and Usage.
Rieger et al. (2016, p 8-14) is not only extending the work by Heitkötter et al. (2013,
p 6-7, p 15-16), they also embed them into a framework that is including a weighting
scheme where assessments of cross-platforms can be employed to make a per-
scenario choice of cross-platform (Rieger et al. 2016, p 3). Rieger et al. (2016, p 15)
present a weight % for each criterion indicating the importance. Each of the 31
criteria receive a weight between 1-7 where the total is 100 points.

Rieger et al. (2016, p 8) describes the four perspectives as

1. Infrastructure: The general background and prospects of a cross-platform

development approach.
2. Development: The aspects of using an approach for carrying out the actual
programming activities.
3. App: The capabilities of applications that can be realized with a given
approach.
4. Usage: Considers usability, ergonomic, and performance aspects that are
essential factors for user acceptance.

2.2.2.1 Infrastructure perspective by Rieger et al. (2016)

Rieger et al. (2016, p 8-10) identifies following seven criteria for selecting cross-
platform framework from the infrastructure perspective which is further described
in Annex 4:

1. License
2. Supported target platforms
3. Long-term feasibility

24
 4. Supported development platforms
5. Distribution channels
6. Monetisation
7. Global application distribution

 License
The license under which framework is published is essential for the type of product
to develop. It needs to be assessed if a developer is free to create commercial
applications and the pricing model also needs to be considered.

 Supported target platforms

The major concern for selecting cross-platform framework is the number and
importance of supported mobile platforms. Support also includes which versions of
the mobile OS each framework is supporting and in what extent.

 Long-term feasibility
Choosing an approach might be a crucial strategic decision considering the initial
investment for hiring and training developers as well as the risk of technological
lock-in, especially for smaller companies. The maturity and stability of the
framework can be evaluated by the historical and expected backwards
incompatible changes of major releases. Short update cycles, regular bug-fixes and
security updates are other indicators.

These three criteria are all important when selecting native or cross-platform
approach. License include the pricing model affordable by the company and if there
are any restrictions in the framework limiting needed modifications. Supported
target platforms is the essence of selecting native or cross-platform approach, the
number of platforms the company need to target and is therefore also an important
criterion. Long-term feasibility, besides the rapidity in releasing bug-fixes and new
OS features, also implies the risk of selecting one approach over another and is also
a criterion that needs to be taking into consideration when selecting approach.

The remaining four criteria, 4) Supported development platforms, 5) Distribution

channels, 6) Monetisation and 7) Global application distribution does not affect the
decision between native or cross-platform approach in that sense they are key
criteria. Supported development platforms, such as Microsoft Windows and Apple
MacOS, does not affect approach since choosing developing for iOS require a
macOS environment. Distribution channels and Global application distribution
handles the distribution of the application and multiple languages within an app.
Monetisation covers the complexity of selling the app. These are not key criteria
related to select between native or cross-platform development approach.

25
2.2.2.2 Development perspective by Rieger et al. (2016)

Rieger et al. (2016, p 10-12) identifies following 11 criteria for selecting cross-
platform framework from the development perspective which is further described
in Annex 5:

1. Development environment
2. UI design approach
3. Testing support
4. Speed of development
5. Deployment support
6. Preparation time
7. Scalability
8. Development process fit
9. Maintainability
10. Extensibility
11. Integrating native code

 Development environment
The maturity and features of an IDE has a big impact of the development
productivity and speed. Tools support includes functionalities such as auto-
completion, debugging tools and emulator. The freedom of choosing a preferred
IDE lowers the initial setup effort for additional dependencies such as runtime
environment of SDK.

 UI Design Approach
UI is a major concern for cross-platform approaches. Graphical user interfaces are
highly platform specific and often covered by a default appearance defined by the
framework. WYSIWYG editors for creating appealing interfaces for multiple devices
can be beneficial and increases the speed of development.

 Testing Support
Application logic and user interfaces needs to be tested with established concepts
such as system and unit tests. To test context-sensitive mobile scenarios external
influences may be simulated. Providing a developer console, meaningful error
reporting, logging functionalities and debugging on a connected device are
possibilities to evaluate.

 Speed of Development
Amount of boilerplate code necessary for functional application skeletons and the
availability of typical application functions such as user authentication has an
impact of the speed of development.

26
These four criteria are all important when selecting native or cross-platform
approach. Development environment and Testing support are linked together and
is a criterion from the perspective on how the testing tools (and debugging) used
by company is supported in each approach. UI design approach is also a key
criterion in terms of how well each approach support the GUI components needed
by the app. Speed of development is a key criteria in terms of which approach the
company can maintain and develop changes in the application without affecting the
speed

The remaining seven criteria, 5) Deployment support, 6) Preparation time, 7)

Scalability, 8) Development process fit, 9) Maintainability, 10) Extensibility and 11)
Integrating native code does not affect the decision between native or cross-
platform approach in that sense they are key criteria. Deployment support covers
how individual packages can be deployed for several platforms and is only
applicable on a cross-platform approach. Preparation time is how fast a developer
can be acquainted with a specific cross-platform framework, Development process
fit evaluates organisational terms of developer specialization. Therefore, they are
more a matter of competence available in the company than the aspect of choosing
native or cross-platform. Scalability covers how each framework can handle
modularisation and Maintainability how the framework handles the code base over
time and Extensibility how well a framework can be extended with third party
libraries and therefore not applicable in the context of choosing development
approach. Integrating native code is also only a cross-platform criteria since a native
approach only handles native code.

2.2.2.3 Application perspective by Rieger et al. (2016)

Rieger et al. (2016, p 12-14) identifies following nine criteria for selecting cross-
platform framework from the development perspective which is further described
in Annex 6:

1. Access to Device-specific hardware

2. Business integration
3. Access to Platform-specific functionality
4. Support for connected devices
5. Input device heterogeneity
6. Output device heterogeneity
7. Application life cycle
8. Security
9. Fallback handling

27
  Access to Device-specific Hardware
It is of big importance in cross-platform approaches to access platform- and device-
specific hardware. This includes sensors such as camera, microphone, GPS,
accelerometer, gyroscope, magnetometer, temperature sensor and heart rate
monitor.

 Business integration
Applications may communicate with existing Web service back-end for data storage
and processing or initiate inter-application communication.

These two criteria are important when selecting native or cross-platform approach.
Access to device-specific hardware is, as discussed previously during the review of
Heitkötter’s framework, an important criterion since the native approach gives
access full access to all device features whereas cross-platform most often only
provide a subset of all features by default. Business integration is important when
developing online or B2B applications and therefore a criteria where native and
cross-platform approaches differ in support and need to be taking into
consideration when deciding.

The remaining seven criteria, 3) Access to platform-specific functionality, 4) Support

for connected devices, 5) Input device heterogeneity, 6) Output device
heterogeneity, 7) Application life cycle, 8) Security and 9) Fallback handling do not
affect the decision between native or cross-platform approach in that sense they
are key criteria. Access to platform-specific functionality such as the file system,
contact lists and battery status is not a criterion for selecting native or cross-
platform. According to Rieger et al. (2016, p 12-13) Support for connected devices
functionality may be trivial but can also be complex depending on the cross-
platform approach. Security is a criterion for evaluating the vulnerability of a cross-
platform framework, Fallback handling covers how well an application can handle
unexpected behaviour and Application life cycle the aspects when an application
starts, stops and resumes and are not a key criterion selecting approach. Input- and
Output device heterogeneity covers how well a framework handles different input
such as gestures and output in terms of screen resolutions.

2.2.2.4 Usage perspective by Rieger et al. (2016)

Rieger et al. (2016, p 14) identifies following four criteria for selecting cross-
platform framework from the development perspective, which is described further
in Annex 7:

1. Look and feel

2. Performance

28
 3. Usage patterns
4. User management

 Look and feel

This evaluates if the UI elements of the framework have a native look and feel or
behave like a Web page. Rich user interfaces with 2D/3D animations and
multimedia features are challenging for cross-platform tools. It should be
considered in what extent the framework supports the platform-specific usage
philosophy.

 Performance
The speed, responsiveness of user actions and stability are essential performance
aspects. The user experience is subjective but speed at start-up, after shutdown
and after interruptions can be measured. Also, CPU, RAM and battery usage at
runtime can be assessed.

These two criteria are important when selecting native or cross-platform approach.
Look and feel with the meaning of accessing different UI-components is also an
important criterion since native development provides full support for all UI
elements whereas cross-platform is restricted to the framework. Performance
could be different depending whether the application is developed natively or in a
cross-platform environment. The importance and impact of this is very dependent
on what type of application that is developed and for some applications the
performance is essential.

The remaining two criteria, 3) Usage patterns and 4) User management does not
affect the decision between native or cross-platform approach in that sense they
are key criteria. User patterns evaluates how well an application integrates into
personal workflows and User management in what extent a cross-platform
framework supports local user accounts and server-based authentication.

Based on Rieger et al. work 2016 (p 8-14) with four perspectives, Rieger et al.
further extends the criteria for selecting cross-platform approach in the work
published 2019 (p 180-186). With this work, Rieger et al. (2019, p 176) propose
steps forward to become the definite framework for evaluating cross-platform
development approaches with weighting capabilities that offer individualisation
and customization. Rieger et al. (2019, p 179) describes the four perspectives as

1. Infrastructure: Supported platforms, aspects of licensing etc

2. Development: Criteria for developing applications such programmers and
software engineers will ask for
3. App: How well the framework support native support functionality

29
 4. Usage: Non-functional requirements such as performance and user-
friendliness.

The contribution in Rieger et al. 2019 (p 180-186) work is first to provide an

evaluation framework for cross-platform development on app-enabled devices.
They also provide weight profiles to be used in conjunction with the framework,
enable a non-generic usage of the framework which allows user to adapt it to their
company- or project-specific needs (Rieger et al. 2019, p 179).

Rieger et al. (2019, p 187) present a weight % for each criterion indicating the
importance. Each of the 33 criteria receive a weight between 1-7 where the total is
100 points. The weight for each criterion is presented in Annex 12.

2.2.2.5 Infrastructure perspective by Rieger et al. (2019)

Rieger et al. (2019, p 180-182) identifies following seven criteria for selecting cross-
platform framework from the infrastructure perspective which is further described
in Annex 8:

1. License
2. Supported target platforms
3. Long-term feasibility
4. Supported development platforms
5. Distribution channels
6. Monetisation
7. Internationalization

 License
For commercial development, a framework’s license is important. Does the
framework have any restrictions to the usage of developed applications? Does the
licensing model allow modifications of the framework? The pricing model is also of
importance and evaluated in this criterion.

 Supported target platforms

The reason for using a cross-platform framework is for being able to reach
several platforms but only develop once. This criterion is therefore very
important. Two versions of a platform might be different enough to consider
developing for them to be the same as developing for two distinct platforms.

 Long-term feasibility
The choice of application development approach can be a strategic decision
and a commitment for many years. The chosen framework must be

30
evaluated from the perspective of the company developing the framework
as well as a possible technological lock-in.

These three criteria are all important when selecting native or cross-platform
approach. License include the pricing model affordable by the company and
if there are any restrictions in the framework limiting needed modifications.
Supported target platforms is the essence of selecting native or cross-platform
approach, the number of platforms the company need to target and is therefore
also an important criterion. Long-term feasibility, besides the rapidity in releasing
bug-fixes and new OS features, also implies the risk of selecting one approach over
another and is also a criterion that needs to be taking into consideration when
selecting approach.

The remaining four criteria, 4) Supported development platforms, 5) Distribution

channels, 6) Monetisation and 7) Internationalization does not affect the decision
between native or cross-platform approach in that sense they are key criteria.
Supported development platforms, such as Microsoft Windows and Apple MacOS,
does not affect approach since choosing developing for iOS require a macOS
environment. Distribution channels evaluates if a specific cross-platform
framework differs in compatibility for different application store restrictions.
Internationalization covers multiple languages and localisation of an app.
Monetisation is the complexity of selling the app. These are not key criteria related
to select between native or cross-platform development approach.

2.2.2.6 Development perspective by Rieger et al. (2019)

Rieger et al. (2019, p 182-183) identifies following 12 criteria for selecting cross-
platform framework from the development perspective which is further described
in Annex 9:

1. Development environment
2. Testing
3. User interface design
4. Continuous delivery
5. Pace of development
6. Preparation time
7. Scalability
8. Development process fit
9. Configuration management
10. Maintainability
11. Extensibility

31
 12. Integrating custom code

 Development environment
Evaluation of integrated development environment (IDE) and its features like auto-
completion, integration of library documentation, built-in debuggers and emulator
support to help developers.

 Testing
Besides from regular unit tests the context-sensitivity of mobile devices must be
fulfilled. Mobile scenarios, such as phone calls when using the application and
varying connectivity, must be taken into consideration when testing. Remote
debugging the device is preferable compared to using an emulator.

 User interface design

Most applications are user-centred which makes the user interface (UI) design an
essential part of the app. Graphical user interfaces (GUI) are in most cases specific
to the platform and often only covered by the default appearance defined by the
framework.

 Continuous delivery
An app’s lifecycle include deployment. When using an agile method using platforms
to automate building, testing and deployment of an application can be used.
Frameworks can be designed to integrate with such toolchains by offering project-
specific scripts, advanced build options and continuous application store
integration for publishing updated versions.

 Pace of development
The influencing factors like for example the amount of boilerplate code necessary
for functional application skeletons. The overall development speed has a direct
impact of the costs and ultimately the return-on-investment.

These five criteria are all important when selecting native or cross-platform
approach. Development environment and Testing are linked together and is a
criterion from the perspective on how the testing tools (and debugging) used by
company is supported in each approach. UI design approach is also a key criterion
in terms of how well each approach support the GUI components needed by the
app. Continuous delivery covers continuous integration and continuous application
store integration. Pace of development is a key criterion in terms of which approach
the company can maintain and develop changes in the application without affecting
the speed.

The remaining seven criteria, 6) Preparation time, 7) Scalability, 8) Development

process fit, 9) Configuration management, 10) Maintainability, 11) Extensibility and

32
12) Integrating custom code does not affect the decision between native or cross-
platform approach in that sense they are key criteria. Preparation time is how fast
a developer can be acquainted with a specific cross-platform framework.
Development process fit evaluates organisational terms of developer
specialization. Therefore, they are more a matter of competence available in the
company than the aspect of choosing native or cross-platform. Scalability covers
how each framework can handle modularisation and Maintainability how the
framework handles the code base over time and Extensibility how well a framework
can be extended with third party libraries and therefore not applicable in the
context of choosing development approach. Development process fit covers how
the development process in a cross-platform framework adapts to the company’s
strategy. Configuration management is a criterion for theming and different user
privileges. Integrating custom code covers how well a cross-platform framework
handles integration native code and custom libraries and therefore only a cross-
platform criteria since a native approach already handles native code.

2.2.2.7 Application perspective by Rieger et al. (2019)

Rieger et al. (2019, p 183-185) identifies following ten criteria for selecting cross-
platform framework from the application perspective which is further described in
Annex 10:

1. Access to device-specific hardware

2. System integration
3. Access to platform-specific functionality
4. Support for connected devices
5. Input device heterogeneity
6. Output device heterogeneity
7. Application life cycle
8. Security
9. Robustness
10. Degree of mobility

 Access to device-specific hardware

A lot of device hardware is available today such as camera, microphone, GPS,
accelerometer, gyroscope and temperature scale. Frameworks with poor support
for device specific hardware is a risk where feature-poor applications are
developed.

33
  System integration
Many applications are using a back-end system for feeding the application with
data. Frameworks support different options for data exchange protocols,
serialisation and multiple data formats.

These two criteria are important when selecting native or cross-platform approach.
Access to device-specific hardware is, as discussed previously during the review of
Heitkötter’s framework, an important criterion since the native approach gives
access full access to all device features whereas cross-platform most often only
provide a subset of all features by default. System integration is important when
developing online or B2B applications and therefore a criteria where native and
cross-platform approaches differ in support and need to be taking into
consideration when deciding.

The remaining eight criteria, 3) Access to platform-specific functionality, 4) Support

for connected devices, 5) Input device heterogeneity, 6) Output device
heterogeneity, 7) Application life cycle, 8) Security, 9) Robustness and 10) Degree of
mobility does not affect the decision between native or cross-platform approach in
that sense they are key criteria. Access to platform-specific functionality such as the
file system, contact lists and battery status is not a criterion for selecting native or
cross-platform. According to Rieger et al. (2019, p 183-184) Support for connected
devices functionality may be trivial but can also be complex with explicit support
depending on the cross-platform approach. Security is a criteria for evaluating the
vulnerability of a cross-platform framework, Robustness covers how well an
application can handle unexpected behaviour and Application life cycle the aspects
when an application starts, stops and resumes and are not a key criterion selecting
approach. Input- and Output device heterogeneity covers how well a framework
handles different input such as gestures and output in terms of screen resolutions.
Degree of mobility evaluates how well a cross-platform supports four different
categories of mobility: Stationary, Mobile, Wearable and Autonomous.

2.2.2.8 Usage perspective by Rieger et al. (2019)

Rieger et al. (2019, p 185-186) identifies following four criteria for selecting cross-
platform framework from the usage which is further described in Annex 11:

1. Look and feel

2. Performance
3. Usage patterns
4. User authentication

34
  Look and feel
The user interface should have a native look and feel rather than look like a web
site. If generated applications use a truly native interface, it should be created in
the way typical for the platform. Applications should support the platform-specific
usage philosophy like the position of navigation bars, scrolling and gestures.

 Performance
Poorly performed applications would likely have low user acceptance. With
performance means application load time, speed for changing views and
computations resulting from user interactions. Performance also includes CPU-
load, battery drain during runtime and download size.

These two criteria are important when selecting native or cross-platform approach.
Look and feel with the meaning of accessing different UI-components is also an
important criterion since native development provides full support for all UI
elements whereas cross-platform is restricted to the framework. Performance
could be different depending whether the application is developed natively or in a
cross-platform environment. The importance and impact of this is very dependent
on what type of application that is developed and for some applications the
performance is essential.

The remaining two criteria, 3) Usage patterns and 4) User authentication does not
affect the decision between native or cross-platform approach in that sense they
are key criteria. User patterns evaluates how well an application integrates with
other applications and how an application can restore data when a user returns
after closing the app. User authentication in what extent a cross-platform
framework supports local user accounts and server-based authentication.

2.3 Comprehensive Decisional Framework for Native vs Cross-Platform

Development
The previous frameworks with its lists of criteria are too broad with limited
perspectives and do not cover the decision on whether to choose a native or a
cross-platform approach.

In this chapter, we update and expand the previous list of criteria from Rieger et al.
(2019, p 180-186), detail the criteria to achieve a measurement level and complete
it with new criteria that are related to the company’s profile.

2.3.1 Takeaway from Pre-existing Models

Heitkötter et al. (2103, p 6-7, p 15-16) is presenting a much more detailed list of
criteria compared to Dalmasso et al. (2013, p 1). Heitkötter’s list is still lacking a

35
measurement level to evaluate the criteria and needs to be updated with more
recent aspects presented by Rieger et al. (2016, p 8-14) and Rieger et al. (2019, p
180-186). The criteria from the development perspective by Heitkötter et al. (2013,
p 6-7, p 15-16) is for example missing the testing and debug criterion. As described
earlier, Biørn-Hansen et al. (2019, p 8) state that native development tools are
easier to test and debug compared to a cross-platform development, and therefore
would be an important factor when evaluating the development perspective of a
native vs cross-platform approach. The criterion GUI design (in Development
perspective) is not elaborated in the way you could use it as a criterion since the
demands on GUI is differs depending on what segment the application is targeting.
As Long (2017), states the UI is more important in an application targeting a B2C
segment compared to a B2B solution and this criterion would therefore have to be
in a more detailed level to decide from it. The Development perspective also lack
the criterion of competence. When selecting approach, it is of big importance of
which competence the company has to offer. As described in criterion Development
environment development for Android is done using Java and iOS using Objective-
C. According to Manchada (2019) development using cross-platform tool Xamarin
is done using C# which could make some companies voting in favour of using that
tool instead of a native approach since that competence might already exist in the
company.

The four perspectives with its 33 criteria presented by Rieger et al. (2019, p 180-
186) are valuable for selecting among different cross-platform frameworks. They
are, however, not intended to act as criteria selecting between native or cross-
platform approach. These criteria do cover many aspects when making such
selection. To help selecting between native or a cross-platform approach, these
criteria are lacking tangible measures and needs to be in a more detailed level which
this paper covers with the new decisional framework.

2.3.2 New Decisional Framework

Developing applications is big business. In 1st quarter 2020 a total of 2 560 000
applications were available on Google Play and 1 847 000 applications on Apple
Application Store (Clement, 2020). Together that is more than 4 million applications
available for download, meaning many companies already chose approach or are
in the situation of determining if native or cross-platform approach is best decision.
A decision already made might also be open for re-decision. A complex application
can cost up to $250 000 if developed in USA (Pratap, 2018) and therefore taking the
wrong decision having to re-write the entire application can be very expensive. By
establishing key criteria, this thesis work will help decision makers avoid taking
subjective decisions and, in the end, save money from taking a wrong decision.

36
Based on the perspectives from Heitkötter et al. (2013, p 6-7) and further expanded
by Rieger et al. (2016, p 8-14) and Rieger et al. (2019, p 180-186) this thesis present
a number of key criteria to help decision makers decide whether they will develop
application using native or cross-platform approach. A new perspective, Business
environment, is introduced that covers the company profile and the market the
application is targeted to.

By providing a more detailed and in-depth criteria selection for Infrastructure and
Development perspective and adding the Business perspective, there are complete
and enough decision factors to make the decision to take a native or a cross-
platform application development approach without the need of the Application
and Usage perspective introduced by Rieger et al. (2019, p 183-186).

Rieger et al. (2019, p 187) is using a weight mechanism where each 33 criteria
receive a weight between 1-7 with a total of 100 points making each point
represent a 1% weight. To present only the key criteria for Infrastructure and
Development perspective, only those with a weight % between 3-7 (Rieger et al.
2019, p 188), as seen in Annex 12, are used.

This thesis work review and discuss each of these, highlight those criteria that may
weight heavier in the decision making and complement Rieger et al. (2019, p 180-
186) list with tangible measures of each previous established criteria and with
complementary list of criteria. In fact, mobile development projects in the last
decade have shown importance of a number of additional aspects, mainly related
to the business activity of the mobile platform provided.

2.3.2.1 Business environment perspective

The Business environment perspective covers aspects about the company and the
market the application is targeting.

Company profile
The profile of the company is an important criterion when choosing strategy.
According to Francese et al. (2017, p 138) developing a native application for each
platform require companies to have developers with strong expertise on iOS and
other with strong expertise on Android. Developers must maintain UI patterns on
multiple platforms keeping in mind the similarity of these patterns among different
devices.

If the company does not have resources to maintain several platforms but need to
target both iOS and Android, they probably would be suited with a cross-platform
approach. Therefore, the aspects of HR management to handle several

37
development teams and the agility in budget to switch platform are important
criterions.

For these criteria, the following detailed criterion can be established:

 Agility in HR management (includes all aspects related to employees) to

maintain selected approach
 Agility in budget (cost of developing for several platforms, cost of hiring
developers to reach desired speed of development, cost to switch platform
if needed)

Competence
Developing native applications for Android OS is done using Koitlin, Java or C++
programming languages (Android Developer Fundamentals, 2019) and for iOS using
Swift or Objective-C (Apple Developer, 2020). Cross-platform tools offer other
programming languages like C# in Xamarin or JavaScript in React Native (Dev
Technosys, 2020). The needed competence is based on the choice of native or
cross-platform approach, but also the competence that already exists in the
company, as well as the possibility to find competence the company might need to
recruit. Also related to long-term feasibility in 2.3.2.2, some companies might
anticipate it will be easier to recruit programmers with C# experience and use
Xamarin than programmers with Swift-competence needed for a native iOS
approach, and therefore choosing a cross-platform approach. According to
Majchrzak et al. (2015, p 74) the language best suitable for a business application
depends on the developer base existing in the company.

For these criteria, the following detailed criteria can be established:

 Deploy competence already available in the company

 Deploy competence available in market recruiting developers

B2C or B2B Market

B2C applications fulfil individual customers’ need and can be categorized as
content-, marketing- or service-oriented applications (Cortimiglia et al., 2011, p 2).
B2C applications are the most well-known applications and the one is most often
found in places as the application store. They are costlier to implement and
maintain due to the need of frequent updates in response to user feedback and
user interface since the user experience is of big importance for this application in
genre (Long, 2017). B2B applications support a company’s internal business process
such as warehouse management, sale-force automation or customer-relationship
management (Cortimiglia et al., 2011, p 2). The need of device specific hardware or
device API is also of importance. According to Rieger et al. (2019, p 192) native

38
applications can access all possible features of a given platform. If this is important
for delivering the desired solution, a native approach can be suitable.

Ruggedized handheld device solutions are used in industrial, retail, and service-
based organisations. They are designed to operate properly in dirty environments,
in extreme temperatures and designed to withstand a series of shocks and drops
(Burch et al. 2016, p 146). Companies purchasing ruggedized devices usually follow
a five- to seven-year life cycle. (ibid, 2016, p 147).

Two of the key vendors delivering rugged mobile devices are Zebra and Honeywell
(Businesswire, 2018). Zebra offer SDK for Android and Xamarin (Zebra, n.d.) and
Honeywell offer SDK for Android, iOS, Windows and Web (Honeywell, n.d.). Besides
from Zebra offering SDK for Xamarin, these two companies only offer native
development support for integrating their device hardware.

B2C applications are under pressure to outdo rivals in terms of performance,

responsiveness, loading speed, content development, content sharing and social
media sharing (Smart Sight Innovations, n.d.). This condensate to delivering an
application with high performance giving the performance an important criterion
when selecting approach.

For these criteria, the following detailed criterion can be established:

 Provide support for required system integration (back-end and cloud)

needed in the application
 Deliver needed access to device specific hardware or device API
 Needed application performance

When in time
When to switch from native to cross-platform, or the other way around, is also a
criterion that needs to be taken into consideration. Angione (2011) presents three
different levels of software customization 1) Individualization, 2) Tailoring and 3)
Core Code Changes and New Custom Software Modules.

Individualization is the first level of customization and is done by configuration, for

example adding a corporate logo or a colour scheme that reflects a corporate
design. This level requires a low level of effort to implement and maintain (ibid,
2011).

The second level of customization is Tailoring and imply changes made in the
software to fit a company’s organizational process. Tailoring may involve
implementing new modules, tailor features to better suit a given task such as

39
vocabulary and application defaults or adding new encapsulated user functions
(ibid, 2011).

The third level of customization is Core Code Changes and New Custom Software
Modules. This level frequently undermines the confidence of the packaged
software’s integrity and the overall application’s evolvability. This level brings
complexity of true software development, integration and testing during each
revision/upgrade cycle (ibid, 2011).

The level of customization and needed approach can be illustrated using this matrix
in Figure 3:

Number of Cross-platform Cross-platform Native

customizations

Both Both Native

Individualization – Tailoring – Core code changes

Level of customization

Figure 3 Matrix suggesting best approach from level of customization compared with
number of customizations done in the app

For these criteria, the following detailed criterion can be established:

 Perform customization with core code changes of the application requiring

a heavy technical expertise
 Handle high number of customizations done frequently of the application
which also impact the maintenance of the application

2.3.2.2 Infrastructure perspective

The infrastructure perspective comprises criteria relating to the life cycle of an app,
its usage, operation and functionality/functional range (Heitkötter et al. 2013, p 6).

License
The pricing model is also of importance and evaluated in this criterion. Native
Android development is free of charge whereas iOS development comes with an
annual fee of $99 - £299 (Apple Developer Purchase, 2020). The license model for

40
the framework might also interfere with the modifications needed to develop the
app.

For these criteria, the following detailed criterion can be established:

 Meet pricing model

 Handle restrictions of needed modifications in the framework

Target platforms
The reason for evaluating native or cross-platform approach is the need of different
OS platforms to be supported. What is the platform or platforms that the company
needs that application to be targeted for? Does the application need to be available
for several platforms? This criterion is related to Company profile and Competence
in 2.3.2.1.

For these criteria, the following detailed criterion can be established:

 Migrate existing software platform into new mobile application

 Deliver the application to targeted/needed operating system(s)

Long-term feasibility
The choice of application development approach can be a strategic decision and a
commitment for many years. The chosen framework must be evaluated from the
perspective of the company developing the framework as well as a possible
technological lock-in (Rieger et al. 2019, p 181). This also applies on the selection of
native vs cross-platform approach. Selecting a cross-platform approach also means
that the company locks the technological development in the hands of the
framework. Choosing native approach can also be considered a lock-in to that
specific OS. Rieger at al. (2019, p 181) highlights that this criterion is especially
important for small companies which might lack the resources to correct an ill
choice. Since iOS and Android has emerged as stable duopoly of smartphone
operating system vendors, long-time reliability is ensured on a native approach
(Rieger et al. 2019, p 192).

For these criteria, the following detailed criterion can be established:

 Provide technical support

 Offer new features in the application delivered by OS manufacturer
 Handle the risk of OS manufacturer will drop support for development tools
used in selected approach

41
 2.3.2.3 Development perspective
The development perspective comprises all criteria that are directly related to the
development process of the app, e.g. topics like testing, debugging and
development tools (Heitkötter et al. 2013, p 6). Since Development environment
and Testing in a selection between native or cross-platform approach is close to
each other, they are presented as one criterion.

Development environment and testing

The development environment can be one critical criterion if none of the previous
criteria has voted in favour for one approach over another. The more advanced
applications that is developed, the bigger is the need for a rich development
environment. Biørn-Hansen et al. (2019, p 8) conduct that cross-platform
development tools are not as easy to test and debug as native development tools.

For these criteria, the following detailed criterion can be established:

 Test fragmented platforms supported by the application

 Support testing tools used by the company

Preparation time
The time it takes for a developer to get acquainted with the framework and
application platform is depending on the required technology stack and
programming languages. This is covered by Company profile and Competence in
2.3.2.1. The competence already existing in the company will provide information
on how fast they can be productive, and the company’s agility determine how fast
they can provide the developers with needed courses to be productive.

UI design
Most applications are user-centred which makes the user interface design an
essential part of the app. Graphical user interfaces are in most cases specific to the
platform and often only covered by the default appearance defined by the
framework (Rieger et al. 2019, p 182). Cost savings by shared code is only done
when designs are simple to not require platform-specific accommodations to be
made for UI designs and functionality. Where beautiful design with animations,
scrolling and transitions is important, it might be more beneficial of using native
libraries (Campbell, n.d,). Francese et al. (2017, p 139) conclude that if the demands
on the UI is fancy native UI, animations, 3D rendering, or intensive hardware is
needed, then the application should be developed native.

For these criteria, the following detailed criterion can be established:

 Support advanced GUI features needed in the application such as 3D

rendering components and AR/VR components

42
Continuous delivery
An app’s lifecycle also include deployment. With an agile method companies can
use platforms to automate building, testing and deployment of an app. There is also
of importance with continuous application store integration to publish an
application in a fast an easy way without affecting the workload of the development
team.

For these criteria, the following detailed criterion can be established:

 Support continuous delivery in automate building, testing and deployment

 Provide continuous application store integration

Pace of development
The overall development speed has a direct impact of the costs and ultimately the
return-on-investment. If a company with a small development team want to target
both iOS and Android, a cross-platform approach will most probably be best suited
since they do not have resources to develop native for two platforms at the same
time. This criterion is closely related to criteria Company profile and Competence in
2.3.2.1 and Target platforms in 2.3.2.2. Pace of development criteria will not be
evaluated from the perspective of maintaining several platforms since that is
covered in Company profile and Competence. If there are any limitations in a cross-
platform approach making development pace slower this must be addressed. There
could be limitations in a cross-platform framework that the company must
compensate for to get needed functionality in the app. Customizations done in the
framework in the core code changes level (as described in 2.3.2.1 When in time)
might address limitations that slows done the development pace.

For these criteria, the following detailed criterion can be established:

 Handle customizations in the core code changes level without affecting pace
of development

2.3.3 List of criteria for selecting native vs cross-platform

Based on the weighting used by Rieger et al. (2019, p 187) each 22 criteria receive
a weight from 1-7 with a total of 100 points, making each point represent a 1%
weight.

The evaluated criterion should be assigned a score from 5 (we definitely can fulfil
requirements) to 0 (we definitely cannot fulfil requirements), indicating in what
extent the company has capacity to fulfil native respectively cross-platform
development approach. The impact each criterion has when selecting approach
depends on the company. Therefore, this thesis provides a list with a weight and

43
each company then enters a score from 0-5 as described above how the company
can fulfil the requirement. After the company has entered the score for native and
cross-platform for each criterion, they then use the formula below to calculate
which approach gives the highest score and thereby indicating which approach is
best suited for the company and thereby avoiding subjective decisions. Say, for
example, decision makers in a company working with C# development is focusing
on the fact that they only will target the Android platform. Therefore, they take the
decision on a native approach. They oversee the fact that they do not need a native
GUI appearance, no access to device specific hardware and have no competence of
Java within the company. In this case a cross-platform approach with Xamarin and
C# might have been a better solution. By weighting the different criteria, such a
scenario is hopefully avoided.

The overall score S for each approach (native and cross-platform) is calculated as
the weighted arithmetic mean of the criteria using this formula borrowed from
Rieger et al. (2019, p 187):

∑ 𝑤 , ∗ 𝑏𝑒 + ∑ 𝑤, ∗ 𝑖 + ∑ 𝑤 , ∗ 𝑑
𝑆=
100

𝑤 = 100

Where 𝑏𝑒 , 𝑖 and 𝑑 being the criteria score from the business environment,
infrastructure and development perspective respectively, and 𝑤 , , 𝑤 , and 𝑤 ,
the corresponding weights for each criterion. The approach with the highest
weighted score will then indicate which approach is the best suited for the
company.

On the next two pages the framework is presented in Table 1. One column contains
the criteria divided into the three perspectives: Business environment,
Infrastructure and Development. The next column is the weight% for each criterion
where the sum of all criterion equals 100. The last two columns contain the
fulfilment level for native and cross-platform approach, respectively. The company
will use this to enter the score from 0 (we definitely cannot fulfil requirements) to
5 (we definitely can fulfil requirements). The weight for each criterion will be
defined through the empirical study with help from professionals from the field.

44
 1-7 Fulfilment (0-5)
5 = We definitely can fulfil
requirements to:
0 = we definitely cannot fulfil
requirements to:
Criterion Weight % Native Cross-
approach platform
approach
Business environment perspective
Company profile
BE1 Be agile in HR management (all ?
aspects related to employees) to
maintain selected approach.
BE2 Be agile in budget (cost of ?
developing for several platforms,
cost of hiring developers to reach
desired speed of development, cost
to switch platform if needed)
Competence
BE3 Deploy competence already available ?
in the company
BE4 Deploy competence available in ?
market recruiting developers
B2B or B2C
BE5 Provide support for required system ?
integration (back-end and cloud)
needed in the app
BE6 Deliver needed access to device ?
specific hardware or device API
BE7 Needed application performance ?
When in time
BE8 Perform customization with core ?
code changes of the application
requiring a heavy technical expertise
BE9 Handle high number of ?
customizations done frequently of
the application which also impact the
maintenance of the app

Infrastructure perspective
License
I1 Meet pricing model ?
I2 Handle restrictions of needed ?
modifications in the framework
Target platforms
I3 Migrate existing software platform ?
into new mobile app

45
 1-7 Fulfilment (0-5)
5 = We definitely can fulfil
requirements to:
0 = we definitely cannot fulfil
requirements to:
Criterion Weight % Native Cross-
approach platform
approach
I4 Deliver the application to ?
targeted/needed operating system(s)
Long-term feasibility
I5 Provide technical support ?
I6 Offer new features in the application ?
delivered by OS manufacturer
I7 Handle the risk of OS manufacturer ?
will drop support for development
tools used in selected approach

Development perspective
Development environment and
testing
D1 Test fragmented platforms ?
supported by the application
D2 Support testing tools used by the ?
company
User interface design.
D3 Support advanced GUI features ?
needed in the application such as 3D
rendering components and AR/VR
components
Continuous delivery
D4 Support continuous integration, ?
automate building, testing and
deployment
D5 Provide continuous application store ?
integration
Pace of development
D6 Handle customizations in the core ?
code changes level without affecting
pace of development
Sum 100
Weighted score
Table 1 Comprehensive decisional framework for native vs cross-platform development

46
 2.3.4 Summary earlier research and contribution made by this thesis
Table 2 provides a summary of earlier research and contribution made by this
thesis of the different criteria. The weight for each criterion will be defined
through the empirical study with help from professionals from the field.

Aurelius 2020 Rieger et al. 2019 (p Rieger et al. 2016 (p 8- Heitkötter et al.
180-186) 14) (2013, p 6-7, p 15-16)
Company profile
Be agile in HR
management (all aspects
related to employees) to
maintain selected
approach.
Be agile in budget (cost of
developing for several
platforms, cost of hiring
developers to reach
desired speed of
development, cost to
switch platform if needed)
Competence
Deploy competence
already available in the
company
Deploy competence
available in market
recruiting developers
B2B vs B2C
Provide support for
required system
integration (back-end and
cloud) needed in the app
Deliver needed access to
device specific hardware
or device API
Needed app application
performance
When in time
Perform customization
with core code changes of
the app application
requiring a heavy technical
expertise
Handle high number of
customizations done
frequently of the app

51
Aurelius 2020 Rieger et al. 2019 (p Rieger et al. 2016 (p 8- Heitkötter et al.
180-186) 14) (2013, p 6-7, p 15-16)
application which also
impact the maintenance of
the app
License License and Costs
Meet pricing model
Handle restrictions of
needed modifications in
the framework
Target platforms Supported Platforms
Migrate existing software Access to platform-
platform into new mobile specific features
app
Deliver the app application Development platforms
to targeted/needed
operating system(s)
Distribution channels Distribution
Look and feel
Monetization
Internationalization
Application Speed
Long-term feasibility
Provide technical support
Offer new features in the
app application delivered
by OS manufacturer
Handle the risk of OS
manufacturer will drop
support for development
tools used in selected
approach
Development and testing Development environment
environment
Test fragmented platforms Preparation time Ramp-up time
supported by the app
Support testing tools used
by the company
Scalability Scalability Scalability
Ease of development
Speed and Cost of
Development
Maintainability
Opportunities for
further development
Development process fit
UI Design GUI Design

52
 Aurelius 2020 Rieger et al. 2019 (p Rieger et al. 2016 (p 8- Heitkötter et al.
180-186) 14) (2013, p 6-7, p 15-16)
Support advanced GUI
features needed in the app
application such as 3D
rendering components and
AR/VR components
Testing Test support
Continuous delivery Deployment support
Support continuous
integration in automate
building, testing and
deployment
Provide continuous app
application store
integration
Configuration
management
Maintainability Maintainability
Extensibility Framework Extensibility
Native Extensibility
Customer code
integration
Pace of development Pace of development Speed of development
Handle customizations in
the core code changes
level without affecting
pace of development
Hardware access
Platform functionality
Connected Devices
Input heterogeneity
Output Heterogeneity
App Application Life Cycle
System Integration
Security
Fallback handling
Robustness
Degree of Mobility
Look and Feel
Performance
Usage Patterns
User authentication
Table 2 Comparison of previous work and contribution made by the thesis work

53
 3. Empirical Study
Empirical study to allocate weight for selected criteria qualifies as a quantitative
research methodology. In fact, we use a survey technique to collect data from
professionals in the mobile applications development field to establish the weight
of each criteria in chapter 2.3.2. Leedy et al. (2015, p 23) describes a quantitative
research where the researcher tries to measure variables in some numerical way.
When measuring the outcome of a research, Leedy et al. (2015, p 27-28)
emphasizes that the researcher needs a systematic way of measuring the
phenomena under investigation such as rulers, scales, length or weight. In this
thesis each criterion is given a score from 1-7 as introduced by Rieger et al. (2019,
p 187), indicating the weight it should have on the selection between native or
cross-platform development approach.

3.1 Data Collection

Leedy et al. (2015, p 99) presents typical characteristics of a quantitative research
where the purpose of the research is to 1) explain and predict, 2) confirm and
validate and 3) test theory. The quantitative research methodology allows me to
investigate into the key criteria presented in chapter 2.3.2 and verify the weight
that each criterion will have. Quantitative research is often done by reducing the
data to summarizing statistics (means, medians, correlation coefficients) and in
most cases, the average performance is of greater interest than the performance
of specific individuals (Leedy et al. 2015, p 100).

Leedy et al. (2015, p 102) describes a survey research as “A study designed to

determine the incidence, frequency, and distribution of certain characteristics in a
population”. This thesis work is using a survey to determine the weight for each
criterion defined in chapter 2.3.2. Leedy et al. (2015, p 159) further uses a restricted
meaning of a survey research as a research involving acquiring information about
one or more groups of people about their previous opinions and experiences, by
asking them questions and tabulating their answers. In the survey in this thesis,
developers and decision makers in companies developing mobile applications are
asked for their opinion on what weight each criterion in chapter 2.3.2 should have
and if there are any criteria missing they would like to add to the list of criteria.

The criteria in the survey are presented without relation to the perspectives of
Infrastructure or Development. The survey also includes some outliers, criteria that
should not be a part of the decision making, to make sure the sample conducting
the survey is evaluating the criteria thoroughly and not just answering them
without any thoughts. The outliers help to remove human errors or other data that
should not reflect the survey. According to Hodge et al. (2004) outliers is used to

55
remove anomalous observations from data by identify errors and remove their
faulty effect on the data set.

In the survey the outliers are number 23 (Internationalization from Infrastructure

perspective) and 24 (Configuration management from Development perspective)
which both received a weight % of 1 from Rieger et a. (2019, p 188).

The survey includes the following:

 Years of experience to evaluate the reasons behind the answers. A person

with less experience will most probably answer different compared to one
with more experience.
 Position – developer, decision maker, both or other
 Weight 1-7 how the participant value the weight the criteria should have
when selecting native or cross-platform approach
 Question if there are any key criteria missed and would be an essential part
when making the decision.

The survey is done using Artologik Survey and Report provided by Karlstad
University which also provide some analysis of the data.

Along with the ethical considerations in chapter 1.6 the survey is presented with
this introductory text:

“You are invited to participate in this research project because you are a
professional with the right competence and selected to assist in this research. Your
participation in this research study is voluntary.
The procedure involves filling an online survey that will take approximately 10
minutes. Your responses will be confidential and we do not collect identifying
information such as your name, email address or IP address. The survey questions
will be about. key criteria when selecting native or cross-platform mobile application
development. All data is stored in a password protected electronic format. The
results of this study will be used for scholarly purposes only and may be shared with
Karlstad University representatives.”

56
Survey

Years of experience
Position (Developer, Decision Maker, Both or Other)

Criterion Weight % (1-7)

Company profile
1 Be agile in HR management (all aspects related to employees)
to maintain selected approach.
2 Be agile in budget (cost of developing for several platforms,
switch platform if needed)
Competence
3 Deploy competence already available in the company
4 Deploy competence available in market recruiting developers
B2B or B2C
5 Provide support for required system integration (back-end and
cloud) needed in the app
6 Deliver needed access to device specific hardware or device API
7 Needed application performance
When in time
8 Perform customization with core code changes of the
application requiring a heavy technical expertise
9 Handle high number of customizations done frequently of the
application which also impact the maintenance of the app
License
10 Meet pricing model
11 Handle restrictions of needed modifications in the framework
Target platforms
12 Migrate existing software platform into new mobile app
13 Deliver the application to targeted/needed operating system(s)
Long-term feasibility
14 Provide technical support
15 Offer new features in the application delivered by OS
manufacturer
16 Handle the risk of OS manufacturer will drop support for
development tools used in selected approach
Development environment and testing
17 Test fragmented platforms supported by the app
18 Support testing tools used by the company
User interface design
19 Support advanced GUI features needed in the application such
as 3D rendering components and AR/VR components
Continuous delivery
20 Support continuous integration in automate building, testing
and deployment
21 Provide continuous application store integration
Pace of development

57
 22 Handle customizations in the core code changes level without
affecting pace of development

Are there any key criteria that is missed in the survey that is of big
importance when choosing native or cross-platform mobile
application development approach?

Do you think the following criteria could or should be among the list
of criteria when selecting between native or cross-platform mobile
application development approach?

Internationalization
23 Support internationalization and adding multiple languages
Configuration management
23 Support theming and different user privileges

Table 3 Survey

3.2 Analysis and Results

The survey was conducted between May 1st to May 12th 2020 with a total of 8
responders each chosen for the expertise of being either developer, decision maker
or both developers and decision makers in companies developing mobile
applications. Artologik Survey & Report is used as a tool for collecting and analysing
the data. For further analysis of the data Microsoft Excel and Tableau are used.
Based on the quantitative research method, a descriptive data analysis will be
applied.

Years of experience
The years of experience among the respondents had a mean value of 11,3 years,
the min value was 3 and the max value 21. The standard deviation was 6,8 and the
coefficient of variation was 60,4%.

Years of experience 1-5 6-10 11-15 16-20 21-25

Percentage 25% 37,5% 12,5% 12,5% 12,5%
# 2 3 1 1 1
Table 4 Distribution of Years of experience among the sample

The mean value among developers where 6.3 years, among decision makers 17,0
years and the mean value among those defined as both developers and decision
makers was 10,0 years.

58
Position
The positions among the respondents was divided among developer (3
respondents), decision maker (3 respondents) and both developer and decision
maker (2 respondents).

Position Developer Decision maker Both Other

Percentage 37,5% 37,5% 25% 0%
# 3 3 2 0
Table 4 Distribution of Position among the sample

Agility in HR management (includes all aspects related to employees) to maintain selected

approach
The Agility in HR management had a mean value of 4.1, the min value was 2 and
the max value 6. The standard deviation was 1.4 and the coefficient of variation was
32.9%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 12,5% 37,5% 12,5% 0%
# 0 1 2 1 3 1 0
Table 5 Distribution of weight in criteria Agility in HR management

The mean value among developers where 4.0, the mean value among decision
makers 4.7 and the mean value among those defined as both developers and
decision makers was 3.5.

Agility in budget (cost of developing for several platforms, cost of hiring developers to reach
desired speed of development, cost to switch platform if needed)
The Agility in budget had a mean value of 5,3, the min value was 4 and the max
value 7. The standard deviation was 1,0 and the coefficient of variation was 19,7%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 0% 25% 37,5% 25% 12,5%
# 0 0 0 2 3 2 1
Table 6 Distribution of weight in criteria Agility in budget

The mean value among developers where 4.7, the mean value among decision
makers 6.3, and the mean value among those defined as both developers and
decision makers was 4.5.

59
Deploy competence already available in the company
Deploy competence already available in the company had a mean value of 4.5, the
min value was 2 and the max value 7. The standard deviation was 1.6 and the
coefficient of variation was 35.6%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 12,5% 25% 25% 12,5% 12,5%
# 0 1 1 2 2 1 1
Table 7 Distribution of weight in criteria Deploy competence already available in the
company

The mean value among developers where 4,0, the mean value among decision
makers 4,0 and the mean value among those defined as both developers and
decision makers was 6,0.

Deploy competence available in market recruiting developers

Deploy competence available in market recruiting developers had a mean value of
4,3, the min value was 2 and the max value 6. The standard deviation was 1,4 and
the coefficient of variation was 32,7%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 0% 50% 12,5% 0%
# 0 1 2 0 4 1 0
Table 8 Distribution of weight in criteria Deploy competence available in market recruiting
developers

The mean value among developers where 5,0, the mean value among decision
makers 4,3 and the mean value among those defined as both developers and
decision makers was 3,0.

Provide support for required system integration (back-end and cloud) needed in the application
Provide support for required system integration (back-end and cloud) needed in the
application had a mean value of 4,3, the min value was 2 and the max value 7. The
standard deviation was 1,7 and the coefficient of variation was 39,3%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 25% 12,5% 12,5% 12,5%
# 0 1 2 2 1 1 1
Table 9 Distribution of weight in criteria Provide support for required system integration
(back-end and cloud) needed in the app

60
The mean value among developers where 4,0, the mean value among
decision makers 5,7 and the mean value among those defined as both
developers and decision makers was 2,5.
Deliver needed access to device specific hardware or device API
Deliver needed access to device specific hardware or device API had a mean value
of 5,3, the min value was 1 and the max value 7. The standard deviation was 2,0
and the coefficient of variation was 37,8%.

Weight 1 2 3 4 5 6 7
Percentage 12,5% 0% 0% 12,5% 12,5% 37,5% 25%
# 1 0 0 1 1 3 2
Table 10 Distribution of weight in criteria Deliver needed access to device specific hardware
or device API

The mean value among developers where 5,7, the mean value among decision
makers 3,7 and the mean value among those defined as both developers and
decision makers was 7,0.

Needed application performance

Needed application performance had a mean value of 6,3, the min value was 5 and
the max value 7. The standard deviation was 0,9 and the coefficient of variation was
14,2%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 0% 0% 25% 25% 50%
# 0 0 0 0 2 2 4
Table 11 Distribution of weight in criteria Needed application performance

The mean value among developers where 6,0, the mean value among decision
makers 6,7 and the mean value among those defined as both developers and
decision makers was 6,0.

Perform customization with core code changes of the application requiring a heavy technical
expertise
Perform customization with core code changes of the application requiring a
heavy technical expertise had a mean value of 4,0, the min value was 2 and
the max value 5. The standard deviation was 1,2 and the coefficient of
variation was 29,9%.

61
 Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 12,5% 50% 0% 0%
# 0 1 2 1 4 0 0
Table 12 Distribution of weight in criteria Perform customization with core code changes
of the application requiring a heavy technical expertise

The mean value among developers where 4,3, the mean value among
decision makers 4,7 and the mean value among those defined as both
developers and decision makers was 2,5.
Handle high number of customizations done frequently of the application which also impact the
maintenance of the application
Handle high number of customizations done frequently of the application
which also impact maintenance of the application had a mean value of 4,1,
the min value was 2 and the max value 6. The standard deviation was 1,5 and
the coefficient of variation was 35,3%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 25% 12,5% 25% 0%
# 0 1 2 2 1 2 0
Table 13 Distribution of weight in criteria Handle high number of customizations done
frequently of the application which also impact maintenance of the application

The mean value among developers where 4,7, the mean value among
decision makers 4,3 and the mean value among those defined as both
developers and decision makers was 3,0.
Meet pricing model in license
Meet pricing model in license had a mean value of 4,0, the min value was 2
and the max value 7. The standard deviation was 1,8 and the coefficient of
variation was 44,3%.

Weight 1 2 3 4 5 6 7
Percentage 0% 25% 25% 0% 37,5% 0% 12,5%
# 0 2 2 0 3 0 1
Table 14 Distribution of weight in criteria Meet pricing model in license

The mean value among developers where 4,3, the mean value among decision
makers 3,7 and the mean value among those defined as both developers and
decision makers was 4,0.

62
Handle restrictions of needed modifications in the framework
Handle restrictions of needed modifications in the framework had a mean value of
4,1, the min value was 3 and the max value 5. The standard deviation was 0,8 and
the coefficient of variation was 20,2%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 25% 37,5% 37,5% 0% 0%
# 0 0 2 3 3 0 0
Table 15 Distribution of weight in criteria Handle restrictions of needed modifications in
the framework

The mean value among developers where 4,7, the mean value among decision
makers 3,3 and the mean value among those defined as both developers and
decision makers was 4,5.

Migrate existing software platform into new mobile application

Handle restrictions of needed modifications in the framework had a mean value of
4,0, the min value was 2 and the max value 6. The standard deviation was 1,3 and
the coefficient of variation was 32,7%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 25% 25% 25% 12,5% 0%
# 0 1 2 2 2 1 0
Table 16 Distribution of weight in criteria Migrate existing software platform into an app

The mean value among developers where 3,7, the mean value among decision
makers 3,3 and the mean value among those defined as both developers and
decision makers was 5,5.

Deliver the application to targeted/needed operating system(s)

Deliver the application to targeted/needed operating system(s) had a mean value
of 5,8, the min value was 3 and the max value 7. The standard deviation was 1,4
and the coefficient of variation was 24,2%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 12,5% 0% 25% 25% 37,5%
# 0 0 1 0 2 2 3
Table 17 Distribution of weight in criteria Deliver the application to targeted/needed
operating system(s)

63
The mean value among developers where 6,0, the mean value among decision
makers 5,3 and the mean value among those defined as both developers and
decision makers was 6,0.

Provide technical support

Provide technical support had a mean value of 4,5, the min value was 3 and the max
value 5. The standard deviation was 0,8 and the coefficient of variation was 16,8%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 12,5% 25% 62,5% 0% 0%
# 0 0 1 2 5 0 0
Table 18 Distribution of weight in criteria Provide technical support

The mean value among developers where 4,3, the mean value among decision
makers 4,3 and the mean value among those defined as both developers and
decision makers was 5,0.

Offer new features in the application delivered by OS manufacturer

Offer new features in the application delivered by OS manufacturer had a mean
value of 4,8, the min value was 3 and the max value 6. The standard deviation was
1,0 and the coefficient of variation was 21,8%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 12,5% 25% 37,5% 25% 0%
# 0 0 1 2 3 2 0
Table 19 Distribution of weight in criteria Offer new features in the application delivered
by OS manufacturer

The mean value among developers where 5,3, the mean value among decision
makers 4,7 and the mean value among those defined as both developers and
decision makers was 4,0.

Handle the risk of OS manufacturer will drop support for development tools used in selected
approach
Handle the risk of OS manufacturer will drop support for development tools used
in selected approach had a mean value of 3,8, the min value was 2 and the max
value 6. The standard deviation was 1,4 and the coefficient of variation was 37,0%.

64
 Weight 1 2 3 4 5 6 7
Percentage 0% 25% 12,5% 37,5% 12,5% 12,5% 0%
# 0 2 1 3 1 1 0
Table 20 Distribution of weight in criteria Handle the risk of OS manufacturer will drop
support for development tools used in selected approach

The mean value among developers where 2,7, the mean value among decision
makers 4,3 and the mean value among those defined as both developers and
decision makers was 4,5.

Test fragmented platforms supported by the app

Test fragmented platforms supported by the application had a mean value of 4,0,
the min value was 2 and the max value 6. The standard deviation was 1,2 and the
coefficient of variation was 29,9%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 12,5% 50% 12,5% 12,5% 0%
# 0 1 1 4 1 1 0
Table 21 Distribution of weight in criteria Test fragmented platforms supported by the app

The mean value among developers where 4,7, the mean value among decision
makers 3,7 and the mean value among those defined as both developers and
decision makers was 3,5.

Support testing tools used by the company

Support testing tools used by the company had a mean value of 3,4, the min value
was 2 and the max value 5. The standard deviation was 1,3 and the coefficient of
variation was 38,6%.

Weight 1 2 3 4 5 6 7
Percentage 0% 37,5% 12,5% 25% 25% 0% 0%
# 0 3 1 2 2 0 0
Table 22 Distribution of weight in criteria Support testing tools used by the company

The mean value among developers where 4,0, the mean value among decision
makers 3,0 and the mean value among those defined as both developers and
decision makers was 3,0.

65
Support advanced GUI features needed in the application such as 3D rendering components and
AR/VR components
Support advanced GUI features in the application such as 3D rendering components
and AR/VR components had a mean value of 4,0, the min value was 2 and the max
value 6. The standard deviation was 1,5 and the coefficient of variation was 37,8%.

Weight 1 2 3 4 5 6 7
Percentage 0% 12,5% 37,5% 12,5% 12,5% 25% 0%
# 0 1 3 1 1 2 0
Table 23 Distribution of weight in criteria Support advanced GUI features in the application
such as 3D rendering components and AR/VR components

The mean value among developers where 4,0, the mean value among decision
makers 4,7 and the mean value among those defined as both developers and
decision makers was 3,0.

Support continuous delivery in automate building, testing and deployment

Support continuous delivery in automate building, testing and deployment had a
mean value of 5,8, the min value was 4 and the max value 7. The standard deviation
was 0,9 and the coefficient of variation was 15,4%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 0% 12,5% 12,5% 62,5% 12,5%
# 0 0 0 1 1 5 1
Table 24 Distribution of weight in criteria Support continuous delivery in automate
building, testing and deployment

The mean value among developers where 5,3, the mean value among decision
makers 6,0 and the mean value among those defined as both developers and
decision makers was 6,0.

Provide continuous application store integration

Provide continuous application store integration had a mean value of 5,1, the min
value was 3 and the max value 7. The standard deviation was 1,5 and the coefficient
of variation was 28,4%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 12,5% 25% 25% 12,5% 25%
# 0 0 1 2 2 1 2
Table 25 Distribution of weight in criteria Provide continuous application store integration

66
The mean value among developers where 4,3, the mean value among decision
makers 4,7 and the mean among those defined as both developers and decision
makers value was 7,0.

Handle customizations in the core code changes level without affecting pace of development
Handle customizations in the core code changes level without affecting pace of
development had a mean value of 4,9, the min value was 3 and the max value 6.
The standard deviation was 1,0 and the coefficient of variation was 20,3%.

Weight 1 2 3 4 5 6 7
Percentage 0% 0% 12,5% 12.5% 50% 25% 0%
# 0 0 1 1 4 2 0
Table 26 Distribution of weight in criteria Handle customizations in the core code changes
level without affecting pace of development

The mean value among developers where 4,3, the mean value among decision
makers 4,7 and the mean value among those defined as both developers and
decision makers was 6,0.

Are there any key criteria that is missed in the survey that is of big importance when choosing
native or cross-platform mobile application development approach?
Two responders wanted to add the following criteria to the list:

 Continuous Integration e.g. CodePush

 Offline support
 Support of third-party libraries

“CodePush is an Application Center cloud service that enables Apache Cordova and
React Native developers to deploy mobile application updates directly to their
users’ devices” (Microsoft CodePush, 2019). Since CodePush is directly associated
with two cross-platform techniques, React Native and Cordova (Adobe PhoneGap),
it is not an option for the native approach. This makes this not applicable as a
criterion when selecting between native and cross-platform approach.

By storing data in the database an application will have support for offline use.
Xamarin is using SQLite as database to store data (Xamarin.Forms Local Databases,
2019). SQLite is also available using React Native (React Native SQLite, 2015), native
Android development also supports SQLite (Android SQLite, 2019) and native iOS
development support SQLite (Apple Developer Persistent Store Types, 2018). By
storing data in a database, the application has offline support and thereby not a
criterion when selecting between native and cross-platform approach.

67
Support for third-party libraries could be a criterion. However, it is dependent on
which third-party libraries is needed for the application and on what platform and
approach they are available. This is therefore not a criterion possible to use as a
selection between native or cross-platform in general terms.

Support internationalization and adding multiple languages

Support internationalization and adding multiple languages was added as an outlier
where 0 indicates that this criterion should not be among the key criteria. This
criterion had a mean value of 4,5, the min value was 0 and the max value 7. The
standard deviation was 2,8 and the coefficient of variation was 62,9%.

Weight 0 1 2 3 4 5 6 7
Percentage 12,5% 12,5% 0% 12,5% 0% 12,5% 12,5% 37,5%
# 1 1 0 1 0 1 1 3
Table 27 Distribution of weight in outlier Support internationalization and adding multiple
languages

The mean value among developers where 4,3, the mean value among decision
makers 4,3 and the mean value among those defined as both developers and
decision makers was 5,0.

Support theming and different user privileges

Support theming and different user privileges was added as an outlier where 0
indicates that this criterion should not be among the key criteria. This criterion had
a mean value of 3,4, the min value was 0 and the max value 7. The standard
deviation was 3,0 and the coefficient of variation was 88,1%.

Weight 0 1 2 3 4 5 6 7
Percentage 25% 12,5% 12,5% 0% 0% 25% 0% 25%
# 2 1 1 0 0 2 0 2
Table 28 Distribution of weight in outlier Support theming and different user privileges

The mean value among developers where 4,0, the mean value among decision
makers 2,7 and the mean value among those defined as both developers and
decision makers was 3,5.

3.3 Discussion
The result from the survey shows that there is a big discrepancy in the entire sample
on how the criteria are weighted. 14 of 22 criteria had a coefficient of variation
above 25%.

68
Discussion from entire sample

As visualized in Figure 4, there is a big spread between the max and min value. The
mean value among the entire sample is closer to the max value than the min value.

Entire Sample - Max, Min and Mean

7

1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 4 Min, max and mean value for the 22 criteria for the Entire sample

The 6th Deliver needed access to device specific hardware or device API and 7th
Needed application performance criterions differs the most compared to the rest in
that sense that they have the biggest and smallest deviation from max and min
values.

Discussion from Position perspective

The survey included three positions: 1) Developer, 2) Decision maker and 3) Both.
Since years of experience does not give a mutual view, we investigate if there is a
more homogeny among the sample within job position.

Developer
Among the sample of developers (3 respondents) there was 7 criteria with a
coefficient of variation above 25%. The sum of the rounded mean weight for each
criterion among developers is 100.

69
 Developer
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 5 Min, max and mean value for the 22 criteria in the sample of Developers

By looking at Figure 5 one can conclude that the respondents with the position as
developers had a more homogeny view on the weight distribution. The criteria 8,
Perform customization with core code changes of the application requiring a heavy
technical expertise, 9, Handle high number of customizations done frequently of the
application which also impact the maintenance of the app, and 10, Meet pricing
model, are the ones that differs the most.

Decision maker
Among the sample of decision makers (3 respondents) there was 12 criteria with a
coefficient of variation above 25%. The sum of the rounded mean weight for each
criterion among decision makers is 101.

Decision Maker
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 6 Min, max and mean value for the 22 criteria in the sample of Decision makers

Figure 6 shows that there is a big spread in weight distribution among decision
makers. The 6th criteria, Deliver needed access to device specific hardware or device
API, have the biggest spread with a min value of 1 and a max value of 6.

70
Both
Among the sample of both developers and decision makers (2 responders) there
was 8 criteria with a coefficient of variation above 25%. The sum of the rounded
mean weight for each criterion among both positions is 104.

Both
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 7 Min, max and mean value for the 22 criteria in the sample categorized as Both
developers and decision makers

It is an even weight distribution among the sample with a position of both and
developer and decision maker, as can be seen in Figure 7. There are six criteria
where both respondents gave the same weigh allocation 4) Deploy competence
available in market, 6) Deliver needed access to device specific hardware or device
API, 9) Handle high number of customizations done frequently, 14) Provide technical
support, 21) Provide continuous application store integration and 22) Handle
customizations in the core code changes level without affecting the pace of
development.

Developer and Both

Among the sample of developers (3 responders) and both developer and decision
maker (2 responders) there was 13 criteria with a coefficient of variation above
25%. The sum of the rounded mean weight for each criterion among developers is
101.

The graph in Figure 8 shows the min, max and mean value for the 22 criteria in the
sample of developers and both developer and decision maker.

71
 Developer and Both
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 8 Min, max and mean value for the 22 criteria in the sample of Developers including
the sample that answered Both developers and decision makers

Decision maker and Both

Among the sample of decision makers (3 responders) and both developer and
decision maker (2 responders) there was 15 criteria with a coefficient of variation
above 25%. The sum of the rounded mean weight for each criterion among
developers is 101.

Decision Maker and Both

7

1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 9 Min, max and mean value for the 22 criteria in the sample of Decision makers
including the sample that answered Both developers and decision makers

Figure 9 shows that there is a big spread in weight distribution among decision
makers. The 6th criteria, Deliver needed access to device specific hardware or device
API, have the biggest spread with a min value of 1 and a max value of 6 and shows
the same distribution as the ones that had a position as only decision makers.

Discussion from Years of experience perspective

In the sample with respondents having an experience of 15 years and above, 10 of

22 criteria have a coefficient of variation above 25%.

72
 15 Years of Experience
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 10 Min, max and mean value for the 22 criteria in the sample of 15 Years or more of
experience

In the sample with respondents having an experience of 10 years and above, 16 of

22 criteria have a coefficient of variation above 25%.

10 Years of Experience
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MAX MIN MEAN

Figure 11 Min, max and mean value for the 22 criteria in the sample of 10 Years or more of
experience

This shows that even people with many years of experience weight each criterion
different, and there is not a mutual view of the weight each criterion should have.
As can be seen in Figure 10 and Figure 11 the ones with more experience had a
more homogeneous weight distribution.

As seen in Figure 12 the line shows that respondents with less experience weight
the criteria “Be agile in HR management” less than “Be agile in budget”. The
respondents with 15 years of experience or more weighted both Be agile in HR
management and Be agile in budget high with a value between 5-7 as illustrated in
the ellipsis. Can this be a phenomenon of generation where a less experienced

73
professional think it might be easier to find competence compared to a more
experienced professional?

Figure 12 Years of Experience vs Be Agile in HR and Be Agile in Budget which both are from
the Business Environment perspective

Discussion from Years of experience and Position perspective

To analyse the result even further we investigate to see how the data looks among
years of experience for each position.

Developer
Among the sample of developers, the years of experience was 3, 6 and 10 years.

Developers based on Years of Experience

7

1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

3 Years of Experience 6 years of experience

10 Years of Experience

Figure 13 Weight of each criterion from the sample of Developer based on years of
experience

74
Looking at Figure 13 it looks like the developers with 3 and 10 years of experience
have a more equal weight distribution among the 22 criteria. The developer with 6
years of experience has slightly different weight distribution.

Decision Maker
Among the sample of decision makers, the years of experience was 10, 20 and 21
years.

Decision Makers based on Years of

Experience
7

1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

10 Years of Experience 20 Years of Experience

21 Years of Experience

Figure 14 Weight of each criterion from the sample of Decision Makers based on years of
experience

Looking at Figure 14 there is hard to make any conclusions or find any patterns
among decision makers based on years of experience.

Both
Among the sample defined as both developers and decision makers, the years of
experience was 5 and 15 years.

Both based on Years of Experience

7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

5 Years of Experience 3 15 Years of Experience 3

Figure 15 Weight of each criterion from the sample of Both based on years of experience

In Figure 15 there is only two respondents and they show a similar weight
distribution even if one has five years of experience and the other has 15 years of

75
experience. This could be explained if they work in the same company and have
similar view. Unfortunately, the company is not a part of the survey and therefore
such a conclusion cannot be made.

When analysing position and years of experience with the criteria Provide support
for system integration, Deliver needed access to device specific hardware or device
API and Needed application performance demonstrated in Figure 16 there is a
correlation between years of experience and weight. Needed application
performance was given the weight 5 from a developer with three years of
experience which since then increased to 6 and 7 by developers with 6 and 10 years
of experience, illustrated by the first line. The same criteria were given a high weight
among the decision makers in the sample illustrated by the black arrows in Figure
2. Provide support for system integration, however, decreased with the years of
experience (illustrated by the second line) among the ones in the sample with the
position as decision maker. The same applies on Deliver needed access to device
specific hardware or device API among decision makers. Those with the position as
both developers and decision makers weighted Deliver needed access to device
specific hardware or device API at 7, which is the highest score, even though there
was a big spread in the years of experience (5 and 15 years).

Figure 16 Years of Experience vs Position vs Provide support for required system integration,
Deliver needed access to device specific hardware or device API and Deliver needed access
to device specific hardware or device API

76
Discussion of Outliers

There are two outliers in the survey, Support internationalization and adding
multiple languages and Support theming and different user privileges. The outliers
received a very diverse weight among the sample and therefore did not fulfil the
intended purpose of detecting human errors and remove faulty data. The
coefficient of variation for Support internationalization and adding multiple
languages was 62,9% and the coefficient of variation for Support theming and
different user privileges was 88,1%. Both outliers had a big spread among the
respondents where both got 0 and 7 as weight. There could be many reasons for
this, and one could be that the outliers where weakly described making room for
interpretation beyond the intended scope.

By comparing years of experience and position with the outliers, as illustrated in

Figure 17, there are some conclusions to make. One developer with 10 years of
experience and one decision maker with 20 years of experience weighted both
outliers at 7, the highest score. Also, one decision maker with 21 years of
experience weighted both outliers with a score of 1 indicating very little importance
when taking the decision native vs cross-platform. One decision maker with 10
years of experience weighted Support internationalization at 5 but Support theming
a weight of 0 indicating it should not be a part of the criteria at all. It could be
explained that one could interpret more into the description of support
internationalization than the actual impact of being part of a decision in native vs
cross-platform.

Figure 17 Years of Experience vs Position vs Outliers.

77
The outliers had a very big coefficient of variation with 62,9% and 88,1%, and in
that sense prove that these two criteria should not be among the 22 key criteria for
selecting native vs cross-platform application development.

Discussion summary

By only reviewing all data from the position or years of experience does not give a
clear picture of the data set. As a decision maker you can have different background
leading into that position, but a developer most likely have a technical view on the
criteria. That could be one of the reasons the group of developers have a more
consistency among the weight distribution compared to decision makers.

If we look at the sixth criterion, Deliver needed access to device specific hardware
or device API, the developer and both developer and decision maker had a mean
value of 6,2 but the position of only being a decision maker had a mean value of
3,7. This is a technical aspect and not all decision makers might know that native
development approach provides access to all device API but not always in a cross-
platform approach, and therefore should have a high weight distribution in the list
of the criteria.

A more business-oriented criteria is the second one, “Be agile in budget” (cost of
developing for several platforms, switch platform if needed), where the decision
maker had a mean value of 6,3 and developer had a mean value of 4,7. This could
be explained by the less technological aspects of the criterion and therefore
developers weight that less than decision makers do.

4. Conclusion
Decide on mobile development approach is not an easy decision to make. There are
many variables to take into consideration and there is also a matter of technological
philosophy. This thesis is contributing by providing a framework for making that
decision based from a theoretical and objective perspective rather than subjective
opinions. Yet, also bring contribution from practice as the field where developer
and managers make their decisions constantly to enhance their business, build up
new strategies and gain competitive advantage.

Based on the outcome of the survey, one can conclude that allocated weight for
the criteria is not consistent among the sample. They who had the position of
developer and both developer and decision maker had the most homogeny weight
distribution in the sample. Not even by analysing the data from only years of
experience gives a homogeny weight distribution. This divergence is a proof that
the framework presented in this thesis is of great value for decision makers and
that there is a need of such a tool. If all respondents had the same weight on all

78
criteria there would be less need of making the decision into a theoretical and
objective process. Since this is not the case, there is a proof of the importance of
such a framework for selecting native or cross-platform application development.

The respondents of the survey did not ask any questions or gave feedback. This
could be interpreted as the criteria was well expressed without any
misunderstandings and can be considered a strength. Another strength is the
distribution among position and years of experience among the respondents. The
respondent with least experience had 3 years of experience and the one with most
had 21 years of experience. The distribution among position was almost evenly
distributed where 37.5% was developers, 37.5% decision makers and 25% both
developers and decision makers.

Both developers and decision makers are stakeholder when it comes to allocating
weight since weight allocation must have input from both technological as well as
business-oriented aspects. By using the mean value from the entire sample, we get
a weight distribution evenly distributed among decision makers and developers.

The rounded mean, the rounded median and mode (most frequent weight) for each
criterion in the entire sample is illustrated in Figure 18. As can be seen the rounded
mean value does not differ much from the rounded median or the mode value and
therefore a weight that can be used for each criterion.

Entire Sample - Rounded Mean, Rounded

Median and Mode
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

ROUNDED MEAN ROINDED MEDIAN MODE

Figure 18 Rounded mean, rounded median and mode for each criterion in the entire sample

By using the mean value from each criterion in the survey from the entire sample,
and round it to closest integer, we receive a total of 100 with a weight distribution
as can be seen in Table 29.

79
 1-7 Fulfilment (0-5)
5 = We definitely can fulfil
requirements to:
0 = we definitely cannot
fulfil requirements to:
Criterion Weight Native Cross-
% approach platform
approach
Business environment perspective
Company profile
BE1 Be agile in HR management (all 4
aspects related to employees) to
maintain selected approach.
BE2 Be agile in budget (cost of developing 5
for several platforms, cost of hiring
developers to reach desired speed of
development, cost to switch platform
if needed)
Competence
BE3 Deploy competence already available 5
in the company
BE4 Deploy competence available in 4
market recruiting developers
B2B or B2C
BE5 Provide support for required system 4
integration (back-end and cloud)
needed in the app
BE6 Deliver needed access to device 5
specific hardware or device API
BE7 Needed application performance 6
When in time
BE8 Perform customization with core code 4
changes of the application requiring a
heavy technical expertise
BE9 Handle high number of customizations 4
done frequently of the application
which also impact the maintenance of
the app

Infrastructure perspective
License
I1 Meet pricing model 4
I2 Handle restrictions of needed 4
modifications in the framework
Target platforms
I3 Migrate existing software platform 4
into new mobile app

80
 1-7 Fulfilment (0-5)
5 = We definitely can fulfil
requirements to:
0 = we definitely cannot
fulfil requirements to:
Criterion Weight Native Cross-
% approach platform
approach
I4 Deliver the application to 6
targeted/needed operating system(s)
Long-term feasibility
I5 Provide technical support 5
I6 Offer new features in the application 5
delivered by OS manufacturer
I7 Handle the risk of OS manufacturer 4
will drop support for development
tools used in selected approach

Development perspective
Development environment and
testing
D1 Test fragmented platforms supported 4
by the application
D2 Support testing tools used by the 3
company
User interface design.
D3 Support advanced GUI features 4
needed in the application such as 3D
rendering components and AR/VR
components
Continuous delivery
D4 Support continuous integration, 6
automate building, testing and
deployment
D5 Provide continuous application store 5
integration
Pace of development
D6 Handle customizations in the core 5
code changes level without affecting
pace of development
Sum 100
Weighted score
Table 29 List of criteria selecting native vs cross-platform approach with weight as rounded
mean value from the empirical study using entire sample

81
4.1 Limitations

The survey did not include company name or company size. With this information
there would be possible to draw conclusions based on respondents from the same
company or if they worked in a big or small company. There is probably more likely
that respondents from a smaller company would weight Be agile in HR
management and Be agile in budget higher than respondents from a larger
company, based on that financial resources are different in these companies.

Since the survey had a big variation of weight distribution among the respondents,
a larger sample would be beneficial.

4.2 Further research

Suggested further research is to conduct a survey with a larger sample. Since the
weight distribution among the respondents seem to be dependent on the position
and not as many years of experience, a larger sample would be beneficial. A
suggestion for the data collection would be having company name and company
size as parameters in in order to make conclusions based on that.

There would also be of interest to make a research to develop a framework deciding

on native vs a couple of specific cross-platform frameworks. Since each cross-
platform framework has its pros and cons this thesis needs to treat them as one
even though some of them differ a lot. By selecting a couple cross-platform
frameworks there could be a more detailed criteria based on the characteristics of
chosen cross-platform tools.

82
5. References
1. Adobe PhoneGap (n.d.) https://phonegap.com/products/ [2020-03-26 11:25]
2. Android Developer Fundamentals (2019)
https://developer.android.com/guide/components/fundamentals [2020-04-19
18:59]
3. Android Developer Platform (2019)
https://developer.android.com/guide/platform [2020-03-09 20:45]
4. Android Source (2019) https://source.android.com/setup [2020-04-19 22:46]
5. Android SQLite (2019) Save data using SQLite
https://developer.android.com/training/data-storage/sqlite [2020-05-13 22:13]
6. Angione, C. (2011) http://sgmlxml.net/sgmlxmlblogs/?p=199 Towards a Better
Understanding of Software Customization [2020-04-08 10:30]
7. Apple Developer (2020) https://developer.apple.com/documentation/xcode
[2020-03-09 21:15]
8. Apple Developer Persistent Store Types (2018), Persistent Store Types and
Behaviours
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/
CoreData/PersistentStoreFeatures.html [2020-05-13 22:17]
9. Apple Developer Purchase (2020)
https://developer.apple.com/support/purchase-activation/ [2020-03-23 20:56]
10. Apple Developer Swift (2020) https://developer.apple.com/swift/ [2020-04-19
13:02]
11. Apple Developer XCode (2020 https://developer.apple.com/xcode/ide/ [2020-04-
19 12:49]
12. Biørn-Hansen, A., Grønli, T-M., Ghinea, G., Alouneh, S. (2019) An Empirical Study
of Cross-Platform Mobile Development in Industry. Hindawi, Wireless
Communications and Mobile Computing, Volume 2019, Article ID 5743892
13. Blair, I. (n.d.) Application Development Costs: $1,000 Application vs. $10,000
Application vs $100,000 Application (What’s The Difference?)
https://buildfire.com/app-development-costs-difference/ [2020-02-28 11:25]
14. Burch, V., Strawderman, L., Carruth, D. (2016) Ruggedized handheld device input
effectiveness by generation: A time and error study International Journal of
Industrial Ergonomics 54 (2016) 146-153
15. Businesswire (2018-01-05) Global Rugged Devices Market 2018-2022 with
Datalogic, Honeywell International, Zebra Technologies & Panasonic Dominating -
Research and Markets
https://www.businesswire.com/news/home/20180105005486/en/Global-
Rugged-Devices-Market-2018-2022-Datalogic-Honeywell [2020-03-23 14:48]
16. Campbell, E. (n.d.) Native vs. Cross-Platform Mobile Application Development
https://www.apterainc.com/blog/native-vs-cross-platform-mobile-app-
development/ [2020-03-09 18:40]
17. Clement, J. (2019) Mobile application usage – Statistics & Facts
https://www.statista.com/topics/1002/mobile-app-usage/ [2020-02-24]

83
18. Clement, J. (2020) Number of applications available in leading application stores
as of 1 quarter 2020 https://www.statista.com/statistics/276623/number-of-
applications -available-in-leading-app-stores/ [2020-05-12 22:40]
19. Cortimiglia, M.N., Ghezzi, A., Renga, F. (2011) Mobile Applications and Their
Delivery Platforms. 1520-9202/11/ © 2011 IEEE
20. Dalmasso, I., Datta, S., Bonnet, C., Nikaein, N. (2013) Survey, Comparison and
Evaluation of Cross Platform Mobile Application Development Tools. Mobile
Communication Department, EURECOM
21. Dev Tecnhosys (2020) Top Cross Platform Application Development Frameworks
in 2020 https://www.mobileappdaily.com/top-cross-platform-app-development-
frameworks [2020-03-09 21:30]
22. Fitzgerald, M. (2019) Create Beautiful Native Applications in Record Time with
Google Flutter https://hackernoon.com/flutter-create-beautiful-native-
applications -in-record-time-nv1e93whh [2020-05-11 23:32]
23. Flutter FAQ (n.d.) https://flutter.dev/docs/resources/faq [2020-03-26 15:10]
24. Francese, R., Gravino, C., Risi, M., Scaniello, G., Tortora, G. (2017) Mobile
Application Development and Management: Results from a Qualitative
Investigation 2017 IEEE/ACM 4th International Conference on Mobile Software
Engineering and Systems (MOBILESoft)
25. Ganguly, S. (2018) Top Pros & Cons Comparison: React Native vs Kotlin
https://hackernoon.com/top-pros-cons-comparison-react-native-vs-kotlin-
2a0dfd1df3e3 [2020-05-11 23:11]
26. Haberl, N. (2015) Cross Platform Development Possibilities and drawbacks of the
Xamarin platform. FH Joanneum, University of Applied Sciences
27. Heitkötter, H., Hanschke, S., Majchrzak, T.A. (2013) Evaluating Cross-Platform
Development Approaches for Mobile Applications
28. Hodge, V.J., Austin, J. (2004) A Survey of Outlier Detection Methodologies. Article
in Artificial Intelligence Review, October 2004.
29. Holst, A. (2019) Global smartphone shipments forecast from 2010 to 2022
https://www.statista.com/statistics/263441/global-smartphone-shipments-
forecast/ [2020-02-05 14:12]
30. Honeywell (n.d.) Developer Library
https://www.honeywellaidc.com/products/software/developer-library [2020-03-
23 14:20]
31. Lamhaddab, K., Lachgar, M., Elbaamrani, K. (2019) Porting Mobile Applications
from iOS to Android: A Practical Experience. Hindawi. Mobile Information Systems
Volume 2019, Article ID 4324871
32. Leedy, P.D., Ormrod, J.E. (2015) Practical Research – Planning and Design (11th
edition) Pearson Education Limited
33. Leuschenko, O. (2018) The Pros and Cons of Xamarin for Cross-Platform
Development https://hackernoon.com/the-pros-and-cons-of-xamarin-for-cross-
platform-development-2a31c6610792 [2020-05-11 22:34]

84
34. Liu, S. (2019) Cross-platform mobile frameworks used by software developers
worldwide as of 2019 https://www.statista.com/statistics/869224/worldwide-
software-developer-working-hours/ [2020-05-26 21:18]
35. Long, S. (2017) What is the Difference Between B2B and B2C Mobile Applications
? https://seventablets.com/blog/what-is-the-difference-between-b2b-and-b2c-
mobile-applications / [2020-02-24 10:04]
36. Novac, O.C., Nocac, M., Gordan, C., Berczes, T. (2017) Comparative Study of
Google Android, Apple iOS and Microsoft Windows Phone Mobile Operating
Systems. 2017 14th International Conference on Engineering of Modern Electric
Systems (EMES)
37. Majchrzak, T.A., Wolf, S., Abbassi, P., (2015) Comparing the Capabilities of Mobile
Platforms for Business Application Development, Springer International
Publishing Switzerland 2015 S. Wrycza (Ed.): SIGSAND/PLAIS 2015, LNBIP 232, pp.
70–88, 2015.
38. Manchada, A (2019) Where Do Cross-Platform Application Framework Stand in
2020? https://www.netsolutions.com/insights/cross-platform-app-frameworks-
in-2019/ [2020-02-24]
39. Microsoft CodePush (2019) CodePush https://docs.microsoft.com/en-
us/appcenter/distribution/codepush/ [2020-05-13 21:49]
40. Monus, A (2019) https://raygun.com/blog/native-app-development/ [2020-02-06
13:01]
41. Palmieri, M., Singh, I., Cicchetti, A. (2012) comparison of Cross-Platform Mobile
Tools, 2012 16th International Conference on Intelligence in Next Generation
Networks
42. Pratap. M., (2018) How much does it cost to make a Mobile app?
https://hackernoon.com/how-much-does-it-cost-to-make-an-mobile-app-
7343dbd99f68 [2020-05-12 23:03]
43. React Native (n.d.) https://reactnative.dev/ [2020-03-25 22:24]
44. React Native SQLite (2015) SQLITE bindings for React Native
http://www.reactnative.com/sqlite3-bindings-for-react-native/ [2020-05-13
22:10]
45. Rieger, C., Majchrzak, T.A. (2016) Weighted Evaluation Framework for Cross-
Platform Application Development Approaches. In: Wrycza S. (eds) Information
Systems: Development, Research, Applications, Education. SIGSAND/PLAIS 2016.
Lecture Notes in Business Information Processing, vol 264. Springer, Cham.
46. Rieger, C., Majchrzak, T.A. (2019) Towards the definitive evaluation framework
for cross-platform application development approaches. The journal of Systems
and Software 153 p 175-199
47. Shah, K., Sinha, H. (2019) Analysis of Cross-Platform Mobile Application
Development Tools. 2019 5th International Conference for Convergence in
Technology (I2CT)
48. Smart Sight Innovations (n.d.) https://www.smartsight.in/technology/how-b2b-
mobile-applications -different-from-b2c-applications / [2020-04-13 14:30]

85
49. Statcounter (2020) Mobile Operating System Market Share Worldwide Aug 2012
– Jan 2020 https://gs.statcounter.com/os-market-
share/mobile/worldwide/#monthly-201208-202001 [2020-02-06 10:32]
50. What is Xamarin (n.d.) https://dotnet.microsoft.com/learn/xamarin/what-is-
xamarin [2020-03-25 14:21]
51. Xamarin.Forms (n.d.) https://dotnet.microsoft.com/applications
/xamarin/xamarin-forms [2020-03-25 14:55]
52. Xamarin.Forms Local Databases (2019) Xamarin.Forms Local Databases
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/data-
cloud/data/databases [2020-05-13 22:03]
53. Zebra (n.d.) Zebra Developer Portal
https://developer.zebra.com/community/tools [2020-03-23 14:13]

86
 6. Annexes
Annex 1 Comparison native and cross-platform approach (Dalmasso et al. 2013, p 1)

Decision criterion Native approach Cross-platform

approach
Quality of UX Excellent Not as good as native
applications
Quality of applications High Medium to low
Potential users Limited to a particular Large – as it reaches to
mobile platform users of different
platforms
Application development High Medium to low
cost
Security of app Excellent Not good
Supportability Complex Medium to complex
Ease of updating Complex Medium to complex
Time-to-market High Short
Application extension Yes Yes

87
Annex 2 Infrastructure perspective - Criteria for selecting native or cross-platform approach (Heitkötter et al. 2013, p 6, p 15)

Criteria Native Cross-Platform

License and cost Android is open source where iOS is only available with Is the framework distributed as free software or open
Apple’s own hardware with an end user software source? Are the developers free to develop
agreement. A membership in Apple developer program commercial software?
is necessary.
Supported platforms Is done separately for each platform because The number of mobile platforms that are supported
programming language and API differ. and the importance of them.
Access to platform- Direct access to all features Access to device hardware like GPS, camera and
specific features notifications.
Long-term feasibility Studies show that both Oss [Android and iOS] will For small companies, this criterion can be of
remain popular. Developers can rely on large importance due to the initial investment. Indicators are
communities, regular bug-fixes and updates. short update cycles, regular bug-fixes, support of
newest versions of mobile operating systems etc.
Look and feel Full support of platform specific UI elements. Does the framework support native look and feel?
Everything that can be done in cross-platform can be Most users seek applications that look like native
done natively. applications.
Application speed Native prototypes are not slower than cross-platform. Compare application speed at start-up and runtime
Equal to cross-platform tool PhoneGap from the subjective user experience.
Distribution Within platform-specific application stores How easy is it to distribute update and applications
with the respective framework?

88
Annex 3 Development perspective - Criteria for selecting native or cross-platform approach (Heitkötter et al. 2013, p 7, p 16)

Criteria Native Cross-Platform

Development Android applications with Java-enabled IDE such Evaluates how well the development environment is
environment Eclipse with corresponding plugins. iOS developers functioning and the features associated with the
require Max OS and XCode framework (IDE, debugger, emulator).
GUI Design Both Android and iOS support WYSIWYG editor. The process of creating graphical user interface (GUI)
and its software support like editor or emulator.
Ease of development Documentation on each OS is comprehensive and Quality of documentation and code examples. Also
both is providing numerous examples. Programmers includes the learning-curve and how much
need additional knowledge on the underlying OS. framework-specific knowledge a developer needs to
acquire.
Maintainability Very detailed object-oriented implementation in The LOC evaluate the maintainability with the
Java (Android) and Objective C (iOS) makes the assumption that an application is easier to support
implementation comprehensive and easy to when it has less lines of code.
maintain.
Scalability Program logic and GUI can easily be separated from How well can larger developer teams and projects be
each other in both Android and iOS. Each view of an handled using the framework? Modularization of
application can be independent developed, and the application and framework is also important to
object-oriented approach enables development reduce the number of concurrent developers.
teams to scale.
Opportunities for further Code written native cannot in general not be ported The reusability of source code and assesses the risk
development to another platform due to programming language of lock-in if a project could be transferred to another
and APIs. approach.
Speed and cost of Native development requires specific knowledge and Speed of the development process and factors that
development experience. An application needs to be repeatedly could hinder a fast development. Cost are related to
developed for each platform which leads to cost of the speed of development and the salary for the
development native is higher. competence needed for a developer in each
framework.

89
Annex 4 Infrastructure perspective – criteria for selecting cross-platform framework (Rieger et al. 2016 p 8-10)

License The license under which framework is published is essential for the type of product to develop. It needs
to be assessed if a developer is free to create commercial applications and the pricing model also needs
to be considered
Supported target platforms The major concern for selecting cross-platform framework is the number and importance of supported
mobile platforms. Support also includes which versions of the mobile OS each framework is supporting
and in what extent.
Supported development Flexibility in development platforms is beneficial for heterogenous teams where developers are working
platforms with specific hardware or software such as development environment. The role within a team such as UI
or UX design may require support for multiple platforms.
Distribution channels Number of users that can be reached, publication process and compatibility with application store
restrictions are some key aspects when considering distribution channels.
Monetisation The complexity of selling the application itself and the following in-application purchases as well as the
availability of advertisement need to be considered.
Global Application A global distribution of applications is most often desired. Approaches can offer built-in support for
Distribution distribution and localisation and translation capabilities allows for easy delivery of multi-language
content.
Long-term feasibility Choosing an approach might be a crucial strategic decision considering the initial investment for hiring
and training developers as well as the risk of technological lock-in, especially for smaller companies. The
maturity and stability of the framework can be evaluated by the historical and expected backwards
incompatible changes of major releases. Short update cycles, regular bug-fixes and security updates are
other indicators.

90
Annex 5 Development perspective – criteria for selecting cross-platform framework (Rieger et al. 2016 p 10-12)

Development environment The maturity and features of an IDE has a big impact of the development productivity and speed. Tools
support includes functionalities such as auto-completion, debugging tools and emulator. The freedom of
choosing a preferred IDE lowers the initial setup effort for additional dependencies such as runtime
environment of SDK.
Preparation time The learning curve and best practices of the approach should promote rapid initial progress. The number
of types of required technology stack and programming languages needs to be considered in order to
lower the entry barrier.
Scalability Modularisation capabilities of the framework with the ability to partitioning code in subcomponents and
architectural design decisions such as MVC pattern has implications to the application structure. With
specified interfaces and interactions between components, developers can specialize themselves on few
relevant components.
Development process fit The amount of boilerplate code, initial configuration and the effort to subsequently modify its scope are
aspects regarding to evaluate the framework. This criterion also includes the organizational aspects of
scalability in terms of developer specialization.
UI Design Approach UI is a major concern for cross-platform approaches. Graphical user interfaces are highly platform
specific and often covered by a default appearance defined by the framework. WYSIWYG editors for
creating appealing interfaces for multiple devices can be beneficial and increases the speed of
development.
Testing Support Application logic and user interfaces needs to be tested with established concepts such as system and
unit tests. To test context-sensitive mobile scenarios external influences may be simulated. Providing a
developer console, meaningful error reporting, logging functionalities and debugging on a connected
device are possibilities to evaluate.
Deployment Support Generating individual packages for all targeted platforms simplifies the deployment process. Approaches
vary from requiring all native SDKs to external build services and cloud-based techniques. Sophisticated
projects use continuous integration platforms to automate testing and frameworks can explicitly be
designed to integrate with such toolchains.

91
Maintainability The evolution of the code base over time. Maintainability is hard to measure and quantify but lines of
code and reusability of source code across development projects are two ways of measuring it.
Extensibility The possibility to extend the framework with functionality based on custom components and third-party
libraries should be evaluated. This for example be additional UI elements and functionalities to access
device features.
Integrating Native Code Running native code in a cross-platform approach seemingly invalidates the idea of a cross-platform
development. This can, however, be necessary when applications are migrating from another platform.
Also, native platform API might enable features not available in the cross-platform level of abstraction.
Speed of development Amount of boilerplate code necessary for functional application skeletons and the availability of typical
application functions such as user authentication has an impact of the speed of development.

92
Annex 6 Application perspective – criteria for selecting cross-platform framework (Rieger et al. 2016 p 12-14)

Access to Device-specific It is of big importance in cross-platform approaches to access platform- and device-specific hardware. This includes
Hardware sensors such as camera, microphone, GPS, accelerometer, gyroscope, magnetometer, temperature sensor and heart
rate monitor.
Access to Platform-specific Functionalities include a persistent layer accessing the file system and a database on the device, contact lists,
Functionality information on network connection and battery status.
Support for Connected Wearable devices are often coupled to a respective master (e.g. a smartphone) and this trend of “device extensions”
Devices must be evaluated regarding viable device combinations.
Input Device Heterogeneity This evaluates the support regarding the variety of input devices than can interact with an app. This includes
keyboards, mouse, touch screens, voice recognitions, remote controls, hardware buttons and more. This also include
multi-touch screens reacting to gestures such as taps, swipes, pinches etc.
Output Device Mobile devices provide different output devices differing in device size, resolution, format, colour palette, frame rate
Heterogeneity and opacity.
Application Life Cycle How far a framework supports the life-cycle inherent to an application where platforms may differ in starting,
pausing, continuing and exiting an app.
Business integration Applications may communicate with existing Web service back-end for data storage and processing or initiate inter-
application communication.
Security Frameworks support developing secure applications in several levels such as access permissions, data encryption
mechanisms and secure data transfer protocols and input validation preventing cross-site forgery and code injection.
Fallback Handling Intelligent fallback mechanism in case individual features are unsupported or restricted can include graceful
degradation techniques or redirected to a Web page.

Annex 7 Usage perspective – criteria for selecting cross-platform framework (Rieger et al. 2016 p 14)

Look and feel This evaluates if the UI elements of the framework have a native look and feel or behave like a Web page. Rich user
interfaces with 2D/3D animations and multimedia features are challenging for cross-platform tools. It should be
considered in what extent the framework supports the platform-specific usage philosophy.

93
Performance The speed, responsiveness of user actions and stability are essential performance aspects. The user experience is
subjective but speed at start-up, after shutdown and after interruptions can be measured. Also, CPU, RAM and
battery usage at runtime can be assessed.
Usage patterns Users want an “instant on” experience and continue where the left of when then left the app. Applications must
integrate into personal workflows to match usage patterns.
User Management Frameworks have different support of user handling reaching from local applications to user accounts over several
devices and role-based authentication. Authentication may therefore be done in-application or server based and
potentially connected to session management.

94
Annex 8 Infrastructure perspective – criteria for selecting cross-platform framework (Rieger et al. 2019 p 180-182)

License For commercial development, a framework’s license is important. Does the framework have any restrictions to the
usage of developed applications? Does the licensing model allow modifications of the framework? The pricing
model is also of importance and evaluated in this criterion.
Supported target platforms The reason for using a cross-platform framework is for being able to reach several platforms but only develop once.
This criterion is therefore very important. Two versions of a platform might be different enough to consider
developing for them to be the same as developing for two distinct platforms.
Supported development Software as Microsoft Windows and Apple MacOS and how well the development environment works are evaluated
platforms here. A good development platform support is beneficial for integration with additional application development
tasks for example user interface and user experience.
Distribution channels Most users acquire their applications in large repositories like Google Play or Apple Application Store, but a broader
support for cross-loading from relevant stores is desirable. Cross-platform frameworks can differ from the
compatibility of application store restrictions.
Monetisation How well does the framework support the means of monetisation? Following categories of applications with specific
business purpose is defined; Paid (one time fee), Freemium (pay to get access to advanced features, in-application
purchases), Paidmium (combines paid downloads and in-application purchases), In-application advertising (banners
and sponsored content) and Free (to increase customer satisfaction).
Internationalisation Applications are often distributed globally, and internationalisation and localisation can offer added value and
broaden the base of potential users.
Long-term feasibility The choice of application development approach can be a strategic decision and a commitment for many years. The
chosen framework must be evaluated from the perspective of the company developing the framework as well as a
possible technological lock-in.

95
Annex 9 Development perspective – criteria for selecting cross-platform framework (Rieger et al. 2019 p 182-183)

Development environment Evaluation of integrated development environment (IDE) and its features like auto-completion, integration of library
documentation, built-in debuggers and emulator support to help developers.
Preparation time The time it takes for a developer to get acquainted with the framework is depending on the required technology
stack and number of supported programming languages of the framework.
Scalability In large-scale or distributed development projects, there is a need to have a scalable application and therefor
appropriate modularisation is needed.
Development process fit A framework should be compatible with the needed development process used by the development team, for
example agile or waterfall methodology.
User interface design Most applications are user-centred which makes the user interface (UI) design an essential part of the app. Graphical
user interfaces (GUI) are in most cases specific to the platform and often only covered by the default appearance
defined by the framework.
Testing Besides from regular unit tests the context-sensitivity of mobile devices must be fulfilled. Mobile scenarios, such as
phone calls when using the application and varying connectivity, must be taken into consideration when testing.
Remote debugging the device is preferable compared to using an emulator.
Continuous delivery An app’s lifecycle include deployment. When using an agile method using platforms to automate building, testing
and deployment of an application can be used. Frameworks can be designed to integrate with such toolchains by
offering project-specific scripts, advanced build options and continuous application store integration for publishing
updated versions.
Configuration management Support for different user privileges, theming and regional peculiarities can be supported by the framework by
different application packages.
Maintainability Code base evolves during an app’s lifecycle. Line of code, readability of code, use of design patterns, in-code
documentation can be used to quantify maintainability. Reusability of source code across development project can
also be evaluated.
Extensibility The framework extensibility covers the flexibility of adding third-party libraries and custom components instead of
developing themselves.
Integrating custom code Some applications require native code or custom libraries to be run. This can be seen as a paradox to the cross-
platform approach but can be necessary in some cases. Platform-specific APIs can enable platform functionalities

96
 and device features. Companies might want to integrate native code when migrating applications that where
developed natively to a cross-platform approach.
Pace of development The influencing factors like for example the amount of boilerplate code necessary for functional application
skeletons. The overall development speed has a direct impact of the costs and ultimately the return-on-investment.

97
Annex 10 Application perspective – criteria for selecting cross-platform framework (Rieger et al. 2019 p 183-185)

Access to device-specific A lot of device hardware is available today such as camera, microphone, GPS, accelerometer, gyroscope and
hardware temperature scale. Frameworks with poor support for device specific hardware is a risk where feature-poor
applications are developed.
Access to platform-specific To avoid the risk of feature-poor applications there might be a need to access to platform-specific features such as
functionality the filesystem, database, contact list, information on the network connection and battery status.
Support for connected The ability to support connected devices like wearables and communication through gadgets has been more
devices important recently. How well these connected devices are supported by the framework must be evaluated.
Input device heterogeneity A smartphone screen can be manipulated using multi-touch gestures such as taps, swipes, pinches and pressure. The
smartphone also reacts to orientation changes and hardware buttons. Cross-platform frameworks must make these
possibilities available for developers.
Output device heterogeneity Screen-size, resolution, format, colour-palette, frame rate and opacity differ between model and devices.
Application life cycle The application life cycle includes of starting, pausing, continuing and exiting an app. Multithreading, continuously
running background services and notifications extends the state in which an application is executed. The life cycle of
an application should be inherited by the framework.
System integration Many applications are using a back-end system for feeding the application with data. Frameworks support different
options for data exchange protocols, serialisation and multiple data formats.
Security A framework can support the development of secure applications with several security attributes such as
confidentiality, integrity and control.
Robustness Applications should include intelligent fallback mechanisms in case specific features are unsupported or restricted by
for example using graceful degradation techniques. An application should also be fault-tolerant
Degree of mobility Four categories of mobility can be distinguished and supported by the framework. Stationary, Mobile, Wearable and
Autonomous.

98
Annex 11 Usage perspective – criteria for selecting cross-platform framework (Rieger et al. 2019 p 185-186)

Look and feel The user interface should have a native look and feel rather than look like a web site. If generated applications use a
truly native interface, it should be created in the way typical for the platform. Applications should support the
platform-specific usage philosophy like the position of navigation bars, scrolling and gestures.
Performance Poorly performed applications would likely have low user acceptance. With performance means application load
time, speed for changing views and computations resulting from user interactions. Performance also includes CPU-
load, battery drain during runtime and download size.
Usage patterns Users wants an “instant on” experience and continue where they left the app. This means that unsaved data should
be available after closing the app, data retrieved from the internet should be stored locally. Applications should also
integrate with common applications such as messaging, email and social media.
User authentication Frameworks should offer several ways for user authentication such as pins, passwords, gestures and biometric
information.

99
Annex 12 Criteria with weight percentage (Rieger et al. 2019, p 188)

Criterion Weight %
Infrastructure
I1 License 5
I2 Supported target platforms 6
I3 Supported development platforms 2
I4 Distribution channels 2
I5 Monetisation 1
I6 Internationalisation 1
I7 Long-term feasibility 5

Development
D1 Development environment 7
D2 Preparation time 7
D3 Scalability 2
D4 Development process fit 2
D5 User interface design 4
D6 Testing 3
D7 Continuous delivery 3
D8 Configuration management 1
D9 Maintainability 2
D10 Extensibility 2
D11 Integrating custom code 2
D12 Pace of development 4

App
A1 Access to device-specific hardware 4
A2 Access to platform-specific functionality 5
A3 Support for connected devices 3
A4 Input device heterogeneity 1
A5 Output device heterogeneity 1
A6 Application life cycle 2
A7 System integration 3
A8 Security 3
A9 Robustness 2
A10 Degree of mobility 1

Usage
U1 Look and feel 5
U2 Performance 4
U3 Usage patterns 2
U4 User authentication 3

100