Semester: 4 Title: a Model for Supporting the Discussion Around

Home , Scribe (log server), Talks at Google

Semester: 4 Aalborg University Copenhagen A.C. Meyers Vænge 15 2450 København SV Title: A model for supporting the discussion around the Semester Coordinator: Henning choice of mobile technology in Olesen

mobile application development Secretary: Maiken Keller Project Period: 1 February – 6 June

Semester Theme: Master Thesis Project Abstract:

The research identified a knowledge gap related to Supervisor(s): mobile Application Frameworks. Specifically, what is Professor Anders Hansen Henten important to know for a business organization when deciding how to build an application for their mobile

Project group no.: 4BUS 4.7 service.

In order to answer the research question, the thesis Members explored the mobile ecosystem, found the most (do not write CPR.nr.): influential members in the mobile development Dragos Nicolae Sassu process. Once it set up this context, the work Focuses

on describing Application Frameworks from a technical perspective. The result of this analysis is a

descriptive model of the application Frameworks

and their surrounding ecosystem. In order to identify

relevant implications for the business organization, the research focuses on users and their acceptance

and continuance behaviours.

Starting from these two descriptive blocks, the research identifies 6 relevant possible problems that should be discussed in the context of this technology choice. Lastly, the work proposes 5 mobile service-

related characteristics that may change after a choice is made.

Lastly, the work puts together all these blocks. The result is a model that can facilitate the discussion around a the mobile technology choice in question.

Pages: 104

Finished: 6/6/2019

When uploading this document to Digital Exam each group member confirms that all have participated equally in the project work and that they collectively are responsible for the content of the project report. Furthermore each group member is liable for that there is no plagiarism in the report.

AALBORG UNIVERVERSITY

MASTER THESIS

A model for supporting the discussion around the choice of mobile technology in mobile application development

Author: Dragos SASSU i

AALBORG UNIVERVERSITY Abstract

Faculty Name Department or School Name

MSc engineer Innovative Communication Technologies and Entrepreneurship

A model for supporting the discussion around the choice of mobile technology in mobile application development

by Dragos SASSU

The research identified a knowledge gap related to mobile Application Frameworks. Specifically, what is important to know for a business organization when deciding how to build an application for their mobile service. In order to answer the research question, the thesis explored the mobile ecosystem, found the most influential members in the mobile development process. Once it set up this context, the work Focuses on describing Application Frameworks from a technical perspective. The result of this analysis is a descriptive model of the application Frameworks and their surrounding ecosystem. In order to identify relevant implications for the business organization, the research focuses on users and their acceptance and continuance behaviours. Starting from these two descriptive blocks, the research identifies 6 relevant possible problems that should be discussed in the context of this technology choice. Lastly, the work proposes 5 mobile service-related characteristics that may change after a choice is made. Lastly, the work puts together all these blocks. The result is a model that can facilitate the discussion around a the mobile technology choice in question. ii

Contents

Abstract i

1 Introduction 1 1.1 Problem formulation...... 2 1.2 Scope deﬁnition...... 3

2 Methodology 5 2.1 Research design...... 5 2.1.1 Research process...... 6 2.1.2 Research Model...... 6 Stage I: Exploratory interviews...... 6 Stage II: Thorough literature review...... 6 Stage III: Defining the Technology Domain (T.D.)...... 7 Stage IV: Defining the Application Domain (A.D.)...... 7 Stage V: Identifying and analyzing the problem space (relationships) between T.D. and A.D...... 7 Stage VI: Define the Business Domain (B.D.) and analyze its opportunities and limitations in the context of mobile technologies...... 7 Stage VII: Showcase of the complete model...... 8 2.1.3 Research Artifacts...... 8 2.2 Literature review...... 8 2.2.1 Sources...... 9 2.2.2 Search process...... 9 2.2.3 Structuring knowledge...... 9 2.3 Interview process...... 10 2.3.1 Exploratory interviews...... 10 2.3.2 In-depth interviews...... 10 2.4 Conference - Google I/o...... 10 2.5 Handling personal experience and experimentation...... 10 2.6 Analysis frameworks...... 11 2.6.1 The ecosystem analogy...... 11 Business ecosystem...... 11 Technology ecosystem...... 12 Digital Ecosystem...... 13 Ecosystem control and interdependence...... 14 2.6.2 Technology adoption theory...... 15 Pre-adoption theories...... 16 Post-adoption theories...... 17 iii

3 The mobile landscape 19 3.1 The evolution of Mobile landscape...... 19 3.1.1 The Brick Era (1973 – 1988)...... 19 3.1.2 The Candy Bar Era (1988 – 1998)...... 20 3.1.3 The Feature Phone Era (1998 - 2007)...... 20 3.1.4 (First) Smartphone Era (2002 - 2007)...... 21 3.1.5 The Touch Era - (Second) Smartphone Era (2007 - Present)...... 22 3.1.6 The smart device era...... 24 3.2 Evolution of mobile services...... 24 3.3 State of the art in the Mobile ecosystem...... 26 3.3.1 Operators...... 27 3.3.2 Networks...... 28 3.3.3 Devices...... 28 3.3.4 Mobile platforms and Operating Systems (O.S.)...... 32 Android Platform...... 33 iOS Platform...... 38 3.3.5 Application framework...... 39 3.3.6 Applications...... 39 3.3.7 Services...... 41 3.4 Ecosystem considerations for applications developers...... 42 3.4.1 Consequences of platform differentiation...... 43 3.4.2 Fragmentation...... 43

4 Technology Domain - An analysis of Application Frameworks 45 4.1 An overview of mobile application frameworks...... 45 4.1.1 Related research...... 45 4.1.2 Framework classification...... 46 4.1.3 Native Application Frameworks...... 46 4.1.4 Mobile Web Application Frameworks...... 47 A classical approach to Web Applications...... 47 A modern approach to Web Applications...... 48 4.1.5 Cross-platform Application Frameworks...... 49 Hybrid...... 50 Interpreted...... 51 Cross-compiled...... 52 Other approaches...... 53 4.2 Analysis framework development...... 54 4.2.1 Scope definition...... 54 4.2.2 Stage 1 - Adapting Adomavicius et. al model of technology roles...... 54 4.2.3 Stage 2 - Component identification and classification...... 55 4.2.4 Stage 3 - Component characteristics definition...... 55 4.3 Analysis of Technology Domain components...... 57 4.3.1 Analysis sources...... 58 4.3.2 Native - Android...... 59 4.3.3 Native - iOS...... 60 4.3.4 Web - Angular...... 61 4.3.5 Cross-platform - Cordova...... 61 4.3.6 Cross-platform - React Native...... 62 4.3.7 Cross-platform - Flutter...... 63 iv

4.4 Conclusion...... 64

5 Application Domain Definition 65 5.1 Exploratory expert interviews...... 66 5.1.1 Findings summary...... 66 5.1.2 Initial considerations...... 69 5.1.3 Related research...... 70 5.1.4 Domain key concepts...... 72 5.1.5 Domain analysis expectations and requirements...... 72 5.2 Application Domain analysis framework development...... 72 5.2.1 UTAUT adaptation...... 73 5.3 Application Domain analysis...... 76 5.3.1 Who are the App and the User?...... 77 5.3.2 Mobile application finding...... 77 5.3.3 Perception based information...... 78 Performance Expectancy (Perceived usefulness)...... 78 Effort Expectancy (Perceived Ease-of-Use)...... 78 Perceived Enjoyment...... 79 5.3.4 Social Influence...... 79 5.3.5 Facilitating Conditions...... 80 5.3.6 Behavioral Intention of Use...... 80 5.3.7 Actual Use Behavior...... 81 5.3.8 User Experience (U.X.)...... 82 5.3.9 Confirmation...... 83 5.3.10 Satisfaction...... 83 5.3.11 Mobile Application Continuation Intention...... 83 5.4 Conclusion...... 84

6 Mobile Applications - Deﬁning the problem space 85 6.1 Technology related problem space...... 85 6.1.1 Framework ecosystem structure and maturity...... 85 6.1.2 Available features...... 88 6.1.3 The cost for achieving performance...... 89 6.1.4 Fragmentation...... 91 6.1.5 Application code base evolution...... 92 6.2 Application related problem space...... 93 6.2.1 User Experience...... 93 6.3 Service related problem space...... 93 6.3.1 Time-to-market...... 93 6.3.2 Customer service access...... 94 6.3.3 Application distribution method...... 94 Web Application distribution...... 94 Platform application distribution...... 94 Mobile store presence: a beneﬁt or a liability?...... 96 Conclusion...... 97 6.3.4 Service costs implications...... 97 6.3.5 Customer experience and customer satisfaction...... 97 6.4 Conclusion...... 98 v

7 Model Presentation 99

8 Work limitations and further improvements 101 8.1 Work limitations...... 101 8.2 Further improvements...... 101

9 Conclusion 103

A Interview - Kristian Friis 105

B Interview - Nicolas Linde 108

C Interview - Philip Bruce 113

D Interview - Christian Risom 118

E Interviews conducted at Google I/O 2019 120 E.1 I/O - Interview 1...... 120 E.2 I/O - Interview 2...... 121 E.3 Google I/O - Interview 3...... 122 E.4 Google I/O - Interview 4...... 122

F Summary of relevant presentations part of Google I/O 2019 124 F.1 Conference Session 1: “Beyond Mobile: Material Design, Adaptable UIs and Flutter”. 124 F.2 Conference Session 2: “Building Successful Websites: Case Studies for Mature and Emerging Markets“...... 124 F.3 Conference Session 3: “Building for iOS with Flutter”...... 124 F.4 Conference Session 4: “App Growth Best Practices and Decision-Making with the Google Play Console”...... 124 F.5 Conference Session 5: “Unlocking new capabilities for the Web”...... 125 F.6 Conference Session 6: “Build Fast and Smooth Web Apps from Feature Phone to Desk- top”...... 125 F.7 Conference Session 7: “Build Apps for the Next Billion Users”...... 125

G Android Software Stack 126

Bibliography 128 1

Chapter 1

Introduction

Almost ten years ago, smartphone sales overtook those of personal computers for the ﬁrst time in history. [81]. Ever since, the turn towards mobile grew steadily and today, the statistics paint the picture of a world in which, on average, teens and adults alike spend around three hours of every day looking at their mobile phone 1. Young generations are mobile native, using their phone as an integral part of their daily life, while those between the ages of 13 to 17 are operating their smart devices considerably more than their older counterparts [11].

FIGURE 1.1: Major trends in the world of mobile application (Source: AppAnnie)

Meanwhile, the mobile industry went from bloom to boom. Ranging from connectivity technologies to never before seen devices and software applications, the ecosystem has been developing at an incredibly fast pace. This enabled newcomers like device manufacturers such as Huawei and platform providers like Apple and Google to take advantage of the innovations, securing the major shares of the value capturing process. By employing different ecosystem strategies, Apple and Google managed to slowly eliminate the competition from the global mobile OS market, together serving over 98% of the business 2. The development of the capabilities of the devices, the adoption of the smartphone and the openness of the new platforms towards the developers set the foundations of a strong and rich application market [24]. And where people and attractive technologies meet, money begins to rain, and when it rains, it pours: it is expected that this year over $120 billion will be be spent on App store related purchases[36], 20 times more than the value of the entire mobile market 10 years ago3. However, applications didn’t become just a source of consumer based revenue, but also a source of revenue for the B2B industry. According to Google, mobile drives or impacts more than 40% (average) of the revenue of leading B2B companies. 4

1https://www.statista.com/statistics/320974/internet-usage-on-mobile-phones-gb-age/ 2http://gs.statcounter.com/os-market-share/mobile/worldwide 3https://communities-dominate.blogs.com/brands/2010/01/gartner-measures-all-apps-of-apps-stores-worth-42b- dollars-in-2009.html 4https://www.thinkwithgoogle.com/data/mobile-b2b-revenue-statistics/ Chapter 1. Introduction 2

Considering the widespread adoption of the smartphone, the constant increase of the time people spend online on their mobile devices [36] and the revenue generation potential, it is expected to see a net increase of the number of companies that pay a closer attention to their mobile channels. How- ever, when the decision making process around technology choice can be difficult. On the one hand, the informal discussion around organization technology adoption tends to be rather superficial, since not all companies are willing or can afford employing a mobile technology expert. Therefore, oftentimes the process slides towards a sales decision rather than towards an informed one. On the other hand, the technology options spectrum is rather large and diverse. New (e.g. PWA, Flutter, React Native) and old technologies (e.g. Titanium, Cordova) are framed as THE solution for any business problem. In these circumstances, the research identifies the necessity of supporting the decision making process of technology adoption. More specifically, the choice concerns picking a suitable technology for the mobile service channel they intent to build. Previous researchers outlined that the general research direction on this subject is not aligned to the industry interests[24]. Therefore, this work aims to take advantage of the researcher’s experience as a mobile developer and the existing body of knowledge regarding mobile technology in order to filter the relevant information. The final goal of this work is to put together all the meaningful findings, add the missing pieces related to the latest technologies and create a framework that supports the discussion on the topic of mobile technology.

1.1 Problem formulation

1. What are the main technology options available for developing a mobile application? The answer to this question should allow a better understanding of the available technology choices. 2. What are the main problem areas to be discussed by a business that considers the usage of one of these technologies in order to build an application that serves it’s mobile service? • What impact can this choice of technology have over the mobile service? The answer to this research question should be a model that can facilitate the discussion about what will the option mean for the respective business. The model should contain two types of components: • Descriptive components - In order to have a productive discussion about the technology choice implications, one should first make sure that the framing of the discussion is understood. The descriptive components will paint this context. One of the components will revolve around the findings deduced from the first research questions. Another component should depict the possible implications of the said choice over the mobile service. Lastly, the research will use other supportive descriptive components in order to bridge the knowledge between the first two. • Problem components - Once the reader understands the context of the discussion, the model should also present the main problems generated by the technology choice.

This formulation of the problem also involves a set of constraints on the present work: • The number of descriptive components will be limited to three, in order to ensure a readable model. • The problems presented will be bound by the choice of theoretical framework and by the primary and secondary data source. Chapter 1. Introduction 3

• Even though Mobile technology is a term which includes many other technology classes, in order to focus the discussion, this work will only use it to refer to technology used for the development of mobile applications.

1.2 Scope deﬁnition

In order to set up the right expectations, the research has to further define what this research will and will not be about. First of all, the research will not cover the mobile games field. Previous experience and research have shown that the technologies, selection criteria and business models are too diverse to allow such an association in the context of this work. However, the work will address applications with a hedonistic component. Even though the research will focus on exploration and identification processes, it does not aim to be exhaustive. The topic of mobile technology is a rather complex one and such a model could not encompass the whole structure. Therefore, the work will take advantage of the existing body of knowledge in order to identify a subset of all the mobile related challenges. Furthermore, the research does not aim to provide a comparative analysis between the problems. It is considered that various businesses will have different available resources and evaluation criteria for the issues outlined by the model. It must be emphasized that this is not a decision making framework. Instead, it aims to help the development of attitudes and opinions in such a context. Secondly, this work will mostly refer to devices to be Smartphones. The category of mobile devices is rather large and extremely diverse, so a limitation was required. On the other hand, the research will address the concept of mobile applications in the broader sense of the term. As it will be discussed in Section 3.3.5, the mobile application term refers both to (1) Web Applications (served over Web) and to (2) Platform Applications, that need to be installed and run on the Device OS. This choice was motivated by two factors: (1) the high number of innovations in Web Technology (Pro- gressive Web Applications) and (2) access simplicity. Last but not least, it was considered that Mobile Web is a popular choice to access mobile services. Thirdly, Chapter 3.3.7 will explain the following interpretation of a mobile service:

A service that exposes digital touch points, and that customers can access through a smartphone is called a mobile service.

This interpretation will allow a transition from a technology related discussion towards a business oriented one. In Consequence, the model will assume and focus on the dynamic between: Consumer(Application user) - Channel(Application) - Service Provider (Business) . This will further narrow context in which the mobile service is perceived. The supported service is for external organizational use and is meant to support or directly deliver the company’s value proposition. Lastly, the work is meant to assist a company interested in the adoption of mobile technology, while not assuming whether such a solution will be developed in-house or externally. The remainder of the research is organized as follows:

• Chapter2 will describe the methodological approach describing how the research was conducted.

• Chapter3 will describe the ecosystem around mobile applications, what are its members, roles and relations. In this chapter a considerable focus is put on historical ecosystem evolution, in order to understand the dynamic nature of the system and the Device and Platform members. These will serve as fundamental knowledge for understanding further relations and impacts. Chapter 1. Introduction 4

• Chapter4 will present the ﬁrst descriptive component of the model, the Technology Domain. The outcome of this chapter is the Technology Domain block and its characteristics.

• Chapter5 will present the second descriptive component of the model, the Application Do- main. The outcome of this chapter is the Application Domain block and its characteristics.

• Chapter6 will describe the main technology driven issues of the mobile application development. This ﬁnal outcome of this chapter will be a set of problems worth reviewing in the technology choice scenario.

• Chapter9 will conclude the work, resuming the ﬁndings. 5

Chapter 2

Methodology

This chapter introduces the research methodology used to resolve the problem presented in Section 1.1. Firstly, the research describes the design paradigm and an outline of the research process. This sections will present the activities and outputs involved in each stage of the model. Secondly, the chapter provides an in depth description of the literature review approach. Next, it presents the interview approaches used for data collection. Furthermore, the chapter describes the author’s prior personal experience with the topic and what other activities he conducted to achieve a better understanding of the domain.

2.1 Research design

According to [60], understanding Information Systems requires a theory that combines the “natural world, social world and the artificial world of human constructions”. Two common research approaches are design science and the behavioral science. Design Science (D.S.) focuses on problem- solving, seeking to create ideas, practices, capabilities and products, generally called artifacts, that contribute to the analysis, design, implementation, management and use of Information Systems ([64]). On the other hand, the Behavioral-Science (B.S.) paradigm focuses on interactions. It aims to explain or predict organizational and human phenomena when engaging with the analysis, design, implementation, management and use of Information Systems ([64]). In his comparison of the two approaches, Göran Goldkuhl outlines that Design Science aims to provide utility through innovative artifacts, while Behavioral Science’s goal is to find the truth in an existing reality. This truth is often obtained by testing one or more causality hypotheses and based on the data collected they may be accepted or rejected. On the other hand, design science usually consists of a design idea which through design work turns in an artifact. This is why, D.S. is characterized as "prescriptive" and B.S. as "descriptive" ([58]). When considering the definition of the relationship structure, the work will have a Design science oriented approach. [64], define a set of 7 guidelines, which serve as requirements for effective D.S. research. The very first step is that it needs to produce a viable artifact in the form of a construct, model, method or instantiation. This is exactly the expected outcome of the paper, a model representing the relationships between technology related components and business components. Therefore, this approach will guide the design of the research process. When describing artifacts, Havner et. all exclude people or organizational elements from their definition. When building the relationship model, the work will not focus on how decision makers actually behave when they make technology adoption decisions. The utility of the model stays in its capacity to actually support technology adoption analysis. Chapter 2. Methodology 6

Last but not least, the work chooses to use a qualitative research approach. This implies multiple data collection steps and an iterative process of reﬁning knowledge. Primary data is collected through interviews, while secondary data is the result of literature review and existing case studies.

2.1.1 Research process The research proposes an eight step process to develop the model. Figure 2.1 describes step by step each stage, required knowledge, corresponding activities and resulting outputs.

FIGURE 2.1: Research process

2.1.2 Research Model Stage I: Exploratory interviews The process starts with an exploration step. In this stage, it is expected to identify which are the main industry concerns and discussion topics related to the research subject. Prior to the interviews, the researcher has brieﬂy reviewed popular opinions in media regarding the value propositions of different mobile technologies. In addition to that, the researcher had been working for 3 years as an Android developer. This provided the necessary familiarity with mobile application development. Two interviews were conducted, in an interval of one week. These initial interviewees were an en- trepreneur, Christian Risom (Founder/CEO at Shape A/S) and a sales representative, Kristian Friis (Head of Business Developer at Shape A/S). Shape is a product studio based in Europe and specialized in building high-quality mobile products. Their activity covers all stages of a mobile application life-cycle: consulting business in assessing their digital needs, building requirements, designing software, implementing applications, supporting running operations and conducting a continuous evaluation of digital services. As the research aims to uncover relations between two different domains (technology and business), the people taking part in these interviews had to have an integrated perspective of the worlds. There- fore, the input of a Technical Consultancy CEO and from the head of digital services sales serves as strong starting point for the this research. The result of these discussions is an initial description and classiﬁcation of the problem space, presented in Figure 2.1.

Stage II: Thorough literature review Starting from the relevant concepts identified during the interviews and the issues outlined by the C. Risom and K. Friis, the research continued with a through review of the existing scientific sources. This step involved reading, evaluating and organizing information from over 200 papers, books, reports or technology related websites. Throughout the review process, the research aimed to (a) extend the existing problem space by identifying new issues, possible choices and conflicting views over the topic, (b) identify the general characteristics of the mobile technology used for developing mobile applications, (c) identify a set of criteria for defining and analyzing mobile applications characteristics, (d) review theoretical approaches of organizing the business domain be organized. The Chapter 2. Methodology 7

ﬁnal outcome of this stage is a Concept Map describing the knowledge structure and the supporting relations.

Stage III: Deﬁning the Technology Domain (T.D.) The web of concept dependencies resulted from literature review and interviews is used as input for deﬁning a conceptual technology domain. However, it is not only enough to summarize the existing technology assessments. Research that aims to describe and compare mobile technologies from an engineering point of view is rather extensive and diverse. Moreover, due to a fast paced technological evolution, research in this area tends to quickly become obsolete. Therefore, at this stage, there is a need to identify which are the relevant characteristics and competencies of this domain that should stay relevant for further analysis.

Stage IV: Defining the Application Domain (A.D.) Similar to Stage III, Stage IV aims to develop the second component of the final relationship model: the Application Domain. In the literature review step, the research identified a set of criteria for defining and analyzing the characteristics of mobile applications. This stage chooses an analysis paradigm which will serve as a guideline for defining the domain. Furthermore, A.D. definition should also consider the Technology Domain and what has been identified during literature review to be influenced by the characteristics of the Technology Domain. In order to keep the model aligned with industry needs and considerations, during this step the researcher conducts another set of interviews. Experts in designing and managing mobile applications are interviewed to ensure a proper domain definition.

Stage V: Identifying and analyzing the problem space (relationships) between T.D. and A.D. Up to this point, the research described both mobile applications and technologies used in their development. Next, Stage V focuses on the relations between the two areas of interest. Starting from literature review and the components present in the Technology Domain, the report presents a comparative analysis of technology choices. The analysis will focus on identifying the implications of these choices over the Application Domain and its characteristics. The expected outcome of this step is a deﬁnition of the relational space between the T.D. and A.D. This relational space is fundamentally a set of decision-making issues which can stem problems in the Application Domain.

Stage VI: Define the Business Domain (B.D.) and analyze its opportunities and limitations in the context of mobile technologies Now, that the process has covered the definition of T.D and A.D. and their relationships, the first research question has been tackled. Next, in order to understand how mobile technology influences the business components of a company, Stage VI has to adopt an analysis framework that classifies business components. Using this approach, considerable research work is put in identifying and analyzing the components that are actually affected by this choice. These components form the Busi- ness Domain. The last analytic step in this stage is to understand and describe the relational space between B.D. and T.D. and A.D. In that sense, the last component of the model needs to provide the set of decision-making issues which can stem problems in the Business Domain. Chapter 2. Methodology 8

Stage VII: Showcase of the complete model Steps II - VI have been developing different sections of the model. Stage VII of the research process consists in putting together all sections and discussing the resulting model.

2.1.3 Research Artifacts The output of the research process is a model describing how choices in the Technology Domain can inﬂuence characteristics and competences in the Business Domain. This model is the ﬁnal artifact of the design process. However, this construction is build by putting together multiple smaller research artifacts. As was presented in Section 2.1.1, these artifacts are developed at different stages of the research process. Figure 2.2 describes the sequence in which the artifacts are designed throughout the design work.

FIGURE 2.2: Model components

2.2 Literature review

The research process described in section 2.1.1 involved two cases for literature review: (1) while preparing for the exploratory interviews and (2) the thorough literature review in Stage II. A brief literature review was conducted before the exploratory interviews. The main objective of this step was to make the researcher aware of the main discussion topics that surround the choice of mobile technology. For that matter, media sources like www.medium.com and www.mobiforge.com were consulted together with a few other academic papers. These online communities of mobile technology adopters would offer a good insight in the current trends of the industry. However in the second use case of literature review (Stage II of the research process) weights considerably more for the report Chapter 2. Methodology 9 outcome quality. The data collected would serve as basis for understanding and identifying the main characteristics and competences of each domain and for the problem space. Therefore, in order to ensure a relevant and qualitative secondary data sources, the information search has to be extensive and rigorous. Moreover, the proposed research questions require a broader and sometimes interdis- ciplinary approach, the information obtained can become unmanageable very fast. In consequence, the literature review process needs to adopt tools and best practices for knowledge management. The following sections further describe data sources, the search process of information and lastly, how knowledge is structured across different research stages.

2.2.1 Sources Three types of sources were used for secondary data: (1) AAU Digital Library, (2) Google Scholar and (3) online community discussions (blogs, forums or media articles). AAU Libraray provide access, among others to research portals like ProQuest, ACM or IEEE Xplore. These served as the main source for collecting academic papers. Google scholar on the other hand, was used mainly for accessing speciﬁc book chapters which are not generally available in digital libraries. Thirdly, community discussions allowed to cross check how practitioners perceive the subjects analyzed by the research community. Even though the analysis found in mass media is rather shallow and sometimes bias, it offers a good reference point of how industry tends to tackle the topic in question.

2.2.2 Search process The search for information focused heavily on search portals (Primo in AAU Library) and Google (Scholar) Search). In the initial literature review, the focus was on understanding what are mobile applications, what technologies are used to build them and what is the impact they have on businesses. In that sense, keywords like "mobile application technology", "mobile application development" and "mobile application value proposition", "trends mobile applications" were used. At the second stage of the literature review, the search became more focused on ﬁlling knowledge gaps. To begin with, the research has focused on understating the impact of mobile applications for organizations (e.g. keywords: "mobile technology in organization", "mobile business model", "mobile application business performance". Next, as the focus has shifted on understanding the ecosystem around mobile technology (e.g. keywords: "mobile ecosystem", "mobile enablers", "mobile application markets") and the core technologies used in mobile applications (e.g. keywords: "mobile technology", "mobile web native hybrid"). At this stage, search based on key words would become inefﬁcient due to the many possible queries and results. Therefore, the process focused on looking at already reviewed papers and selecting further papers from their bibliography. This way, the process took advantage of the effort put in previous research. Moreover, the bibliographic searched focused on survey papers or on research building taxonomies. Throughout the research process, 250 papers were shortlisted for an abstract review, out of which 140 were thoroughly reviewed.

2.2.3 Structuring knowledge Indexing, organizing and storing this amount of information can pose a great challenge for the research. Therefore, the research adopted a two level strategy for structuring the knowledge: (1) information structuring and (2) source structuring. Firstly, a concept map was used Fto manage the information acquired through reading. Through the use of CMap Tools software, new relevant concepts and analysis concerns would be added to a map together with their sources and brief comments. In parallel, sources would be classified based on the topic they cover (e.g. comparing technologies, Chapter 2. Methodology 10 explaining business implication of technology use, defining the mobile ecosystem). Using a folder organizational structure, generated at the end the literature review a set of 12 research areas. Throughout the research process, a live document containing existing relevant questions was maintained. Based on the conceptual, literature review and the analysis of previous interviews, new questions would be continuously identified. This question log would serve as input for deciding the subjects tackled during the interviews.

2.3 Interview process

The Section 2.1.1 outlined three different use cases for interviews: exploring the research domain and obtaining in depth knowledge regarding speciﬁc areas of interest. All interviews were hold in person, recorded, summarized post conversation, and the questions asked were open ended.

2.3.1 Exploratory interviews This data collection technique is used in the ﬁrst stage of the research process. As it was previously mentioned, two experienced members from the industry were interviewed: Christian Risom and Kristian Friis. The ﬁrst discussion, with C. Risom, took an unstructured form with little involvement of the researcher. He was briefed about the topic of the report and asked what is his take on the topic. A summary of the transcript can be found in AnnexD. This discussion rose new questions and concerns. The second exploratory interview partially provided new research input and partially explored the existing suppositions. Therefore, the discussion with K. Friis was more bi-directional, following a semi-structured form. A summary of the interview can be found in AnnexA

2.3.2 In-depth interviews These type of interviews are used to properly understand and deﬁne the Application Domain. Al- though literature review offered a good starting point for domain characterization, practitioners facing these issues on a day by day basis can provide a different perspective on the issue. Philip Bruce and Nicolas Linde. were interviewed for this purpose. In both cases the topic of the research was kept hidden for the ﬁrst half of the interview. This hopefully provided unbiased opinions on the subject. The interviews followed a semi structured form and focused on their work experience. They both have over7 years of experience in consultancy companies working with various clients.

2.4 Conference - Google I/o

The researcher attended to Google I/O 2019 in order to collect more information about the Android Ecosystem, Web and Flutter Development. During the Conference, 4 more interviews were conducted with experts, employed by Google to answer to community questions. These interviews can be reviews in AnnexE. Furthermore, the researcher attended to 7 different conference sessions with subjects ranging from “Building Successful Websites: Case Studies for Mature and Emerging Mar- kets” to “Building for iOS with Flutter” (Annex F.1).

2.5 Handling personal experience and experimentation

Besides the data collection steps mentioned this chapter, the researcher also relies on its own personal experience. Three years of experience in Native Mobile Application Development allowed him to grasp the fundamental principles of native mobile technology and mobile applications in general. Chapter 2. Methodology 11

Further on, at the time of writing this report, he is taking part in a cross technology team that develops a mobile website and native mobile solutions for the same project. Therefore, this offers the opportunity to conduct informal discussions with other practitioners about the research subject. The results of these conversations will not be documented, but they will contribute to the report analysis. In addition to the external input gathered through informal and formal conversation, the research involved a short experiment during a coding competition event. During two days, a small mobile application was developed using Flutter. This allowed for diversifying technology exposure and hands on experience.

2.6 Analysis frameworks

2.6.1 The ecosystem analogy Natural ecosystems have been long used as a metaphor for complex systems that imitate their structure and behavior. Natural organisms are organized using complex hierarchies, cells within tissues, contained in organs, within organisms, grouped in populations [119]. As early as 1990, Michael Rothschild observed that [119]:

"A capitalist economy can best be comprehended as a living ecosystem. Key phenomena are also central to business life. Information is the essence of both systems."

Business ecosystem Since then, multiple parallels have been drawn to the natural ecosystems. J.M. Moore coined the Business ecosystem metaphor in 1994 [102]. He argued for a new paradigm requiring businesses to see themselves as a greater ecosystems living in a larger environment. His main argument is that analyzing an industry by looking at how actors integrate vertically and horizontally is insufﬁcient. Instead, he proposes the business ecosystem, focusing on how organizations, similar to natural organisms, co-evolve and interact within an outside host (environment). According to Moore, communities are build around goods and service delivery, which in turn satisfy customer needs. The main mechanisms through which members of the ecosystem innovate their value are competition and cooperation. Furthermore, these ecosystems consist of larger networks of organizations which often cover several industries. One important consideration for Moore is that ecosystem structure doesn’t only include the actors creating the value, but also the consumers and supporting bodies in this process (e.g. regulatory agencies, resource owners or representatives of the ecosystem host). Iansiti and Levien [69] further draw attention to how important are member connections in the ecosystem. The conclude that all members of the ecosystem, depend on each other in order to develop highly effective processes and a strong value proposition. In their analysis, they propose an ecosystem model where each member, based on their role can be deﬁned as a keystone, dominator or niche player. Based on their role, organizations can apply different strategies that will affect among others the capabilities of the organization and how resources are allocated and controlled in the ecosystem. A considerable research effort used the business ecosystem framework to explain value creation and ecosystem evolution in ICT related contexts. For example, J. West and D. Wood highlight the importance of open innovation strategies and how companies employing them rely on external cooperation in order to develop [153]. For this purpose, they examined the ecosystem supporting Symbian Operating Sys- tem. B. Iyer and T. Davenport describe the Google ecosystem, highlighting how its infrastructure and architectural control impacted its evolution [74]. Chapter 2. Methodology 12

Technology ecosystem As more and more research combining the Ecosystem framework with the Information Technology domain, Adomavicius et. al. [4] emphasize the interdependent relationships existing between multiple technologies and how they affect each other’s evolution. Consequently, they claim that the environment of I.T. services can be difficult to navigate by decision makers. Especially when these decisions concern what technology to use in new product development cycles, what are the right technology investment choices and how to conduct technology planning [5]. One of the aspects industry analyst often ignore when researching these decisions is the “organic nature of technological development” [5]. In order to help firms to better understand technology ecosystems they introduce the concept of a technology ecosystem. Adomavicius et. al. define this new ecosystem analogy flavor to be:

A system of interrelated technologies that influence each other’s evolution and development. A specific technology ecosystem view is defined around a focal technology (i.e. technology that the analyst is most interested in) in a given context (a specific application, use, or capability of the focal technology under consideration).

The interpretation is joined by an ecosystem model describing the dynamic evolution of technology (Figure 2.3). Their structure describes three possible technology roles and nine paths of inﬂuence between them. The three roles are:

• Product and application role - the chosen focal technology of the study together with other direct competitors (e.g. assuming laptops for gaming is the focal technology, this category would also contain consoles or highly performing mobile devices)

• Components role - technologies identiﬁed as necessary for performing product functions in a given context of use. (e.g. video-card for gaming laptops)

• Support and infrastructure role - technologies enhancing the value of the product, through better performance or use (e.g. cloud computing for video processing). Chapter 2. Methodology 13

FIGURE 2.3: Adomavicius et. al. technology roles and paths of inﬂuence (Image Source: [4])

Digital Ecosystem S. Henninsson and J. Hedman analyze the transformation of the digital payment ecosystem [63]. Building on top of previous research, including the work of Adomavicius et. al., they deﬁne the digital ecosystem as an extension of the business ecosystem “a co-opetitive environment in which symbiotic relationships are formed to create mutual value for its members” that “exist in a fusion relation to mobile technologies, where digital technologies form part of a technology ecosystem”. The merge between business and technology allows for technology innovation to shape the business landscape. They believe that this transformation usually occurs as a result of management decision making, decisions which usually considers both ecosystem competitive and collaborative aspects. In some cases, it is just the result of aligning innovation with the ecosystem practices. Digital ecosystems have been further researched in multiple occasions. An exceptional overview of the state of the art regarding Digital Ecosystem research is presented by L. Marjamaa-Mankinen in Technology ecosystems and digital business ecosystems for business [92]. On concept that stands out in this research is DBE (Digital Business Ecosystems). It was ﬁrst presented to the research community in the Lisbon Agenda by the European Union. It outlines the European transition from simple Business Ecosystems towards the use of Digital Business ecosystems. Similarly to the case of Henninsson and Hedman, the enabling technology is capable of changing the structure and networks of organizations, while enterprises can modify the structure of the technology. In a discussion paper published by the European Commission [49], the digital business ecosystem is portrayed as a “digital environment populated by digital species”. These digital species can be anything ranging from software components, services and applications to knowledge, laws and contracts. These species also interact, behave, evolve, adapt, can become instinct and follow the laws of the ecosystem. F. Nachira proposes a three-layered structure of the ecosystem. What is more important however, is that each layer Chapter 2. Methodology 14 should be analyzed from three perspectives: (1) the technological component, (2) business models and (2) knowledge. To conclude, three applications of the Ecosystem metaphor have been presented: (1) the technology ecosystem, (2) the business ecosystem and (3) the digital ecosystem. On one hand, It can be observed that Business ecosystem theory mainly refers to its members as organizations or actors (e.g. companies, standardization bodies, customers, owners). On the other hand, the technology ecosystem approach considers its members to be technology providers (e.g. wireless chipsets, laptop, router manufacturers or network standards). The digital ecosystem has a more integrated approach, allowing members from both domains as long as they are digitally enabled. Furthermore, one recurring point that appeared in the literature review concerning all three ecosystem types is the importance of platforms [92]. From the perspective of business ecosystems the platforms are described as the main enabler for value creation, growth and ensure ecosystem healthiness. According to Iansiti and Levien, these members should follow the keystone strategy. In the case of technology ecosystems, platforms are software that either solve and important technical issue in the industry or they simplify the access to resources, constantly allowing new members to joining the ecosystem. Lastly, in the digital ecosystem view, infrastructure technologies together with services create an overall services platform which increases the total available value for other stakeholders.

Ecosystem control and interdependence According to Pfeffer and Salancik [114], controlling some indispensable and irreplaceable resources for a member of an ecosystem, translates into power over the respective actor. Another classiﬁcation proposed in Business Ecosystems Revisited [80] takes in consideration the number of actors and their interactions. Therefore, two types of member interdependence are identiﬁed: reciprocal and pooled. A reciprocal interdependence describes an ecosystems where there is a qualitative focus when developing relationships between members. A pooled interdependence system favors the quantitative development of operations, resulting in the expansion of the organism. In other words, the number of actors which are likely to interact with each other increases when moving from reciprocal to pooled interdependence. Based on their organizational design (level of resource control and the type of interdependency), literature review [132] revealed four different types of business ecosystems (Figure 2.4). Firstly, there is the case where the organism is controlled by an actor who delegates (externalizes) some complementary contributions to the value generation process. In this case, the central pillar of the ecosystem brings around a few important partners with which it develops key relations. This type is called a Supply system. Firstly it is important to mentioned that it still remains a system. Even though the controller has high bargaining power over the partners, they still bring unique resources required for the process. Secondly, this form of organization highlights that co-evolution doesn’t necessarily translate into collective innovation. If the partners are forbidden to conduct it, the controller is the only one entitled to make it [132]. One example of supply system would be an automotive ecosystem. In the second scenario, the design of the organism is controlled by an actor who, by making a key asset available to other actors, enables them to conduct their own activity [132]. This is a Platform ecosystem. In comparison to the supply system, the platform is organized based on the pooled interdependence. This favors the existence of multiple independent economic initiatives. Moreover, being designed around the concept of modularity, a platform offers different interfaces for the other members of the community to access its resources. If the business contracts are not restrictive, it enables new entrants to join the network and provide extra value to one of the niches of the system [132]. An exponent of this type of industry would be the video game industry. Chapter 2. Methodology 15

The third ecosystem identiﬁed is the Community of destiny. This design reunites a more heterogeneous group of members than the Platforms or Supply Systems. These type of ecosystems imply the existence of a common characteristic between the actors, characteristic which is independent of the members inclination. For example, they could all be survivors of a speciﬁc event. Communities of destiny do not develop around a central actor, but rather united by an “existential solidarity”. An important point to mention regarding this ecosystem type is that the power of innovation is ambigu- ous. There were cases, like Sematech, in which the entire ecosystem was frightened by the impact of innovation [132]. As a consequence, the adaptation process did not include for a long time important innovative solutions to the existing challenges. For example, the DVD supporters fought against the propagation of DIVX, the innovative technology, to protect the existing industrial rules. The fourth scenario consists of Expanding communities. In this case, an essential resource brings together a big number of members [132]. As in the case of the platform, all the actors which access the key resource, individually add unique contribution to the value creation or distribution process. The main difference between the two cases, is the nature of the key resource. In the case of the platform it is controlled by another member of the community, whilst here it is a common good in the community. The most suggestive example for this scenarios are the free-software communities. In these systems, all the actors have a common objective (ex: developing a software).

FIGURE 2.4: “Inspired by Understanding Business Ecosystems [132]"

2.6.2 Technology adoption theory Existing theories considering technology adoption can be grouped in 5 categories [66]: (1) Diffusion Theories, (2) User Acceptance Theories, (3) Decision-making Theories, (4) Personality Theories and (5) Organization Structure Theories. Diffusion looks into how, why and at what pace innovative technologies and ideas spread across a community. User acceptance theories focus on modeling human intention phenomena that surrounds the use of information technology. Decision-making theories address the need of modeling a decision processes, considering a given objective and a set of crite- rion. Personality theories used in technology research look at personality attributes and character traits in order to understand and justify reactions to disruptive technology. Organization Structure Theories, similar to user acceptance models, try to provide an explanation to how technology is accepted. However, they distinguish themselves by focusing on how specifically organizations (not individual users) adopt theories and the role of organizational culture, structure and values have in this process. Furthermore, when reviewing IS adoption behavior theory, the work can mostly be divided in two categories: pre-adoption and post-adoption research [156]. In the case of pre-adoption studies, the goal is mainly to understand factors which influence users to use the system or service Chapter 2. Methodology 16 for the first time. Post-adoption research aims to discover what drives repeated system (or service) usage [162].

Pre-adoption theories User acceptance theories are often used to explain consumer acceptance of technologies and their use intentions [83]. A large number of theories have been developed throughout the years. Some of the more general theories that have been extensively researched in the domain include: Theory of Reasonable Action (TRA) [1], Theory of Planned Behavior (TPB) [7] and the Decomposed Theory of Planned Behavior (DTPB) [136]. However, they lacked speciﬁcity in regards to information systems and technology. In order to cover this gap, the Technology Acceptance Model (TAM) and its variations (TAM2, TAM3 and UTAUT) were proposed. These models make the pre-adoption theoretical body of knowledge of this work The starting point of TAM models is Fred Davis’s doctoral thesis project [33]. In his work he claims that system use is a response explainable (or even predictable) by analyzing user motivation. Further on, this motivation is directly inﬂuenced by an external stimulus, which at the base consists of system features and capabilities (Figure 2.5)

FIGURE 2.5: Initial conceptual TAM framework (Image Source: [33])

Technology Acceptance Model (TAM) The final version of TAM was proposed by Viswanath Venkatesh and Fred Davis in 1996 [35] after Davis conducted multiple iterations on the model. It aims to explain what determines computer acceptance and to how is it related to user behavior. Figure 2.6 presents the building blocks of the model. Perceived Usefulness is defined as “the degree to which a person believes that using a particular system would enhance his or her job performance” [34]. Perceived Ease of Use is described as “the degree to which a person believes that using a particular system would be free of effort” [34]. The perception over the system can be influenced by external factors. Furthermore, the resulting perceived usefulness and ease of use influence behaviour intention which can lead to a usage behavior.

FIGURE 2.6: Technology Acceptance Model (Davis, 1996), Source: [35] Chapter 2. Methodology 17

Technology Acceptance Model 2 (TAM2) Venkatesh and Davis have further analyzed what are the external variables that impact perceived usefulness [147]. They have proposed two dimensions for the determinants: (1) social inﬂuence which includes the subjective norms around the user, voluntariness of the use and image and cognitive instrumental processes covering the job relevance, output quality, result demonstrability, perceived ease of use [83]. The resulting model was named TAM2.

Technology Acceptance Model 2 (TAM3) Venkatesh and Bala have further used research identifying external varales inﬂuencing the perceived ease of use to develop an integrated model called TAM3 [146].

Unified Theory of Acceptance and Use of Technology (UTAUT) In order to integrate all existing findings related to acceptance and use of technology, Venkatesh, Morris, Davis and Davis came up with Unified Theory of Acceptance and Use of Technology [148]. The model defines (Figure 2.7) 4 predictors of user’s behavioral intention: (1) performance expectancy, (2) effort expectancy, (3) social influence and (4) facilitating conditions. Performance expectancy is the result of aggregating similar concepts in the theory: “perceived usefulness, extrinsic motivation, job-fit, relative advantage and outcome expectations” [83]. Effort expectancy include the perceived Ease of Use defined in TAM and system complexity. They also mention that social influence is not particularly important in voluntary contexts. Four user characteristics were found to be moderating the influence of these constructs: (1) Gender, (2) Age, (3) Experience and (4) Voluntariness.

FIGURE 2.7: UTAUT model (Image Source: [148])

Post-adoption theories Post-adoption behaviors have a critical role in the long-term success of a product or service [105]. This class of behavior includes but is not limited to willingness to share opinion about the experience, continuing to use the product (or service) or enhancing connected behaviors (e.g. buying and using other products or services from the same company). One of the widely used models in this area is IS Continuation Model.

IS Continuance Model If the TAM based models are focusing on initial acceptance, Bhattacherjee has created the IS Continuance Model in order to discover why people continue to use the that In- formation System, even after the ﬁrst interaction [20]. It is one of the ﬁrst models that consider the difference between adoption and usage continuation behaviours. Chapter 2. Methodology 18

FIGURE 2.8: IS Continuance Model (Image Source: [20])

Figure 2.8 presents the 4 block architecture of the model. In essence it states that an the individual intention to continue using a system is influenced by (1) the satisfaction generated during prior use and (2) the perceived usefulness. The framework shows that user satisfaction is the congruence of two factors: perceived usefulness (user perception of how beneficial will be to use the IS system) and confirmation (the user perception on whether the system performance has actually met the expectations user had). Thong et. al. claim that Perceived Ease of Use and Perceived Enjoyment are also constructs in the model [141]. Through empirical data he confirms that users intend to continue the use if the experience deemed to be useful, easy to use and enjoyable. To sum up, this section has presented some of the most important concepts related to ecosystem research and it has presented a subset of technology adoption theories, with a focus on TAM and IS Continuation Model. 19

Chapter 3

The mobile landscape

The following chapter aims to depict the environment in which applications dedicated to mobile users are developed. At the end of the section, the reader will be equipped with the knowledge required to understand technology differences and the value co-creation process in the ecosystem. Research identiﬁed four areas of discussion relevant for the current work. Firstly, Section 3.1 will introduce the central steps of of the mobile ecosystem evolution. This section will allow the user to understand how we got to the existing understanding of the smartphone and how did various actors contribute to this state. Secondly, Section 3.2 will brieﬂy explain how innovation in mobile services has developed. Thirdly, Section 3.3 will analyze each component of the mobile landscape, using an adapted version of the ecosystem layering presented by Brian Fling [47]. Lastly, Section 3.4 will outline the major ecosystem challenges for creating mobile touch points.

3.1 The evolution of Mobile landscape

The modern mobile phone is more than a communication and information device. It allows users to stay connected permanently to the internet, sending and receiving voice and text messages and even purchasing goods and services. In fact, it enables users to do almost everything they would normally do on their desktop computers ([47]). However, it has not always been the same. The capabilities and use of mobile phones have been continuously evolving for more than 50 years. The following chapter will present the most important milestones of this process, using the classiﬁcations presented in ([47]) and observations of ([110]).

3.1.1 The Brick Era (1973 – 1988) Even though the mobile technology starts to be developed around 1950s, it is rather focused on mil- itary uses. Generally, this period is characterized by large and heavy headsets, which can hardly be called mobile. In his book, Brian Fling recalls “My first taste of mobile telephony was with my father’s suitcase phone that he purchased when I was still in school—basically a corded receiver connected to a portable radio the size (and weight) of a car battery.”. In 1972, B-Nets launches in Germany the first mobile phone that does not need human operators in order to connect calls. In 1980s, the mobile telephony shifts to commercial use. Manufacturers focus on designing an experience similar to the traditional phones. This is also the time when the first generation (1G) of wireless telephony is developed which allows only for voice transmission. It had low capacity and it started as a luxury due to high prices. In parallel, at the pressure of AT&T, Federal Communications Com- mission (FCC) developed the first market regulation ([110]). One of the most emblematic devices of that time was the Motorola DynaTaC. Due to high prices and sizes, Brick Era phones were used only by those for whom constant communication was critical, like stockbrokers, salespeople or real estate agents ([47]). Meanwhile, in 1983, the U.S. Defense Department opened the Internet to everyone. All the communication over internet was done at that point through computers. E-mail became instantly Chapter 3. The mobile landscape 20 popular, Telnet was used to connect to remote machines and Archie allowed to manage shared di- rectories. The shift to personal Internet consumption together with advancements in technology (e.g. LANs and Ethernet) opens the business for delivering Internet to masses.

3.1.2 The Candy Bar Era (1988 – 1998) As mobile technology starts to be deployed on cars, cell phone carriers are pushed to provide constant remote coverage. Deploying more cell towers meant that now, devices could lower their power requirements. This allowed smaller handsets. "Candy bar" is the term industry uses to label the rectangular shaped phones, rather thin, with a small screen and a number keypad bellow. Devices became at this point small enough to be carried in a pocket ([47]). Starting with Finland in 1991, the network shift to second-generation technology (2G). Even though the mobile industry allowed for mobile data exchanges over the network (e.g.SMS, MMS or ring-tones), internet technologies were too heavyweight for that time. However, this did not stop Tim Berners-Lee to invent the World Wide Web. Meanwhile, data speed improved, business started to develop internet based services and computer browsers become more efficient [110]. All these resulted in 16 million global Web connections in 1993 In the meantime, due to a period of financial prosperity, consumer demand for mobile phones increased. This increased more competition between network providers and generated even more competition between device manufacturers, leading to reduced costs for final the users, further increasing mobile accessibility ([47]). All things considered, it has to be pointed out that all this activity is mainly happening in North America, Western and Northern Europe and Australia, while for example in India, the first cell-phone and service was launched in July 1995 ([134]).

3.1.3 The Feature Phone Era (1998 - 2007) Feature Phones are telephony terminals focusing on voice capabilities which also provide multimedia and internet related features. On one hand, this evolution was powered by network providers who introduced 2.5G (GPRS) and 3G considerably increasing the data transfer capabilities ([110]). Further- more, the development of Bluetooth and Wi-FI standards allowed for ubiquitous connections. This in turn enabled device manufacturers to include internet based applications and services. On the other hand, devices went through an incremental evolution in terms of user experience and features. In 2001, Nokia introduces the ﬁrst monochrome display cell phone, the 8250 model ([134]). Other relevant relevant innovations were the integration of camera and color display in mobile phones (2002 by Nokia), multi-screen capacity (2003 by Samsung), sliding technology, external storage drives or the Walkman phone - playing music directly from your handset (2005 by Sony). Phones slowly transform into gadgets which aim to reﬂect user personality, through features, looks and feel ([134]). Even though these innovations had an immense potential, it was hardly tapped due to the structure of the Ecosystem. Although Web reached mobile devices, high prices, lack of marketing and rendering inconsistencies made users stay away from it. Business models based on tightly coupled manufacturer-carrier relationships are doubled by incompatible proprietary technologies. Further- more, third-party development is hold back by proprietary APIs, libraries and OSes ([110]). This meant most of the innovation was controlled and coordinated by network operators and device builders [47]. In this context, mobile developers mostly limited themselves to developing visual and audio artifacts (e.g. wallpapers and ring-tones), games and applications that are sold through network operator portals. ([47]). It also meant that users were generally locked in to incompatible technologies. Nevertheless, mobile penetration continues to grow. In 2002, there were twice as many mobile devices as PCs. Chapter 3. The mobile landscape 21

3.1.4 (First) Smartphone Era (2002 - 2007)

Yesterday’s smartphone is tomorrow’s ordinary mobile. Email and Web access were arguably the defining smartphone applications a year ago, but numerous mid-market handsets now have this functionality as standard - A. Charlesworth, The ascent of smartphone (2009) According to TechTerms, a Smartphone “is a mobile phone that includes advanced functionality beyond making phone calls and sending text messages” ([138]). When analyzing the Smartphone industry, ([26]) needed to define a set of inclusion criteria for devices covered by the study. They adopted a more feature-centric approach, picking phones with “an operative system, a wi-fi system and the possibility of sending and receiving emails”. After analyzing other interpretations as well, Hee-Chang Song observes two reoccurring aspects in Smartphone definitions: (1) the integration with mobile telephone technology and (2) the ability to access the internet ([131]). Taking this in consideration, it quickly becomes clear that the boundary between Smartphones and Feature Phones is rather blurry. This also reflects in the overlapping time frames of the two categories. However, the separation becomes more clear once the next generation of smartphones is presented. The naming confusion may stem from the context in which it was created. Even though the term Smartphone appears in various publications long before 1997, Ericsson is responsible for coining it that year, when it announced its GS88 “Smart Phone”. Moreover, the word smart can encapsulate many attributes in a concise construct: intelligence, style, elegance, class, modernity ([121]). At that time, the GS88 model aimed to be an universal alternative to two different devices: the Personal Digital Assistant (PDA) and the mobile phone. Therefore, as the concept was created in the world of marketing ([161]), it can be argued that the naming had advertising purposes: outlining the new model on the market. Yet, it was later adopted by other companies with similar products. According to Google Books Ngram Viewer, the term started to be popular in written texts around 2002. Nevertheless, this contextualization defines another competence of the Smartphone: it allows Personal Information Management (PIM) ([161]). These device types would allow users to download, install and remove hundreds of applications. Part of these applications could also be used to personalize user’s interface. The main take away is the design paradigm shift. While feature phones would focus primarily on voice and text services, smartphones would focus on delivering multimedia data communication and mobile internet based services ([28]). Even though Ericsson used the term in 1997, the first phone that falls in the smartphone category was actually released in 1994 by IBM. Simon Personal Communicator had a monochrome LCD touch screen, with a 4,5 x 1,4 inches display, 1 hour of battery lifetime and all the core features a modern smartphone has address book, applications, predictive typing and a few extra ones (Fax and a jack for connecting to the land-line network) [61]. Unfortunately, the price and the time when it entered the market did not make it a popular acquisition, being used mostly in business world. Later on, Palm, Nokia, Blackberry, Motorola and many others released their models, running with various Operating Systems (Palm OS, Symbian OS, Blackberry OS or Windows Mobile). Only few came with a good enough mobile browser to display more than links, some text and an image at best ([27]). This resulted in an unattractive web browsing experience. Nonetheless, this didn’t stop them to integrate all new innovation coming from the Feature phones. Being inspired by P.C. design paradigm, smartphone manufacturers tried to deliver a portable personalized personal computer ([47]). In order for users to install applications for their specific device, they would either have to search in third party stores or to manually download them on their personal computer and then install it through a tedious process ([57]). Most of the smartphone producers were new on the mobile market, technology was constantly innovating and users entered an (unattractive) era of ubiquitous information (discretionary information retrieval and exchange). As a result, the ecosystem supporting the industry became more rich but also more complex than it was during the feature phone era ([28]). And for a while, this resulted Chapter 3. The mobile landscape 22 in poor market performance. A. Charland and B. Leroux summarize the smartphone use case perfectly: “if you had one of these devices, you were either a businessperson addicted to email or an alpha geek hoping that this would be the year of the smartphone.” [27]. According to ([47]), the first smartphone generation acquired at most 15% of the market share.

3.1.5 The Touch Era - (Second) Smartphone Era (2007 - Present) “Every once in a while a revolutionary product comes along that changes everything.” - Steve Jobs A quick recap for the state of the mobile landscape at the beginning of 2007: • Rich and diverse mobile innovation • A market dominated by Feature phones, built by many device manufacturers • PDA inspired smartphones running different young Operating Systems • A diverse and complex and rather close ecosystem • Tight coupling between carriers and device manufacturers • Poor user experience and content delivery in mobile web browsers More and more device features were researched and squeezed in those old cell phone devices, turning them in mini personal computers. However, people were not that interested and mobile phones remained mostly a peer to peer communication device. [47]. This is where Apple tried to make a change in January 2007, with the iPhone 3G. The new device changed people’s perception of what mobile technology can do. The first model proposed a disruptive interaction design for that time. Architects realized that the old mobile approach (physical keypad and small screen) is not enough and adapting the personal computer patterns it is not an optimal solution. Therefore, they reseted the entire mobile experience for the user [27]. It took all the important mobile features on the market and added the multi-touch screen experience without including a physical keyboard, allowing for direct interactions using finger gestures [2]. In the following years, Apple followed an iterative model adding new features or improving the existing product [142]. In 2008 through the O.S. 2.0, among others, it added 3G cellular network support and most importantly, allowed device owners to upgrade their software. Arguably, more important was was the launch of the new App store. This empowered developers to easily build and distribute platform applications. In 2009, the Lite (and cheaper) version of the device was launched, with bigger storage, compass and camera. In 2010, with iPhone 4, Apple makes a new innovative move, adding a high quality camera facing the user, opening the way for taking selfies. In 2011 with an O.S. update, they enable users synchronize their data between Apple devices through the iCloud service. This is just a sneak peak on how fast they also moved in the industry. Apple radically improved the user experience. And did it managed to do so through a set of well executed moves: • Shifted the interaction model from a physical based (using keyboards or pointed stylus) one to a multi-touch system based on finger interaction. This shift allowed for virtual buttons, new navigation patterns and multitasking capacities, • Improved the browsing experience. • Created the App Store. Initially, the iPhone was designed as a closed ecosystem, forcing third- party developers to build web-based application, which could only run in browser. As these were extremely limited and slow at the time, there was a need for building native applications. Therefore, Apple released the App Store, a mobile application that allowed developers to publish and monetize applications and users to quickly download and install them. [57]. Chapter 3. The mobile landscape 23

FIGURE 3.1: Market share evolution of mobile handset (Image source ([73]))

• Empowered developers to produce software and services. Until the arrival of the App Store, the mobile software development was not very attractive, as there weren’t many development tools, distribution was tough, operating systems were fragmented and monetization capabilities were uncertain ([57]). Apple provided a rich Development Kit, a structured, a proper process for verifying applications and distributing them and simple charging mechanisms for developers. This made apps being on the App Store reliable and qualitative and it gave developers a reason to build applications for the platform. This process resulted in a powerful Two-sided market. • Contributed to the shift of the ecosystem control structure. Before the release of the phone, mobile application development was highly dependent on device manufacturers and network carriers. With the emergence of application stores, carriers were no longer crucial in delivering application to the users. As a result, they were demoted to just infrastructure providers for the ecosystem ([126]). On the other hand, the Operating System replaced carriers in forming a relationship with device manufacturers. They are now acting as a platform for the ecosystem, working as enablers for service development, distribution and consumption. What did this changes mean in terms of user behavior? B. Fling outlines a valuable set of statistics obtained just one six months after the iPhone was released: • “84.5% of iPhone users report accessing the news and information, compared with 13.1% of the overall mobile phone market and 58.2% of the total” smartphone owners. • “58.6% percent of iPhone users visited a search engine on their phone, compared with the general 37% percent of smartphone users” • The number of users tuned into mobile TV or video clip watching on mobile has doubled in comparison with other smartphones • “74.1% of iPhone users listen to music on their device, while only 27.9% did so (on average) on smartphones and 6.7% of the overall mobile phone population” This superior user experience also had impacted Apple’s market share. Even though in 2009 it was only responsible for less than 5% of the devices on the market, Apple made more than 40% of the industry proﬁt. Chapter 3. The mobile landscape 24

Apple created a new user perception of what a mobile phone is and what it can do. After that point, the separation between smartphones and feature phones becomes more clear. Smartphones are ﬁnally ready to deliver what they promise: an integrated set of services based on communication, computing and information management ([127]) delivered through an attractive user experience. Despite this innovative approach, one can not attribute the smartphone development solely to Apple. After 2007, many other companies contributed to the phenomena. Google, through the development of the highly successful Android ecosystems together with Nexus phones. Windows, by improving the Windows Mobile O.S. and supporting the device manufacturers and developers in adopting it. Samsung and Huawei, through the development of highly successful handsets. Mobile browsers, like Mozilla and Opera, investing in the mobile browsing experience. And the list can go on. Last, but not least, their activity was also doubled by technological advancements like 3G and 4G networks that were capable to deliver high data rates at low costs. Feature Phones also developed new capabilities like more efﬁcient Operating Systems (KaiOS), adapting modern browser technologies (HTML, CSS, JS) and some of them even integrated voice assistants. However, most of them kept their initial design concepts: the small screen (240pixel x 320pixel) and the D-Pad navigation. More information about their features and context of use can be found in Annex F.6.

3.1.6 The smart device era As Fling’s description of the mobile evolution stops in 2010, there is a need to also mention another recent evolution of the mobile paradigm: the diversification of device smartness. In the Touch era, evolution mostly focused on phones as being the main devices being capable of accessing voice and data services. However, the development of communication technology continued and many new device types emerged: Smart TV, Smart Home, Smart Watch, Smart cars or drones. Most of them fall under the "umbrella term" mobile devices, but they can vary greatly in how they are meant to be used, computational power or interaction possibilities [125]. Innovation in innovations in powered sensors and wireless technologies made device classification and definition even more complex. They enabled the development of sensor-driven devices which communicate and share information part of the Internet of Things[77]. The development of location aware services, physical and virtual sensors (like blogs and social media) created new opportunities for service providers ([71]). Nonetheless, evolution came with the price of complicating the development for mobile devices [77]. As some of the technology is shared between them and smartphones [77], their development also meant a leap forward for the capabilities of the smartphone.

3.2 Evolution of mobile services

As per Section 3.1, the new generations of devices constantly created innovative ways of communication, user interaction and consumption of mobile services. This section will focus specifically on what drives the evolution of mobile services in this innovative environment. On one hand, Raul C. Basole claims that traffic in the mobile service ecosystem is driven by “the immense consumer thirst for data-centric mobile services, including email, text messaging, the mobile Internet, mobile applications, and mobile commerce” ([14]). This perspective focuses on the relationship between users and service providers. This dynamic leaves space for analyzing the push - pull market effects. On one hand, as users find limitations in the existing services, they search for alternatives. The market pull phenomena phenomena is summarized in ([25]) as: “[an] unsatisfied customer that creates new demand, which requires problem solving”. One example in this sense are the services allowing users to make frontal pictures with their camera (selfies) and share them on social media (e.x. Snapchat). Both the frontal camera and the sharing intent existed way before this Chapter 3. The mobile landscape 25 service appeared. However, the process was too lengthy and unpleasant for the user. On the other hand, we can talk about a market push effect when users are forced to update to the new version of the Operating System. Toshikiko Yamakami approaches the evolution of mobile services from a different angle ([158]). He analyzes the dynamics, diversity, and heterogeneity of the environment around mobile services using the Ecosystem Analogy. He adopts the definition of the digital ecosystem proposed by Gerald Briscoe: “any distributed adaptive open socio-technical system, with properties of self-organization, scalability and sustainability”. He bases his research on his previous work which explored business model engineering of mobile services in the Feature Phone Era ([157]). In his more recent paper, he extends his analysis, adapting the evolution stages for services delivered in a more modern Mobile Digital Ecosystem. Initially, the focus should be on ensuring user acceptance of the service. And for that matter, adoption is driven, in his view, by the content delivered through the service. At this stage, limited technical capabilities restrict service’s capability to deliver their mobile content to all existing users. Therefore, services focus on context-fitness for their user base. In order to overcome this limitations, the service needs strong business engineering skills coupled with constant communication with users. Furthermore, to optimize the evolution process, actors involved in the service delivery (users, device manufacturers, O.S. developers, carriers, content providers) have to collaborate and coordinate in order to update and release device capabilities and the existing content. This process can take a long time if the service aims to deliver top-quality content. Active user involvement is critical in achieving a good service. It allows the service to better understand user requirements, fine-tune its content based on their needs and educate its users to better engage with the service. Last but not least, according of T. Yamakami, the adoption of mobile services is further influenced by the evolution of mobile Internet. The resulting system can be classified as an ecosystem. In return, this evolution alters the set of constrains put on the service. The Cyclic Innovation Model (CIM) is an instrument used for describing continuous reform in public and private organizations. It illustrates the innovation process as a “circle of change”, linking changing in scientific insights, technological capabilities, changes in product design and manufacturing and changes in market demand. The four sections are closely intertwined and the coherent resulting system is, according to CIM the key to successful innovation ([18]). T. Yamakami, adopts this model to the Digital Ecosystem around mobile services. Figure 3.2 illustrates his simplified evo- lutionary model describing a few stages in the service development. This cyclic evolution model is showing the impact of every step on Visual Impact (mainly achieved through hardware improvement) and changes in programmability and interactivity. Chapter 3. The mobile landscape 26

FIGURE 3.2: Spiral evolution model of mobile services (Image Source: ([158]))

The most important conclusions resulting from T. Yamakami’s work are: • User involvement and acceptance is critical for service development; • Constraints and innovations have impact across the whole mobile service ecosystem; • Ecosystem collaboration is required in order to overcome mobile technical limitations; • Integrating an innovative artifact in a mobile service which aims to deliver high-quality content takes time;

3.3 State of the art in the Mobile ecosystem

James F. Moore established the theoretical framework for defining business ecosystems [102]. He uses an analogy to the biological ecosystem to describe the structure of a dynamic and diverse system where members co-evolve while trying to create and deliver value through collaboration and competition practices. A business ecosystem according to Moore is: “an economic community supported by a foundation of interacting organizations and individuals—the organisms of the business world”. Considering the high number of actors involved in the mobile landscape, the different levels where they integrate and the shared interest in producing, offering or selling of mobile phones and mobile services, the mobile ecosystem can be classified as a specialized business ecosystem. While the previous sections focused on the evolution of the ecosystem, this section will take a closer look at the existing layout of the landscape. Extensive research has been conducted to describe and understand the mobile ecosystem. One of the most cited works is Visualization of interfirm relations in a converging mobile ecosystem by Rahul C Basole [15]. He uses visualization sciences and the theory of complex systems in order to identify and present the structure and dynamics of almost Chapter 3. The mobile landscape 27

7000 companies engaging in over 18 000 relationships in the mobile ecosystem. Feijóo et al. explore the digital ecosystem in order to deﬁne a set of taxonomies describing the mobile content [44] delivered by the ecosystem. Tewari et. al. focus on analyzing the growth of platform as a business model [139]. As this work has its roots in assessing the potential value of technology, it is important to understand what are the components involved in the development of mobile technology. There- fore, the content will be structured around the layer classiﬁcation of the mobile ecosystem presented in Figure 3.3 presented by [47] in Mobile Design and Development. As was discussed in Section 1.1, the research is looking at technology options and their impact on the business layer. Moreover, the previous sections highlighted the importance of Device Manufacturers and Operating Systems in the co-creation process. In consequence, this segment will pay particular attention to layers 3 to 9. Furthermore, as aggregators are not relevant for the scope of this research, their activity will not be tackled. Lastly, due to the integrated nature of mobile platform with their operating systems, the layers will be merged and discussed as one. Furthermore, in Moore’s understanding, an ecosystem is a network of organizations [102]. However, Fling does not stick to this approach and mixes organizations (e.g. operators and platform owners), with goods (e.g. devices), resources (e.g. Application framework) and services. Nonetheless, based on actors creating the goods (e.g. device vendors), using the resources (e.g. developers) and providing the services, one can identify the organizations part of the system.

FIGURE 3.3: Mobile ecosystem layers (Adapted from ([47]))

3.3.1 Operators The ﬁrst layer in the mobile ecosystem is the Mobile Network Operator (MNOs) also refered as operator or carrier [47]. The carrier installs and operates mobile communication networks, enabling subscribers to access voice and data services, handling the billing and in some cases also selling devices [160]. Chapter 3. The mobile landscape 28

3.3.2 Networks In order for operators to deliver information and communication services, they have to operate a mobile network. As mobile network technology has evolved from 1G (ﬁrst generation), in the early 1980s, to 5G being currently (2019) deployed in some parts of the world [31]. As can be observed in Figure 3.4, 2nd, 3rd and 4th generations are the ones currently in use. According to GSMA, they all now have more or less an equal share of the global internet connections, but there will be an increase of newer generation technologies in the following years [95]. Considering the technological differences between generations, this change should allow for more reliable connections, providing internet services at higher speeds and with a higher Quality of Service [90]. However, there are several important aspects to keep in mind. (1) Not only the mobile carrier networks can provide data services. For example, one can use a combination of Broadband and WiFi connections in order to connect to the internet. However, using carrier connections allows users to also take advantage of their voice services. (2) Technology is deployed at different rates and at different generations in different regions of the world. For example, it is expected that in 2020 the Economic Community of West African States to have about 34% of their mobile connections using 3G technology, while in the Economic Community of Central African States, this number to stay as high as 62%. Moreover, it is important to note that only 1% of the users of both regions have 4G based connections [95].

FIGURE 3.4: Global mobile adoption by technology (Image Source ([95]))

3.3.3 Devices Also known as handsets, terminals, these are mainly portable computing devices. In “Conquering the Mobile Device Jungle: Towards a Taxonomy for App-enabled Devices”, C. Rieger and Tim A. Majchrzak believe that many of the mobile devices are “more-or-less app-enabled”. This category of devices become “particularly useful” because there are applications that extend their use possibilities. In order to help the classiﬁcation of mobile devices, Rieger and Majchrzak developed a taxonomy based on device media richness of outputs, richness of both user inputs and degree of mobility. Figure 3.5 presents a two dimensional representation of the devices, based on richness of output and input. In some cases, one company can develop multiple device classes. For example, Google with Google Nest hub (Smart home), Google Pixel Series (Smartphone), Google Pixel Slate (Tablet) or Sony with PlayStation Series (Console), SmartEyeglass (VR/AR headset), Xperia (Smartphone). One device Chapter 3. The mobile landscape 29 class which was not included in their taxonomy, but remains relevant for the research is the Feature Phone. Some of them also have an application ecosystem and can at least deliver web applications.

FIGURE 3.5: Mobile device taxonomy (Image source: ([125]))

In order to scope the discussion, the research will focus on technology choices that apply mostly for Smartphones, but in some cases also for Feature Phones. Different technologies are applied when developing applications on device classes [125]. Consequently, this limitation is required in order to focus the analysis on a subclass of application choices. According to PEW Research Center [135], it is estimated that about 5 billion people world wide have mobile handsets. About half of their devices are smartphones. However, a considerable amount of people own a mobile phone that is not a smartphone, especially in the emerging economies, as is pictured in Figure 3.6. Chapter 3. The mobile landscape 30

FIGURE 3.6: The state of Phone ownership (Image taken from ([135]))

According to the research made by Cecere et. all [26], the device manufacturing industry is both diversiﬁed and extremely competitive. After researching the innovation related to smartphone, they concluded that: (1) the number of new products constantly increases at a remarkable pace; (2) smartphones considerably improve over time, with new functionality constantly being released, both on the hardware and software side; (3) the industry is repeatedly facing new entrants, coming from other industries. According to StatCounter, the most successful device vendores are Samsung and Apple, who together own more than 50% of the mobile vendor market share worldwide (Table 3.1).

Samsung Apple Huawei Xiaomi Oppo LG Motorola Other 31% 23% 9% 7% 4% 3% 3% 19%

TABLE 3.1: Mobile Vendor Market Share Worldwide (April 2019)

Cecere et. all made that observation as well, noting that “there is no clear dominant design in the sector (a specific path along an industry’s design architecture, which establishes dominance among competing design paths)”. Firstly, they argue that there is a strong product differentiation between Chapter 3. The mobile landscape 31 companies. Their analysis focuses on the vertical innovation - “the introduction of new additional features (e.g., wi-fi connectivity, touch screen), or to the improvement of technical characteristics (e.g., weight) that is evaluated in the same way by all consumers”) and horizontal innovation (“the development of innovations that imply the change in existing product characteristics that do not appeal in the same way to different consumers”) concerning mobile devices. Even though competition and technological development lead to some degree of convergence regarding vertical innovations (e.g. the use of Bluetooth or WiFi), companies used strategies and conducts in order to protect their designs. For example, Apple and Samsung still compete when it comes to screen size, screen thickness or Operating Systems. One other example is Samsung’s foldable phone which innovates the way in which the touchscreen is used. Lastly, they point out that patents are one of the common strategies used by vendors to protect their designs. In the cases of devices, these patents include utility patents (“protects the way an article is used and works”) and design patents (“protects the way an article looks”) [112], covering the handset shape and graphical user interfaces. On the same topic, DeviceAtlas [36] expects that 2019 is not probable to show major innovations in the Apple device offering, however, Samsung is preparing to disrupt the market with Foldable phones. Even if this may affect their market share, Apple is not expected to follow their competitors anytime soon [36]. Since the disruption created in 2007, Apple tries to position itself as being the most innovative and cutting- edge mobile platform provider on the market. This is also supported by how DeviceAtlas sees their mobile device product “iPhones are a trend in themselves - they don’t need to follow others”. Considering that Feature phones are by design resource constrained devices, with a very limited feature set, the section will further focus on identifying the major smartphone device attributes.During the literature review it was observed that most research analyzing devices or technology concerning smartphones performs some degree of analysis regarding smartphone general characteristics. A selection of these will be presented in order to paint a clear perspective over the multitude of factors included in these characteristics. Considering the innovative nature of device functionality the description does not pretend to be exhaustive. In order to conduct their study concerning the relations of mobile device attributes with user- perceived quality of applications, Noei et all. have analyzed 210 devices and compiled a list of 38 raw attributes (Figure 3.7)[107]. Furthermore, they define seven categories relevant for device attributes: (1) Body (e.g. device dimensions), (2) Display (e.g. colors used, size, resolution), (3) Platform (e.g. O.S, CPU, GPU), (4) Memory (e.g. internal ROM and RAM), (5) Batery (e.g. talk time or battery size), (6) Camera and (7) The release date. As they defined these categories after eliminating the common features in all their devices, some of the core device functions were not covered (e.g. Bluetooth support or browser). Chapter 3. The mobile landscape 32

FIGURE 3.7: List of raw device attributes (Table transcribed from ([107]))

Cecere et. all analyze the smartphone applying “the theoretical framework of products as a bundle of characteristics in the spirit of Lancaster (1990), Saviotti (1994) and Frenken, Saviotti, and Trommetter(1999)” [26]. To discuss product differentiation, they propose two subgroups of characteristics: (1) hardware and (2) software. When it comes to hardware features of a modern smart device, they talk about connectivity (e.g. 2G/3G/4G networks, wi-ﬁ, WLAN, NFC), processing units (chipset, CPU/GPU), sensors (e.g. accelerometer), display characteristics, writing interaction tools (touch based or keyboard based), memory related conﬁguration (card slot type, device and external memory), available ports (e.g USB), the type and the number of cameras, whether a GPS system is included and battery related attributes. On the other hand, software attributes cover the existence of a browser, what messaging solutions are available (e.g. push mail, SMS, instant messages) and how advanced the operating system is. In their view, these are all means through which handsets can differentiate from competitors. Lastly, a good summary of what device attributes are, is provided by L. Rakestraw et. all [81]. They make three central observations: (1) Smartphones have similar components as personal computer (e.g. processor, RAM, USB port(s), internal storage), (2) that users can customize and upgrade devices to match their needs (e.g. add additional storage) and (3) USB peripherals like cables for data transfer of headphones are available together with a smartphone.

3.3.4 Mobile platforms and Operating Systems (O.S.) The operating system is the core software found of every smartphone. The O.S. is in charge with the communications between the more abstract layers of software and the hardware layers of the devices. At the core of every operating system there is a kernel. This central module is generally responsible with process, task, memory and disk management. This is achieved with the help of drivers, which enable the communication with Input/Output components (e.g. camera or USB ports). Furthermore, through a middleware layer, the operating system exposes a set of APIs (Application Programming Interfaces), which allow developers to access hardware functions. These are the Application frameworks presented in Section 3.3.5, the 7th layer of the ecosystem. Lastly, the O.S. comes bundled with an application suite consisting of critical features of a mobile devices (e.g. user interfaces like menu and navigation, phone call and texting software) [81]. Every device needs to have an O.S. deployed in order to allow user interaction. Even though in the early days of the smartphone that meant a considerable diversity in terms of operating systems Chapter 3. The mobile landscape 33

(e.g. Blackberry O.S., Windows Mobile, Symbian) they all but two slowly disappeared from the mar- ket123 . The result is a duopoly between Android and iOS (Figure 3.8), with less than 2% of the devices running a different O.S [36]. One other actor worth mentioning is KaiOS, a new player coming to the market in 2017. Even though it wasn’t adopted by a large proportion of the global devices (0.5%), it is addressing a niche segment: the Feature Phones. Through a set of partnerships with device manufacturers, it aims to acquire over 50% of the segment until 2021 [152]. Furthermore, they already have an important presence in emerging markets, places where there is an active demand for Feature Phones (e.g. India, overtaking iOS, with a 4% market presence).

FIGURE 3.8: Mobile Operating System Market Share Worldwide (Data source: [56])

Android Platform With the largest share of the market (75.6), Android platform is still the fastest growing smartphone operating system ever [2]. The platform is developed by Open Handset Alliance, led by Google. The platform is rapidly evolving, releasing on average one new version every year 4. Each new release has a codename (e.g. Pie, Nugat, Kitkat), version (from v1.0 to v9 ) and an API level (from 1 to 28). The latest released version is Android Pie, which is version 9 and has API 28. At Google I/O May 2019, Google has announced that the next version (Android Q) enters in public beta phase and is expected

1Blackberry pushes users to use Android OS - https://blogs.blackberry.com/2017/12/supporting-bb10-and-bbos- customers-and-rewarding-your-loyalty 2Windows Mobile no longer supported by Microsoft - https://support.microsoft.com/en-us/help/4485197/windows- 10-mobile-end-of-support-faq 3Symbian stopped all the development and maintenance of its OS in 2014 - https://www.symbianos.org/ 4https://www.androidauthority.com/history-android-os-name-789433/ Chapter 3. The mobile landscape 34 to roll out in Summer 2019 5. Each new version comes with set of software improvements and new features available for users and developers. Table 3.2 summarizes key features shipped with each major version.

Version name Key features Pie (v9.0) • Adaptive battery and brightness • More efficient memory management • New system specific gestures • Single-button navigation system • App slices (allowing applications to display rich, dynamic and interactive content in the Google Search and Google Assistant) • Digital wellbeing features • Changed system behavior and look (e.g. rounded corners, new transitions between screens) • Richer messaging notifications (allows for full conversations, large images and smart one click replies)

Oreo (v8.0 - v8.1) • PIP (Picture-in-Picture) feature • Instant applications • Improved audio and visibility support for people with accessibility needs • Ambient screen • Notiﬁcation snoozing and categorizing • Simpliﬁed Vendor OS update procedures

Nougat (v7.0 - v7.1.2) • Multi-windows support that allows application to co-exist on the screen • Direct-reply and bundled notiﬁcations • Vulkan APIs that allow for better games and graphics development • Seamless system updates • Shorcut manager APIs • Keyboard image insertion • VR thread scheduling management • Carrier conﬁg options to manage video telephony • Source type support for Visual Voicemail • Multi-endpoint call support • Launch actions on app icon press

5https://www.androidcentral.com/android-q Chapter 3. The mobile landscape 35

Marshmallow (v6.0 - v6.0.1) • MIDI support • Permissions dashboard • App linking • Ability for applications to integrate with Google Assistant. • USB Type-C support • Fingerprint Authentication support • Custom Chrome Tabs for better in app browser support

Lollipop (v5.0 - v5.1.1) • Multiple SIM cards support • Lock protection for lost and stolen devices • HD voice calls • Support for 64-bit devices • Tracking battery consumption application • Released and implemented Material Design

KitKat (v4.4 - v4.4.4) • Google Now launcher • Public API for SMS management • Printing framework • Storage Access Framework • Chromium WebView • Audio monitoring • Screen recording

Jelly Bean (v4.1 - 4.3) • Multi-user accounts • Actionable notiﬁcations • Lock screen widgets • Created and implemented a new system UX • Voice search • WiFi service discovery • Sounds on camera taking photos • Gesture typing and support for new input devices (e.g. gamepads and joy- sticks) • 4K resolution support • Open GL graphics support Chapter 3. The mobile landscape 36

TABLE 3.2: Android feature availability by version [65]

In order to understand how different application frameworks interact with the Operating System, it is required to understand the basic layers of the Android platform. For a visual representation of the Android software stack, the reader can consult AnnexG. Furthermore, the platform encompasses multiple layers of the ecosystem. They will now be briefly introduce in order to create a complete overview, but they will be further detailed in the following sections. According to the official documentation [117], the six components of the Android platform are: 1. Linux kernel - the foundation of the platform, handling hardware related interactions like threading, memory management at the lowest level. 2. HAL (Hardware Abstraction Layer - a set of standard interfaces that have to be implemented by device vendors for their specific hardware components (e.g. camera, bluetooth). It allows Android to abstract lower-level driver implementations and provide a universal entry point for hardware related features. 3. ART (Android Runtime) - added in Android 5.0, ART ensures that each application on the O.S. runs in a separate virtual environment, with isolated state and processes. This component also exposes a set of Java APIs for OS libraries that handle core functions (e.g. drawing API, media management, building views). 4. Native C/C++ Libraries - In order to achieve fast response speed, Android uses C and C++ to write system services which need to be in close connection with the hardware (e.g. proximity sensors, accelerometer or the touch screen). This is why opening the camera is always slower than the feedback from a touch gesture. Even though Android exposes Java based APIs for these services as well, for these libraries there is a set of native (C/C++) libraries that can be used. 5. Java API Framework - the building blocks required to develop an application. This layer will be further explained in Section 3.3.5 6. System Apps - a set of applications which is central for device usage (e.g. email, SMS messaging, internet browsing, calling, agenda, etc.). Most of them can be replaced with 3rd party developed applications by users. However, they are useful for developers as they ensure key OS capabilities can always be accessed. One key aspect about the Android distribution is that it has been publicly available since 2007, under open source terms [2]. This allowed for massive adoption from other device vendors. How- ever, as the distribution was open sourced, mobile handset manufacturers sometimes customize (to some extent) their distributed version of the OS. This in turn, adds value to their products allowing for market differentiation, as was also observed by [26]. Device vendors often partner with carriers, social networks and content providers in order to further diversify their offer [52]. In order to ensure that all customized OS versions will run applications to a certain standard, Android developed the Android Compatibility Program to define a set of requirements for all distributions to respect 6. Only if the Vendor device distribution passes the CTS (Compatibility Test Suite) designed by Google, the device is labeled as Android compatible. This brings up the discussion of how Android OS new version releases are handled in the ecosystem. Figure 3.9 describes the ideal adaption process before Android 8.0 (Oreo) [88].

6Android Compatibility Program Overview - https://source.android.com/compatibility/overview Chapter 3. The mobile landscape 37

FIGURE 3.9: "Life of an Android release" (Source: [88])

1. Android team from Google releases the code for the new OS version. This initial release only runs on a reference device (e.g. Pixel) [137]. This would imply changes anywhere across the software layers: Kernel updates in order to include security patches or performance optimization, HAL/ART/Native libraries in order to support new OS features and services, API Framework in order to expose the functionality to developers and bundled applications. 2. The open source kernel is not by default compatible with all existing device Systems on Chips (SoC). Silicon manufacturers (chip-set vendors) adapt the kernel in order to support their hardware (Board Support Package). 3. The resulting OS version is changed by device manufacturers in order to incorporate the vendor specific OS requirements (e.g. define custom navigation patterns due to phone design, adapt applications to use optional hardware like the third camera or vendor owned applications like Huawei’s AppGallery). 4. Next, in case of partnership with carriers, they may also have requirements regarding OS behavior like locking it to a specific network or shipping a set of applications together with the smartphone. In some countries, irrespective to this relation, carriers have to certify the new release [137]. In all cases, the final version has to also pass the CTS. 5. The update is shipped to the users. In order to simplify the process, the Android development team rolled out Project Tremble which aims to standardize the HAL (Hardware Abstraction Layer). This has happened in Android 8.0 and offers backwards compatibility. The last factor that further diversifies the Android offering is the lightweight version of the OS, which came with every release since Android 8.0 (Oreo), Android GO. It was designed to run on resource constrained smartphones, with at most 1GB of RAM and in challenging environments (e.g. slow internet or few charging opportunities) 7. Furthermore, the Android team makes efforts in order to adapt the whole platform ecosystem to support it: play store applications, user interfaces, services

7https://www.android.com/versions/go-edition/ Chapter 3. The mobile landscape 38 and content 8. Considering to the device limitations and use challenges they try to tackle, it is an attempt to address the long tail strategy to smartphone users, particularly in emerging markets. iOS Platform In contrast to Google, Apple opted for a proprietary operating system, only shipped with their devices (iPhones) [124]. Started as a specialized version of the Mac OSX, iOS and the iPhone saw a meteoric increase in popularity. Even though iOS is hosted by only 21% devices of the market, their profit share of the smartphone industry has often reached 50% in the past years [76]. One core difference between iOS and Android is that the former is part of a tighter vertically integrated ecosystem. Apple is controlling most of the critical parts in the value supply chain in order to make and commercialize the iPhone [149]. It is designing the hardware (e.g. iPhone), owning, developing and maintaining the iOS platform, manages the complementary services (e.g. iTunes, iCloud or AppStore) and it is also in charge of the retail experience. Raymond Allan G. Vergara, points out that even though the technology giant outsources the production and assembling of devices to external companies, Apple “closely controls the design and development of its products”. Similarly to Android, Apple constantly releases new OS versions. However, one major difference between the two platforms is Apple tendency to push new releases of iOS to all their iPhones. For example, two months after iOS 10 was released, 72% of all iOS devices had the update and 19% on iOS 9. This high adoption rate translates in an easier time to develop and support applications across the device spectrum. The “unparalleled control over it end-to-end supply chain” [101] allows Apple to defend itself from opportunistic behavior of other actors in the ecosystem layers. According to G. Parker et. all [111], vertical integration can help mitigating against behavioral uncertainty. In Android’s case, device manufacturers and carriers see an opportunity to differentiate themselves using customized forms of the operating system. Due to total control over the design development process, they are able to keep the number of supported mobile devices to 14 9 (May 2019) and mostly 2 iOS versions. Consequently, there will only be a brief description of the iOS architecture layers. Furthermore, as the innovation of iOS follows more or the same patterns as on Android (constant innovation, a couple of versions every year, changes concerning both users and developers), the section will not include a feature by version presentation. However, if the reader is interested in this aspects, more information can be found in Apple’s official documentation10. The iOS architecture is also defined by layers of technology (Figure 3.10)[130]. Their role is to enable application to run on devices without having to implement hardware interfaces.

8https://developer.android.com/docs/quality-guidelines/building-for-billions 9https://support.apple.com/en-gb/guide/iphone/supported-models-iphe3fa5df43/ios 10https://developer.apple.com/documentation/ios_release_notes Chapter 3. The mobile landscape 39

FIGURE 3.10: iOS platform technology layers (Source: Mobile Developer’s Guide to the Galaxy [2])

1. Core OS - encapsulates the kernel environment and exposes to the other layers low-level frameworks that handle among others: hardware connectivity, image processing across all devices, security and various kernel operations. 2. Core Service - provides a set of base frameworks that enable date and code sharing between libraries. Furthermore, some core system services are deployed at this level (e.g. iCloud Storage and In-App Purchase) 3. Media - exposes libraries related to graphics, audio and video. 4. Cocoa Touch - the entry point of the application framework, providing access to UI manipula- tion (through UIKit) and the main system functions (e.g. camera, touch input or contacts)

3.3.5 Application framework In order to help the developers to build native applications, platforms can offer a software development kit (SDK)[72]. As previous section pointed out, the application framework represents the collection of building blocks exposed by a platform to developers to build applications [47]. These building blocks take the form of APIs and are grouped together around features of the host operating system (e.g. communication, authentication, location). In the case of Android, the application framework is called Android SDK and in iOS’s case it is iOS SDK. Once an application is developed with a speciﬁc SDK, any further addition to the code base is bounded to use the same environment [84]. An- droid SDK API supports Java and Kotlin programming, whilst in the case of Cocoa Touch developers can use Swift and Objective-C. Both SDKs are used to create native applications. However, the use of multiple SDKs in order to develop an application compatible with multiple platforms can be both resource intensive and more time consuming [53]. In order to overcome these issues, researchers and the industry have searched for development frameworks that work across all platforms [84]. Various cross platform frameworks have either emerged for the mobile context or have been adapted from other development environments. Furthermore, the web is also seen as a viable application framework recently, with the evolution of Progressive Web Applications (PWA) and Accelerated Mobile Pages (AMP) technologies. Some of these development choices will be further presented and discussed in depth in Chapter4.

3.3.6 Applications According to Emerging trends in mobile apps market and their potential impact on mobile users engagement in the global economy[159], “A mobile application (app) is a software program developed for small Chapter 3. The mobile landscape 40 handheld devices such as mobile phones” [47]. Applications are built using Application frameworks and are generally used for completing different activities in a more flexible and efficient way [159]. In the context of this research, the term Mobile Web Applications will refer “applications for mobile devices that require only a Web browser to be installed on the device in order to be used” and are developed with Web Technologies 11. For example, the Twitter social media portal 12 is an example of a web applications. The term Platform Application will refer to applications developed using Platform Native SDKs or Cross Platform technologies which are designed to run on a specific platform, on the Application layer (e.g. The Android Twitter Application 13). Finally, the term Mobile Application will encompass all the applications (Web or Platform) accessible on a mobile device. Mobile applications will also be referred as Apps. A more thorough discussion regarding the use of mobile applications will follow in Chapter5. One common aspect about the modern smartphone platforms is that they provide Application markets or stores (e.g. AppStore and Play Store). They play a central role in discovering and accessing applications and digital services. Markets act as an intermediary between smartphone users and developers [140]. Both industry and Academia have proposed multiple types of classifications for smartphone applications. Apple’s AppStore and Google’s Play Store define different sets of categories to group their applications based on genre (e.g. games and applications), purpose (e.g. business, music, weather, sports) and whether they are paid or free. The taxonomy of application content made by C. Feijóo [44] can be applied to the corresponding applications, resulting in: (1) Adapted or repurposed - apps ported from other device types that have been adopted to match the mobile context (e.g. Keynote developed for Mac), (2) Original or specific - applications designed considering mobility aspects and (3) Augmented - applications that explicitly take advantage of mobile features (e.g. accelerometer or location services) [129]. Zhu et. al. [163] used web search and device logs to classify applications around a 9 primary categories (Internet, Business, Communication, Game, Multimedia, Navigation, SNS, System and Reference) and 18 other secondary categories. Mokarizadeh et. all applied cluster- ing techniques on 21,065 Google Play applications [100] and showed that applications do not always fall in store category. The general conclusion of these research outcomes is that even though there are many approaches to classify applications, there is no standardized way of doing it [129]. Fur- thermore, existing techniques do not provide refined inclusion criteria and well defined category boundaries. One core application which will further influence the analysis of technology choice implications is the Web Browser. It is a specialized software which acts as a window and interface for smartphone users to access the web [2]. In order to deliver real time responses, it uses a combination of web technologies (e.g. Javascript, CSS, HTML5, Ajax). There are many available Mobile Web Browsers, out of which the most popular are: Chrome, Safari, Samsung Internet, UC Browser and Opera 14. In order to enhance browser development, Google initiated the Chromium Project aiming to develop an open source stable, fast and secure browser and an open source Operating System 15. Chromium supplies the majority of the Chrome Browser code but also other proprietary browsers like Microsoft Edge and Opera. In the same way in which the Android and iOS Platform components and services are at the heart of every application, the rendering engine (or layout engine) is the central component for a browser. It is charged with laying out and rendering the content of web pages [2]. Modern web browsers usually own one of the following engines:

11https://www.gartner.com/it-glossary/mobile-web-applications 12https://mobile.twitter.com 13https://play.google.com/store/apps/details?id=com.twitter.android&hl=enUS 14http://gs.statcounter.com/browser-market-share/mobile/worldwide 15https://www.chromium.org/ Chapter 3. The mobile landscape 41

• WebKit - an engine released in 2001 used by Safari and other Apple products.16 • Blink - a open source Google fork of WebKit that has been adopted by Chromium based browsers17. • Gecko - an open source engine supported by Mozilla browsers 18. • U3 Engine - a WebKit fork maintained by the UC browser developer 19. Furthermore, research [150,3, 164] outlines a second important component for a Web Browser, the JavaScript Engine. All browser engines include a JavaScript Engine that interprets and compiles JS code, allowing for run-time compilation (JIT - Just-in-time) on the browser. Therefore, the choice of engine inﬂuences how fast the web application will run. Each of the engines previously presented uses a different JavaScript engine (e.g.V8, Nitro, SpiderMonkey). Applications running on web browsers are also developed using a (Web) Application framework. For these applications the browser works as a container hosting and presenting the user experience. In order to improve, browsers have to be constantly innovated. This is the only way to keep up and support new features and competences developed by the underlying technology layers. This lead to the adoption of a software versionining system similar to the one present at the platform level, where each new version has to be diffused in the ecosystem and adopted by vendors and users.

3.3.7 Services In B. Fling’s view [47], services represent “anything the user is trying to do” on the mobile platform. These are available at different layers in the ecosystem and they may include accessing the internet, making a phone call or paying for petrol in a gas station. It quickly becomes obvious that this interpretation is too vague for the scope of the current work. Literature review revealed numerous perspectives and interpretations of services in the mobile context. Ericsson’s Mobility Report as- sumes the carrier - smartphone owner, referring to mobile service as the provisioning of radio signal in order to ensure voice and data connectivity [42]. However, they also state that mobile service usage evolved to also include applications. Rahul Basole refers to mobile services with multiple occasions in his work [15]. He labels mobile serves as the activity of offering customer service in charge with billing, pricing and delivering bundled software to customers. Last but not least, in A. Becker et. al. research, mobile service delivery implies that “mobile devices are able to offer more services than just simple phone calls and text messaging” [16]. It can be observed that services can integrate multiple ecosystem actors and have different purposes. For example, accessing a mobile location service from the system service can serve a technical purpose like allowing application to create a context aware feature. On the other hand, it may have a transactional purpose, allowing the smartphone owner to receive a marketing notification triggered only in a specific geographical area. Whilst all of the interpretation are valid, neither of them is clear enough for the present research. Therefore, in order to clarify what is a suitable understanding of mobile services in the context of this work, a thorough literature review has been conducted. One common reference paper in the study of the service is Evolving to a New Dominant Logic by S.L. Vargo and R. Lusch [145]. They claim that the understanding of marketing in the 21st century should focus on application of competences, or specialized human knowledge and skills, for and to the benefit of the receiver. Since the service is more and more recognized as the cornerstone of global value creation [38], service integration with digital technologies generated important shifts in work practices and business models. Vargo and Lusch define a service as: "the application of specialized knowledge skills through deeds, processes, and performances for the benefit of customers" [145]. This definition

16https://webkit.org/ 17https://www.chromium.org/blink#TOC-How-do-I-port-Blink-to-my-platform 18https://developer.mozilla.org/ro/docs/Mozilla/Gecko 19https://technode.com/2011/06/13/chinese-browser-vendor-uc-released-new-engine-u3/ Chapter 3. The mobile landscape 42 obviously adopts an economic perspective, assuming a relationship between a service provider and a customer. The service can be called digital when it is utilizing the online channel to deliver the service to the customer [120]. Another connected research area concerns the impact of customer journey touch points on customer experience [46, 103, 96]. According to A. Steina and B.Ramaseshan [133], touch points are “instances of direct contact with any part of the product, service, brand or organization, across multiple channels and at various points in time”. Furthermore, one touch point can be seen as an interaction instance between a business and a customer or as “a combination of channel, device, and user task” [46]. Interactions can happen over multiple channels, some of which are digital (e.g. websites, smartphone applications, social media or email). Users can access digital channels with compatible devices like the smartphone. In this case, interactions triggered from the mobile context are called mobile touch points. A service that exposes digital touch points, which customers can access through a smartphone is called a mobile service. For example, MobilePay allows people to make payments using their mobile phones 20. The company offers a payment service (mobile service) which can be accessed through a mobile application (touch point) installed on customer’s smartphone. Furthermore, the company also exposes a web application (MyShop), a second service touch point, where shop owners can do the necessary steps to set up a payment point at their physical location. Therefore, MobilePay can be considered a mobile service provider. This deﬁnition will be used from now on when referring to mobile services. The implications of mobile touch points on customer experience will be further discussed in Section ??.

3.4 Ecosystem considerations for applications developers

To begin with, one can actually identify two major sub-ecosystems in the overarching mobile landscape: (1) Apple ecosystem and (2) Android ecosystem. Multiple research projects were conducted [149, 14, 38, 139] focusing on aspects ranging from value co-creation and monetization to platform openess and power distribution. Eaton et. al. see these groups as service systems (“an interactive configuration of various resources and their mutual exchange to facilitate value co-creation that is institutionalized and regulated through institutional logics and standards”. In their study they conclude that there is an uneven distribution of power in these system, resulting in powerful actors being able to forcefully frame others’ choices. Considering that developers and developing companies and even businesses owning mobile software applications are usually not as powerful in the system as Google as Apple are, they have to comply to their decisions on the ecosystem state. One of these examples is the AppStore regulations, Android’s CTS (Compatibility Test Suite) or the prioritization of Platform features. The degree of platform openness can influence this power dynamic. However, platform openness also imposes a trade-off between core platform direct revenue and more application development. In order to ensure the platform stays attractive for users and to protect their market share, both platforms have to ensure they differentiate on the market. Apple does it by vertically integrating the ecosystem and ensuring design innovation across all actors involved. In the case of Google, it externalizes some of the innovation to Device manufacturers that customize the Android distribution. Furthermore, they use crowd-sourcing model to improve their open source software. Lastly, Android ensures that innovation can actually be effectively adopted by the platform through standardization projects. A major benefit of the existence of these well defined sub-ecosystems is compatibility of software across devices. 20https://www.mobilepay.dk/ Chapter 3. The mobile landscape 43

Even though the research has been focusing on smartphones, it is important to know that both Apple and Android Device Vendors develop a large number of devices (e.g. iPad, Tablets, Smart Watch, Apple watch). In most cases, developers can easily adapt a native application working on smartphones to also work on these device sets. Furthermore, applications can also integrate with multiple devices in the same ecosystem and deliver enhanced services (e.g. smartphone push notiﬁ- cations delivered to the Smart Watch or synchronized storage between iPad and iPhone).

3.4.1 Consequences of platform differentiation As each platform is representative for each ecosystem, it is directly impacted by the need of market differentiation. They are also concerned by strategies that protect their platform design and the actions that protect the market from new entrants. As C. Risom pointed out, none of the platforms has any incentive to give up their control and power and follow the platform design proposed by the other one. In this specific case, platform design is understood as the tools, methods and resources used to develop their main products and services. Consequently, there is no foreseeable future for Apple doing Android applications or Google doing iPhones. However, these means the two ecosystems have to constantly innovate, otherwise they may lose critical market share. The Android feature history (Table 3.2) shows that both device manufacturers and the the Google team are capable of bringing new features to the platform services. Furthermore, for the same reason (protecting their platform design), Google and Apple propose two vastly different development environment and mobile experiences [2]: • Different programming languages and SDK used in development; • Considerable variations in Style and interaction patterns (Material Design vs Apple Design Guidelines); • Lockscreen integration • Multi-tasking support • Platform services like push notifications or in-app-advertisement During the third interview, N. Linde highlighted that lately design and interaction related differences have a tendency to converge to a common pattern. However, in his opinion this is not enough to deliver premium experiences to the end users. This is also due to the design limitations of stock Android applications. Lastly, even though the two ecosystems are direct competitors, they still exchange core technology. Apple buys low level hardware and displays from [149] Samsung, the leading Android device vendor. C. Risom explains justifies this paradox based on a need to protect the ecosystem form new entrants

3.4.2 Fragmentation Fragmentation was one of the reoccurring issue in research related to the mobile ecosystem. Out of 160 papers reviewed, 46 had mentioned it. The fragmentation problem manifests at four layers of the ecosystem: (1) devices, (2) Android distribution, (3) Android distribution modiﬁed by vendors and (4) Mobile Browsers. Previous section outlined different reasons for which versioning is required in each case. As P. Bruce pointed out (AppendixC), iPhone and iOS require application developers to maintain a couple of device-platform combinations for their applications. Nonetheless, this issue is not so problematic as on Android. To put the Android fragmentation problem in numbers: Chapter 3. The mobile landscape 44

• Over 170 Certiﬁed Android Partner Brands 21 that commercialize Android devices. Each of them is theoretically capable to provide its own distribution of Android platform; • 9 Platform versions with a signiﬁcant (>3%) number of users running them;

FIGURE 3.11: Android Platform version distribution (may 2019, Source developer.android.com)

Devices differ, among other things, on characteristics like display format, size, form, and functions of physical buttons [mobile_app_development_and_management_results_francese]. One of the most problematic consequence is the limited testing opportunities developers have, issue also identiﬁed by Francese et. al. [mobile_app_development_and_management_results_francese]. As P. Bruce mentioned during the interview (AppendixC, developers usually will only test the software on a selection of devices which has to be as representative as possible. Google admitted that the update process to bring an older device to the newly released Android distribution is costly, complex and lengthy [88]. As was discussed in Section G.1, this motivated project Treble. However, it was recently introduced, covering only 38% of devices. However, Google can not force any vendor to update their devices or to adapt existing devices. Therefore, even though the project may lead to a more uniﬁed ecosystem in the future, at the moment developers still have to manage device and platform changes on every update. Furthermore, as can be seen in Annex ??, OS interfaces (e.g. Samsung TouchWiz) and device controls can differ considerably. When it comes to browser fragmentation, problems are as stringent as in the other cases. The browser landscape is constantly changing [2]. Furthermore, browser popularity can vary based on the target market. Browser companies are competing and that makes each of them to develop their own rendering engine and JavaScript engine. The downside of this is that a website can look different if displayed by different browsers [94]. UNINCLUDED: (1) platform providers perform a critical role as they as keystones take care of healthiness of the business ecosystem

21https://www.android.com/certiﬁed/partners/ 45

Chapter 4

Technology Domain - An analysis of Application Frameworks

The ﬁrst research issue of this work tackles the technology choices in developing mobile services. Furthermore, it looks for their value proposition and limitations. As Chapter3 pointed out, application frameworks are the main building block when it comes to developing a digital solution accessible from the mobile context. The following chapter will focus on describing the main technology paradigms, understand their relationship with other members and structures in the mobile ecosystem and lastly, based on an adapted ecosystem technology framework, propose a deﬁnition of the technology domain in the context of mobile services.

4.1 An overview of mobile application frameworks

As was presented in Chapter3, mobile application frameworks are bundles of software libraries that provide structure and guidance in the application development process. Intensive research effort has been investing into describing and comparing mobile application frameworks. Furthermore, as it will be presented later in this chapter, industry has also been adopting a wide range of technologies in this process.

4.1.1 Related research Researchers have taken various approaches when studying this domain. Some focus on what the technology used by the industry. For example, Biørn-Hansen et. al. analyze the adoption and popularity of various tools and development frameworks [24]. Through an online survey they found that PhoneGap, Ionic and React Native are the most used frameworks both in personal and professional use. Another research approach commonly used is developing a survey or taxonomy of application related concepts based on existing research. In 2018 Biørn-Hansen et. al. have published A Survey and Taxonomy of Core Concepts and Research Challenges in Cross-Platform Mobile Development, an extensive work that reviewed over 100 research papers describing the state of research in the area of Cross- Platform mobile development [23]. After classifying their ﬁndings, they pointed out a considerable lack of research in regarding security issues. Furthermore, underline the lack of research related to Progressive Web Apps. Some others have taken a more technical approach, drawing discussions and conclusions after conducting one or more applications. For example, A. Biørn-Hansen and G. Ghinea have developed two cross platform mobile applications analyzing how frameworks handle custom communication bridges with the native platforms [22]. They found that even though designing and implementing these bridges are non-complex tasks, performance can differ greatly from one situation to another. Another take on the subject is identifying requirements for a desirable development Chapter 4. Technology Domain - An analysis of Application Frameworks 46 framework, as did Gaouar et. al. [17]. Some of their aspects that made their list are: the integration with mobile platforms, the development environment, APIs and documentation or resource consumption. Contributions do not only come from the academia environment. IBM has published Native, web or hybrid mobile-app development, an analysis of the existing mobile development paradigms [70].

4.1.2 Framework classification Multiple classification approaches have been identified during the literature review process. In order to cover all existing development paradigms, the frameworks will be split in three categories (1) Native, (2) Cross-Platform and (3) Web. For each category, if necessary, further distinctions will be made. In order to illustrate how they work, some of the most popular Frameworks will be briefly presented. Due to the high number of existing software frameworks, only a selection will be presented. The choice is based on available information in literature review and on how used they are by the industry. Indeed the line between apps and web is often blurred in an ecosystem where apps can be built entirely with web technologies, can pull their data and content in via web API requests, or can act as simple app shells for what is essentially a browser (WebView). It can be useful to think of a web-native continuum, with native at one end and web at the other, and various hybrid models in between. - Ruadhan O’Donoghue

4.1.3 Native Application Frameworks A brief explanation of how native applications are developed on Android and iOS has been presented in Section 3.3.5. Native applications are programs specifically developed for a specific O.S. [104]. As it was pointed out, Google and Apple have build an ecosystem around their platforms, adopting different strategies regarding openness and adopting common practices. Consequently, application frameworks differ in terms of tools, APIs and build systems [27]. A. Charland and Brian LeRoux wrote some years ago: “In fact, the only thing these operating systems have in common is that they all ship with a mobile browser that is accessible programmatically from the native code”. And not much has changed since then. In order to develop Android applications, developers use XCode IDE and Swift or Objective C programming languages. Apple offers a tightly integrated set of auxiliary tools that ease the development process (e.g. Testflight or Apple Developer Documentation1). The same goes for Android development, powered by Android Studio IDE, Kotlin and Java languages and other tools like Espresso for testing or Android Profiler for diagnosing app issues 2. The Software Development Kits (SDKs) are tightly integrated with the platform features. The Android Java API Framework (AnnexG, Figure G.1), provides a set of customizable User Interface (UI) components which expose APIs for developers to particularize and integrate them in their application. The same goes for the four layers of the iOS architecture which allow developers to create and manipulate UI, define animations, manage media or access other applications through a set of APIs. This allows native applications to have a look and behavior that integrates perfectly with the platform design patterns. Furthermore, since the Frameworks are built by Platform developers, they offer unhindered access to all device capabilities, updated hardware resources and platform features [82]. This also means they support all types of interactions and interfaces offered by the targeted O.S. environment [104].

1https://developer.apple.com/documentation/ 2https://developer.android.com/studio/proﬁle/android-proﬁler?hl=es-419 Chapter 4. Technology Domain - An analysis of Application Frameworks 47

Figure 4.1 shows the main development and distribution steps of a native application [82]: the source code and the images are compiled and transformed into binary ﬁles packaged and distributed through app stores.

FIGURE 4.1: Native application development process (Image source: [82])

4.1.4 Mobile Web Application Frameworks Even though mobile web applications are also a method to make software accessible on multiple platforms, they will be considered as a separate development paradigm. This is mainly due to the differences in distribution, running environment and the way applications features are developed.

A classical approach to Web Applications A mobile web application is a web application which is optimized for running in a mobile web browser. These applications are developed with standard web technologies (HTML, CSS and JavaScript) [82, 123]. Various applications frameworks (also known as web frontend frameworks) are wrapping these technologies in order to offer developers an extended development environment to build complex and large web applications. Some of the most popular are Vue, React and Angular 3. However, according to the same statistics, there is a considerable amount of cases where developers choose to use no overarching application framework. This is possible since the web itself is an application framework where these three technologies and their libraries are bound together in order to deliver web resources through browsers. Figure 4.2 presents a simplistic architecture of a classical web application. The application runs in a web browser and is connected to a set of web services. When queried, these services are in charge with serving resources that are put together and rendered to present web pages to the user. This communication is done through the Internet. Therefore, connectivity becomes critical for accessing the service. Since mobile web applications are actually delivered through browsers, they are platform independent.

3https://2018.stateofjs.com/front-end-frameworks/overview/ Chapter 4. Technology Domain - An analysis of Application Frameworks 48

FIGURE 4.2: Logical structure of a mobile web application (Adapted from: [123])

As more browsers supported a continuously growing set of features appeared, the web required a set of standards to simplify the development process. To answer this need, multiple Standards Development Organizations have been established (e.g. IETF, W3C or WHATWG). They bring together working groups in order to create a standardized approach to develop web features [151]. For example W3C and WHATWG worked together in order to develop HTML5 features. HTML5 enables browsers to actually compete in terms of feature parity with native applications. Location based APIs, Sensor APIS, storage and push notiﬁcations are just a few examples of what features could be available for mobile web application development [2]. However, different browsers adopt these standards at different rates (e.g. iOS Safari doesn’t support the Orientation Sensor interface while mobile Chrome and Android browsers implemented it 4)

A modern approach to Web Applications As older research points out (e.g. ), the classical approach to mobile web applications had a hard time in delivering a true native experience. As an answer, multiple design practices have been adopted [2]: • Responsive web design (RWD) - delivering resolution independent web pages. These are flexible layouts that can adapt resolution in order to fit most screen sizes. • Progressive Enhancement - a technique involving progressively improving the capability of an application. The application serves a single base page for all devices. Through JavaScript enhancements, the page is built until it delivers the optimal experience for user’s specific device. • Mobile-First Responsive Design - a process that starts from a mobile-optimized application which applies RWD principles. However, once accessed it will also use progressive enhancement until it delivers the most suitable content and functionality for that specific device. • Adaptive Web Design (Server-Side Adaptation) - “browser-sniffing” is a technique which involves the use of a device detection solution. The client side uses it to inform the server what is the target device. Using a database containing device capabilities, the server can build a highly optimized page. “RESS: A Hybrid Approach” - a combination of adaptive and responsive approaches, RESS uses server-side adaptation to create an initial page optimized for a class of devices. The web page content is further adapted on the client-side using through responsive design. By leveraging these design practices and existing browser features, a couple of mobile web application breeds are commonly referred both in research and used by the industry.

4https://caniuse.com/#search=Orientation%20sensor Chapter 4. Technology Domain - An analysis of Application Frameworks 49

Progressive Web Applications (PWA) These apps aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins. - Alex Russell, Google Chrome Developer The term Progressive Web App (PWA) defines web application which take advantage of modern browser features to create rich applike experiences [2]. There are ten fundamental concepts that define this category of applications: progressive and responsive, installable and independent from internet connectivity, with an app-Like aspect and fresh content whenever available, safe, discover- able, re-engageable and linkable [21]. There are three key components in a PWA that allows it to pursue these 10 goals [12]. • Service worker - a script that leaves outside of the browser window and listens to a set of pages. Whenever events are triggered from these pages, it can intercept them and modify them (as described in Figure 4.3). The development of the service worker allowed for offline use of the web app. • Web App Manifests - describes the application, containing information about its icons, colors and orientation. • Push Message API, and Notifications API - they enable web applications to take advantage of the O.S. Notification feature. • Homescreen shortcut

FIGURE 4.3: Service worker integration (Source: [68])

“At its core, PWA allows websites (web apps) to become less web-like and more app-like.”

Accelerated Mobile Pages (AMP) Another popular approach for mobile web applications is AMP. Accelerated Mobile Pages is an open-source HTML framework which helps developers improve page download speed [2]. The framework allows for building a static web pages using speciﬁc ﬂavors of HTML, JavaScript and CSS. Applications developed with AMP achieve so fast load times with the price of having access to a limited set of JS features and HTML5 tags. For example, no extra JS libraries are allowed other then the ones provided by AMP-JavaScript.

4.1.5 Cross-platform Application Frameworks Literature review revealed that cross-platform development research has its roots in 2011, when Charland and Leroux conducted one of the first studies on the topic [27]. At that time, in a debate comparing web native technologies, they forsaw that the technology winner will be a hybrid solution. Eight years later the debate is still on. However, all this time, the ecosystem went through Chapter 4. Technology Domain - An analysis of Application Frameworks 50 a continuous transformation, “abandoning” many of its old members, whilst nurturing the development of many others. Research has been tracking this evolution as well, constantly publishing papers describing the state of the art at different points in time [91,6, 78]. Cross-platform (or multi-platform) is an umbrella term that describes platforms following the principle: “Write once, run anywhere” [40]. In the case of native applications developers have to create a different software application for each platform they target. In the case of cross-platform solutions, a single development framework and development process are used to reach all devices. Of course, developers are still limited by what platforms are supported by the application framework. Moreover, it is important to remember that the term is not describing a specific tool, framework or development process. Multiple technical frameworks fall in this category (e.g. Ionic, Cordova, React Native or Flutter). However, all these frameworks can be classified based on how they architect the applications. This classification takes in consideration: user interface rendering process, device APIs accessability and code compilation techniques [40]. The classification used in this chapter will rely on three recently published research papers which do an excellent job at presenting the main findings and concepts around cross-platform frameworks. In Taxonomy of Cross-Platform Mobile Applications Development Approaches, El-Kassas et. al. survey development approaches in an attempt to create a global view over the landscape. Their results include a comprehensive categorization of the cross-platforms approaches, pros and cons for each approach, illustrate how each framework is used and point out some of the existing open research areas [40]. Secondly, in A Survey and Taxonomy of Core Concepts and Research Challenges in Cross-Platform Mobile Development, Biørn-Hansen et. al. review over 100 research papers related to cross-platform development and report on what what is the current state of research in the field. They build their analysis around 4 core concepts in mobile development: (1) user experience, (2) device features, (3) performance and (4) security). Their main findings show that is essential that the research process adopts an user-oriented approach. They also highlight that the knowledge base contains a considerable amount of claims that are not backed by empirical verification [23]. In order to have a complete overview, An Empirical Study of Cross-Platform Mobile Development in Industry is employed to understand the perspective the industry perspective on the topic. Biørn-Hansen et. al. conduct an online survey with 101 participants with a mobile development background in order to identify what are the popular frameworks, adoption rates and arising issues related to the use of these technologies. Their findings describe a general impression of performance and user experience penalties. They also point out the popularity of React Native, PhoneGap and Ionic frameworks. The following classification does not aim to be exhaustive. Instead, it will focus on the main approaches used by the industry in developing applications. Lastly, even though pure web applications are also considered as cross platform solutions, they will be discussed separately, in Section 4.2. This distinction is necessary to highlight specific features and implications of the pure web category (e.g. distribution, browser dependency, and specific technology frameworks).

Hybrid Frameworks falling in this category combine the concepts of web applications and native applications. The principle behind hybrid development is to create an abstract layer which is platform independent, that exposes device and platform features to a WebView component (WKWebView on iOS). These features include, but are not limited to device storage, sensors data or camera. The We- bView is in charge with executing and rendering web pages. This enables developers to use the standard web technologies (HTML, CSS and Javascript) to build the application logic and the user interface. When the application needs to access a platform or device feature, it invokes a Cordova plugin which acts as a bridge between the Javascript call and the platform API. If a plugin does not exist, it can be developed and included in the project. The application code and the web code are Chapter 4. Technology Domain - An analysis of Application Frameworks 51 bundled together and distributed as a native application, through any available application stores. This also allows for ofﬂine access to the application content, as the resources and logic is part of the application package[22]. This container implementing the abstract layer is called a Native-Wrapper [23].

FIGURE 4.4: Hybrid approach architecture (Source: [22])

Hybrid application frameworks are in charge with setting up the application and exposing the universal set of Javascript APIs. The most popular choice in this category is Apache Cordova, an open source framework. It handles the initialization process of the app container and it provides a set of core APIs for app development (Figure 4.4. When building web interfaces, HTML and CSS are used to build the UI components. In order to offer a better development environment, a new set of libraries have been developed in order to enhance Cordova’s capacity to deliver richer user interfaces (e.g. Sencha Touch or Ionic). Developers using these libraries can use visual components that are designed to mimick the look of Native application interfaces[23].

Interpreted A second approach in cross-platform application development is the interpreted approach. Similarly to hybrids, a bridging component is used to expose device APIs in a universal framework. How- ever, interpreted apps do not use a WebView component to render the web pages. Instead they use a code interpreter that translates (using Just in Time compilation) web based UI components in native user interface components (e.g. a React View in an Android TextView). In the case of hybrids, WebViews would handle the interpretation and rendering of the web code. To solve this issue, In- terpreted applications contain a JavaScript engine (e.g. JavaScriptCore) that is optimized for reading and translating web code. Furthermore, since the UI is no longer bound to the WebView, Interpreted approaches allow developers to integrate native developed components in the application. Chapter 4. Technology Domain - An analysis of Application Frameworks 52

FIGURE 4.5: Interpreted approach architecture - the case of React Native (Source: [22])

Some of the most popular interpreted frameworks are React Native, NativeScript or Titanium Ac- celerator. If in the case of Cordova the bridging between the native side is done through a collection of plugins, in the case of react native this is a collection of importable modules. One important consideration for interpreted frameworks is that they don’t have a standardized way of building bridging elements [22]. In the case of hybrids, plugins are inter-operable between all frameworks. However, a module developed for NativeScript to bridge the NFC communication can not be imported in a React native environment. The difference is that all hybrids have been extending Cordova’s capabilities, also adapting its standards. On the other hand, even though most Interpreted application frameworks use the same web technologies to build the interfaces, the underlying framework APIs are totally different.

Cross-compiled A third approach to cross-platform development involves cross-compilation. These frameworks take an application written using a common programming language (e.g. C# or Dart) and compile it, obtaining a Native byte code executable for each supported platform. Since the code is interpreted at compile time (Ahead-of-Time), there is no need for an interpretor in the final application. Two different approaches can be further distinguished: with a bridge (e.g. Xamarin) or without a bridge (e.g. Flutter). In the case of Xamarin, the SDK (Xamarin Native) exposes a set of C# APIs for accessing platform specific services and specific UI Widgets for iOS and Android 5. When compiling, it translates the C# calls to services and corresponding Widgets. For simple UI designs, developers can use the Xamarin.Forms. Instead of using platform specifc APIs for UI components, the library exposes a universal set of APIs that are automatically mapped to the corresponding Android / iOS Native Widgets at compile time.

5https://docs.microsoft.com/en-us/xamarin/xamarin-forms/ Chapter 4. Technology Domain - An analysis of Application Frameworks 53

FIGURE 4.6: Interpreted approach architecture - the case of React Native (Source: [22])

Flutter also provides an SDK that developers can use to access platform features. Moreover, developers can also build custom platform channels to access custom or unsupported platform services. The main difference between Xamarin and Flutter is the rendering process (Figure 4.6. Flutter’s SDK is built on top of the Flutter Engine, which is in charge with rendering SDK Widgets on the screen 6. Flutter exposes a set of Framework specific UI Widgets. Developers can theme those, using both An- droid and iOS predefined styles in order to recreate the platform specific design. The code describing the application logic and UI, together with the SDK are compiled ahead-of-time to a native library. The engine code is also compiled with Android NDK/iOS LLVM. This allows the engine to communicate directly with the platform low level APIs (e.g. Native C/++ Libraries in Android, AppendixG) 7 for canvas management and event handling. The all these are bundled in the application package. When the application runs, it loads the Flutter library (app specific code, Flutter SDK and engine) and delegates all rendering, input and event handling to the Flutter engine. This architecture also allows the framework to no longer have to communicate with the high level platform API framework (e.g. Java API Framework in Android), and take control of the entire rendering process without the need of a bridge to the native framework.

Other approaches Research highlighted two other framework paradigmes (1) Model Driven (MD) [cross_platform_model_driven_development_heitkotter] and (2) Component Based (CB) [113] approaches. MD frameworks use a Domain-Speciﬁc Language to describe the user interface of the application. A generator is then used to convert the models in native code for the target platform. Component Based frameworks are a hybrid solution between native code and a common application language. Framework developers would deﬁne a set of application components and rules regarding how these components would be translated for each framework. Developers would provide the navigation patterns and the views associated to each components and then the tools would handle the entire transformation. However, research revealed that neither of these approaches have been adopted by the industry. Umuzoha and Brambilla argue that the main cause for the rejection is the lack of standard modeling language for mobile development [144].

6https://ﬂutter.dev/docs/resources/faq 7https://ﬂutter.dev/docs/resources/technical-overview Chapter 4. Technology Domain - An analysis of Application Frameworks 54

4.2 Analysis framework development

First of all, the scope and purpose of the domain have to be defined. Further on, the section will follow a 3 step process to create a suitable analysis framework for this model block. The first step is to adapt the existing analysis framework to to specificity of mobile application research. The second step involves identifying which members should be included in the Technology Domain. The framework should also outline groups of members with similar characteristics. This should help in the next stages of the model development. Last but not least, the analysis needs to focus only on relevant characteristics of T.D. members. Therefore, the third and final step is concerned with defining these areas of focus.

4.2.1 Scope deﬁnition Technology Domain is the ﬁrst block of the three-layered model built in this research. As mentioned in Section 2.1, the model should present relevant characteristics and competences of the most relevant application frameworks. Relevance in this case will be linked to characteristics that either create the value proposition of the framework or cause the limitations of the framework in relationship with the Application Domain or the Business Domain. Furthermore, as Section 4.1.2 highlighted, there is a wide and diverse selection of mobile application frameworks that can be used for development. The analysis will only look at a selection of frameworks, the most popular and representative ones for the industry.

4.2.2 Stage 1 - Adapting Adomavicius et. al model of technology roles Each Application Framework in the Technology Domain could be described as a Technology Ecosys- tem. In order to identify the members of the ecosystem and to define the boundaries of the analysis, the section will start from Adomavicius et. al. model of technology roles and paths of influence (presented in Section 2.6.1, Figure 2.3). In their work, they support Saviotti and Metcalfe’s claim that “technologies are best represented by their technical characteristics (internal structure of a technology) and service characteristics (services performed by a technology)”. In their model, they split technology based on three roles: (1) product and applications, (2) components and (3) support and infrastructure. These three can be mapped to research components presented so far. Firstly, (1) the final product in this work is a digital solution accessible from the mobile context which we will call from now on as a mobile application. The characteristics of these applications will further be described in Chapter5, based on the user perspective. Secondly, (2) components are technologies enabling the development of the product. In the context of this work, they are the mobile application frameworks presented in Section 4.1.2. They provide developers tools and resources to develop the applications. The last step of the model mapping, (3) the support and infrastructure role is ensured by the mobile platforms and device manufacturers presented in Section 3.3. One could argue that application frameworks are actually members of the support and infrastructure domain. Even though this may be a valid interpretation, the work emphases the active role that browsers and WebViews have when using web applications and how interpreters and rendering engines enable the use of applications developed with a cross-platform frameworks. Section 3.3 has discussed about the main support and infrastructure drivers in the mobile ecosystem. This section will describe components enabling application development. Strong arguments can be made to prove that some of the paths of influence proposed by Adomavicius et. al. have meaningful effects in the mobile ecosystem. However, this chapter will use their work to further describe the roles in the ecosystem. Chapter 4. Technology Domain - An analysis of Application Frameworks 55

The model of Adomavicius et. al. includes both software and hardware technology. Moreover, mobile applications do not require exclusively software components (e.g. sensors or camera lens). However, the analysis aims to focus on application development frameworks. Therefore, the research will be limit itself to identifying components related to the software components (application frameworks).

4.2.3 Stage 2 - Component identification and classification As it was already discussed, members of the component layer are Mobile Application Frameworks. Section 4.1 has already outlined 3 classes of frameworks: (1) Native, (2) Cross-platform and (3) Web. Therefore, the members of the mobile application frameworks ecosystem can also be grouped based on this classification. It should be pointed out that, at this stage, the research deliberately ignores other ecosystem members (e.g. IDE providers, developers or application owners). This is a self imposed limitation in order to focus the discussion. Moore has a similar approach when illustrating the ecosystem concept through exemplary cases. He reduces the whole construct to its nucleus like Apple, IBM or Wal-mart [80].

4.2.4 Stage 3 - Component characteristics definition Section 4.1.2 presented the technical characteristics of each component. However, in order to understand their implications on the Application Domain and Business Domain, the analysis needs to also take in consideration non-technical characteristics of each member. This shall be done, once again using the ecosystem analysis. Each framework is essentially part of a digital sub-ecosystem of the larger mobile application ecosystem. L. Marjamaa-Mankinen points out in her research that a digital ecosystem involves a “set of technologies related to one another through some functionality or services, incorporating various stakeholders such as customers, financial firms, or regulators”[92]. The actor centred perspective on how technology is used is exactly what is required in order to achieve a complete component description. Therefore, by combining the two approaches (technology focused and actor oriented) one could identify the following characteristics of an application framework ecosystem: • (Technology centered characteristic) Development resources (libraries) usable by the community. As product complexity evolves, developers are more and more dependent on using preex- isting modules to keep costs and development time under control. [4]. • (Actor centered characteristic) Developer community. It is central for the evolution of the framework, as it is the main user of the application framework. Their activity shall be analyzed both in a quantitative manner, but also in qualitative manner. • (Actor centered characteristic) Ecosystem interdependence and control. It can be argued that each application framework owner works as a platform where ecosystem members co-create value in the form of mobile applications. However, this development process is strongly influenced by how key resources (e.g. libraries and knowledge) are controlled and evolved and who are the stake-holders involved. Note: the main inclusion criteria for components characteristics was their relevance for the problem domain. However, it was decided that it is in the reader’s interest to understand all framework characteristics before investigating the problems they can cause. This 3-step process is illustrated in Figure 4.7. Furthremore, the outcome of Stage 2 is answering the first research questions:“ What are the main technology options in order to develop mobile applications?”. The figure presented in Stage 3, represents the the technology domain, component of the final model of this research. Chapter 4. Technology Domain - An analysis of Application Frameworks 56

FIGURE 4.7: Framework adaptation process Chapter 4. Technology Domain - An analysis of Application Frameworks 57

An important consideration when reading the components characterization is that they are ecosystems as well. Therefore, they are subjected to co-evolution both in their sub-ecosystems bot also in the greater mobile ecosystem. This means that in time, members density can change (the number of Cordova based frameworks which are actively in use), they can get fragmented (e.g. React and React Native) or they could even converge (PhoneGap and Adobe lead to the development of Cor- dova). Same goes for their characteristics (e.g. the size of communities). This view of component evolution is aligned with the population perspective adopted by Adomavicius et. al. They belive it is important to “acknowledge the variance and differences among members” and that technological evolution further changes these differences of the members.

4.3 Analysis of Technology Domain components

Literature review [23] and industry analytics [98] highlighted a considerable amount of possible application frameworks. It was decided to focus on six of them: Native Android and Native iOS, Flutter, Cordova and React Native representing the cross-platform framework class and Angular to represent the Web category. The selection took in consideration three aspects: (1) community relevance, (2) ensuring diversity in terms of ecosystem conﬁgurations and (3) ensuring category representation. In order to determine the community relevance, research proposes a framework shortlist resulting from literature review. Further on, StackOverﬂow Trends tool8 was used to analyze developers discussion and interest for each member (Figure 4.8). Therefore, this selection of frameworks should be representative for the vast majority of existing choices.

FIGURE 4.8: Framework discussion evolution over time (Image created with StackOver- ﬂow Trends tool)

8https://insights.stackoverﬂow.com/trends Chapter 4. Technology Domain - An analysis of Application Frameworks 58

4.3.1 Analysis sources The following data sources will be used for the analysis: • GitHub repository9 - one of the largest repositories for open source resources. It will be used to search for libraries and applications (source for reusable modules) and wikis (source of knowledge) for each framework. Results were filtered to maximise relevancy (at least one update in the past two years and at least 50 approval stars) and match the development language of the framework. Stars are the main ranking method of the platform. When users decide to offer a star to a repository, they show their appreciation for the project maintainer10. For example, to obtain libraries for Flutter, stars:>=50 fork:true language:dart pushed:>=2017-05-30 flutter search query was used. The results are not expected to return the exact number of libraries, instead, they are used to show the general availability of resources. • TIOBE Index for May 201911 - provides a measurement unit reflecting the general interest for a programming language. The index is calculated based on how searched is that language across all popular search engines. The metric represents the percentage of the total searches for the +" programming" query. • 2018 State of JavaScript Survey12 - a survey of over 20000 developers, from 153 countries, conducted by freeCodeCamp editors S. Greif, R. Benitte and M. Rambeau. The present work uses the survey in order to evaluate the overall community opinions about some of the frameworks in question. The results revealed the degree of community interest in various development frameworks and most liked and disliked aspects about them. • Developer Survey Results 201913 - a survey of over 90000 developers from all continents which aims to discover technology trends and existing developer interests. It was used to further understand how are frameworks perceived by developers. React Category iOS Android Angular Cordova Flutter Native GitHub 5,501 8.988 2,050 384 1,238 758 repositories GitHub 60,290 138,326 37,662 4,962 6,254 1,122 Wikis Framework repository (MAX) - - 48.6k 77.7k 65.6k GitHub 14.3k Stars (Switf) (Java) 1.15% 16% (JS) (JS) (JS) (Dart) TIOBE Index (Obj-C) (Kotlin) 2.69% 2.69% 2.69% 0.5% 1.6% 0.3%

TABLE 4.1: Framework ecosystem statistics Data was not always available for all frameworks from all sources, especially for more recent frameworks. This is why multiple sources reporting on the same areas of interest were included in the report. The data was collected in May 2019.

9https://github.com/search 10https://help.github.com/en/articles/about-stars 11https://www.tiobe.com/tiobe-index/ 12https://2018.stateofjs.com/mobile-and-desktop/overview/ 13https://insights.stackoverﬂow.com/survey/2019#overview Chapter 4. Technology Domain - An analysis of Application Frameworks 59

FIGURE 4.9: Community opinion and interest in Application Frameworks (Data source: 2018 State of JavaScript)

4.3.2 Native - Android A strong characterization of the native Android ecosystem was already provided in Section 3.3, while Section 4.1.3 explained more about the technical considerations of the Android SDK. The ecosystem is mainly coordinated by the Android Development Team at Google. They are in charge with developing the platform and the SDK. They also take ownership on the development process, coordinating the ofﬁcial documentation, Android SDK releases and maintain a close connection with developers. As already discussed, platform openness is characteristic for Android. Furthermore, Google tries to maximize developer freedom in terms of applications developed, quality an publishing. There is absolutely no entry barrier to access the Framework resources. Android’s framework ecosystem manifests a pooled inter-dependence behavior, adopting the expanding communities model. Since Google owns the platform as well, it doesn’t have to look for SDK monetisations. On the contrary, by minimizing the restrictions and control over the resources it aims to increase the applicaitons developed in the ecosystems. In turn, this strategy creates other revenue opportunities (e.g. services based on user data, as proposed by K. FriisA). The only degree of control manifested by the application framework is for standardization purposes. Inhouse SDK development ensures that the SDK is rich enough to offer connectivity to all device feautres and valuable platform APIs, everything with high performance. Furthermore, Google focuses on using the wisdom of the crowds to guide the platform and framework evolution. This aspect is emphasized both by talks at Google I/O conference, but also by how the company employs the Issue Tracker 14. The Issue Tracker allows Google Developer team to work together with Android developers in order to identify bugs in the framework and create new SDK feature requests. Asked about how Google prioritizes its internal resources, Andre Brogon (AnnexE) pointed out that the whole process relies on user needs. Therefore, it can be concluded that even though has a huge potential to control the ecosystem, it actually empowers developers to give direction to the framework co-creation process.

14https://issuetracker.google.com/issues Chapter 4. Technology Domain - An analysis of Application Frameworks 60

When it comes to development resources, the android framework excels both in terms of repositories and know how. This is not a surprise considering the market share of the Android Platform. Developers surveyed about it mentioned strong documentation, well established framework, strong tooling and full featured as strengths of the environment. Thus they further confirm the mature resource body. However, the most liked aspect is that the framework offers fast performance. In The State of JavaScript survey, a considerable number of participants never heard of Native development frameworks. Since the questions were mainly targeted at JavaScript developers, this phenomena may be justified. However, a considerable amount of respondents (30.4%) are not interested in learning it and just 1 in 10 participants would be happy to use the frameworks again. This phenomena may be justified by the development process around the framework. Surveyed people consider that native SDKs are too complex, making them hard to learn. The code base often feels “bug prone”, bloated and development looks clumsy. Issues related to code management may be solved when a larger developer base switches from Java to Koltin. However, for now, Java is by far the most researched programming language. As a general conclusion, it can be argued that the Native Android Framework is a strong and stable choice, offering a wide range of options in terms of resources and know-how. Developers have all the necessary tools to create highly performing and feature rich applications. However this comes with a considerable issues in terms of community happiness and development process.

4.3.3 Native - iOS Similar to Native Android, iOS application framework has been previously described in Section 3.3 and in Section 4.1.3. Apple is also in charge with maintaining and releasing the updates to the iOS SDK. However, in their case, as it was mentioned in Section 3.3.4, Apple has a tighter integrated ecosystem. Part of that involves designing the platform and the user experience enabled by the SDK. As it was previously mentioned, this is done in order to protect Apple’s platform design and ensure market differentiation. Other actions in the same line involve charging developers an annual fee in order to publish the applications they build with the framework. Also, Apple allows native code compilation only on Apple Mac computers. Last but not least, every app goes through a rigorous review of features, functionality, security and looks before it is allowed on the AppStore. All these are means through which Apple controls key resources in the ecosystem. This further results in a tighter coupling between the company and the developer community than in Android’s case. This control and inter-dependence diminishes the freedom and opportunities developers have when creating native mobile applications. Moreover, this does not only apply to applications developed with the Native SDK, but also to any developer targeting the Apple platform and wants to distribute an application through the AppStore. Even though the ecosystem around the Native iOS SDK still has a platform characteristic, there is a tendency of transforming it into a large distributed supply chain, with well deﬁned boundaries for development. However, the large number of developers and their critical role in innovating products keeps the system from evolving in such a direction. This ecosystem dynamic with higher degrees of control may be a second reason for which developers complain and want to stay away from Native development (according to the opinions presented in Figure 4.9). Even though Apple promotes the shift from Objective-C to Swift, the former is ranking high among developers and follows an ascending trend (TIOBE Index). This is unexpected, since the same programming language ranks second in the most dreaded languages of 2019 (2018 State of JavaScript). This category essentially means that most of the developers using Objective-C right now, express no interest in doing it in the the future. On the bright side, the libraries, projects, wikis and generally the ecosystem around iOS seems to be rich and complete. It was discovered [] that the iOS community ﬁnds the support provided by platform and framework developers to be extremely valuable. Therefore, it may be the extra care Chapter 4. Technology Domain - An analysis of Application Frameworks 61 for developers that makes native development to be stable, reliable and capable of delivering high quality products.

4.3.4 Web - Angular Google is also the creator of developing Angular. The project is entirely open sourced, but the company vowed to update it on a constant basis and to support every version for 18 months. Even though it exists since the beginning of the decade, Google has rebuilt it from scratch and released a new version in 2016 15. Most of the contributions to the frameworks seem to come from Angular Team members or from Google memebers. Therfore, it could be claimed that Google controls the evolution of the framework, but there is no other barrier or conditions to use it. The update came with a lot of changing including vital features for modern mobile applications (PWA support, browser animations or server side rendering). This shift may contribute both to the lower number of repositories and Wikies, but also to Angular taking the 4th position the the top most dreaded programming frameworks. However, developers seem to be pleased with the available framework features, documentation quality and Google’s support for Angular development. However, it seems like Angular is loosing momentum in favor of React and developers noticed it. This may also be due to a slow learning curve for the former and a bloated framework structure. Furthermore, the community is split on how good and efﬁcient is the programming style. One thing is sure, that a considerable people claim that it is performs poorly, it changes too fast and often this results in new framework bugs. It seems that all these are good enough reason for more than 60% of survey participants to avoid learning and/or using the framework. To conclude, it seems that the ecosystem didn’t reach at a mature point yet, even though Google and its community put a lot of effort into reaching that goal. Furthermore, it seems that even though Angular stirs a lot of discussions on technology forums, it may not necessary be a sign of high popularity, but rather of a framework vulnerability.

4.3.5 Cross-platform - Cordova Cordova framework was created after Adobe acquired the PhoneGap framework. In order to create more available resources, the company extracted the core engine and libraries and transformed it in an Application Framework. It was later released under open-source terms with the name Apache Cordova. As described in Section 4.1.2, it is the central framework for developing Hybrid applications. Since most of the hybrid frameworks are just a version of Cordova, but with richer features (e.g. Ionic or PhoneGap), the contributor community to the platform is rather large (over 3000 members on the official Slack channel16 and over 100 official contributors to the core framework libraries 17). When assessing the official Apache framework Issue Tracker 18, there are 992 opened bugs related to the core libraries. The issues are rather divers, ranging from broken features after OS updates to UI misbehavior on specific phones. It should be noted that in a considerable number of cases, contributors were not able to replicate reported issues. An important contribution to the ecosystem strength is given by custom plugins developed by individual members of the community. In terms of active and meaningful GitHub resources and know-how, Cordova has the weakest offering between all 5. This is further reflected by the total number of appreciation Stars awarded to Framework7, the highest rated Cordova based framework found on the repository host. This is a bit unexpected considering that it is the oldest cross-platform

15https://angular.io/guide/ajs-quick-reference 16http://slack.cordova.io/ 17https://cordova.apache.org/contribute/ 18https://issues.apache.org/jira/projects/CB/issues/CB-14182?filter=allopenissues Chapter 4. Technology Domain - An analysis of Application Frameworks 62 framework out of all 3. However, Cordova plugins are only used for allowing developers to access device and platform specific features. For UI and application logic modules, developers can use whatever libraries are available for their Web Framework choice. This may be a reason why people are content with the ecosystem resources and consider it powerful enough for what they try to achieve. Furthermore, it also scores a high appreciation when it comes to how lean is the learning curve. Nonetheless, even though JavaScript is the main developing language for hybrids, scoring high in developer appreciation, Cordova, as a framework, is the 2nd most dreaded development approach. It also seems that the general feeling is that the framework is buggy and leads to error-prone code. Developers also complain about the poor performance of applications developed with it. As a general feeling, it seems like Cordova is losing momentum. Considering that Apache Cordova has no central authority in charge with maintaining and developing the framework, the control of the ecosystem is rather dispersed. The ecosystem is rather fragmented, different developers using different web technologies to deliver the content rendered in the WebView container. Furthermore, since there is no major company taking ownership of the framework, individual contributions are driving the ecosystem forward. Furthermore, the contributors have a pooled structure, with low degrees of inter-dependence between specific members. It has little importance who is the developer making the GitHub contribution or reporting a bug, as long as there are enough people doing it. Once someone fixes an issue or makes a new module available, everyone can benefit and integrate that change in their own project. It can be concluded that the ecosystem around Cordova has the highest degree of developer empowerment. The ecosystem key resources are maintained and evolved in a truly democratic way, where each member can shape the co-creation and co-evolution process. The resulting value is also distributed equally among the members. However, this comes at the cost of a less qualitative generated value (framework competences).

4.3.6 Cross-platform - React Native React Native development was started internally by Facebook back in 2013 and was officially open sourced in 2015 19. Since then, the company has dedicated substantial resources in order to maintain and further develop the competences of the framework as it is a significant building block for their mobile digital products. Facebook is in charge with evolving the core components of the framework, while non critical modules are externalized towards the community. Facebook has also recently published a road map for the future of React Native 20, confirming its long term commitment to continue the development. Even though it started as a tool for the social media company, the innovative technology use and the open source licence lead to a massive adoption by young successful companies like Instagram, Tesla, Uber or Skype. Therfore, a considerable amount of value produced in the ecosystem (libraries, code reviews, wikis) is no longer coming from Facebook. In terms of active members, React Native is among the top open source projects on GitHub. To contextualize, the core flutter repository has 394 contributors, Angular has 942. while React Native has 1.963 (31st of May, 2019). It is also the 15th most Stared repository on GitHub, surpassing all other frameworks presented in this paper. Therefore, it can be safely concluded that it is not only that React Native has a large community, but it is also an active one, making meaningful contributions to the ecosystem resources. This is not only proved by the Stars number, but also by the feedback provided by developers surveyed part of the State of JavaScript project. Top five appreciations towards the framework were: that it has a rich package ecosystem, offers an elegant programming style and patterns, it is backed by a great team/company, it offers good documentation and tools. However, even though it makes

19https://facebook.github.io/react-native/ 20https://github.com/facebook/react-native/wiki/Roadmap Chapter 4. Technology Domain - An analysis of Application Frameworks 63 a good impression when it comes to quantitative metrics (number of libraries, number of developers, number of contributions, number of appreciations), there are some complains regarding framework buggines, performance and some missing framework features. Event so, it serves the needs and desires of developers, as over 70% of surveyed developers want to either learn or continue using React Native. When assessing the control over ecosystem key resources and the extent to which members are inter-dependent, a strong similarity with the Native Android structure can be noticed. Similarly to Google, Facebook controls the evolution of the core framework and ensures that it evolves to meet its needs. However, this core framework (SDK) is considerably smaller than Android SDK, including only fundamental application features (e.g. Simple UI elements like Text, TextInput, Slider, WebView or basic platform functionalities like Push Notiﬁcation or Toasts). All other features are maintained and developed by the community. Community can also contribute through pull requests, code reviews a discussion to the development of the core framework. So it can be argued that the ecosystem presents a reasonable degree of resource democratization. Therefore, it can be concluded that React Native ecosystem is a classical platform based structure, with a semi controlled key resource. The control is used to ensure ecosystem survival and it has a positive effect for everyone involved. Members are grouped in a pooled structure and ﬁll the gaps in value creation process. This allows for ecosystem continuous evolution that enables, to some degree, the adoption of innovative features From the Native Ecosystems.

4.3.7 Cross-platform - Flutter Last but not least, Flutter is one of the most recent mobile development frameworks. Released by Google, in may 2017 21, the framework achieved an impressive community recognition. In less than two years of official existance, it surpassed Cordova and Angular respositories, obtaining almost as many Github Stars as React Native did. The ecosystem is rather young, therefore it is not a surprise that Flutter scores low both on project respositories and on GitHub Wikies. Another sign of ecosystem immaturity is the number of opened issues labeled as severe crash22. After filtering the 5823 opened tickets found on GitHub, the search engine returned 432 severe crash issues. Meanwhile, React Native with a larger contributor base, has only 443 total open tickets. Google is also responsible for developing the Dart programming language. Andre Brogon, senior engineer for the Flutter framework, argues that the use of Dart empowers the Flutter ecosystem (Interview 4, AnnexE). Since both projects are developed in-house by Google, framework and language developers have the opportunity to cooperate and align Dart competences with Flutter needs. On example he mentioned during Google I/O Talk on Flutter is the spread operator ... . One of the development challenges in Flutter is to structure UI code. The spread operator was recently released and enables developers to unwrap a collection of UI elements. This unique cooperation makes the ecosystem development more agile and responsive. Google is committed to coordinate the Flutter ecosystem as long as there is there is a development need for it 23. This was also confirmed by Andre Brogon during the interview (AnnexE). The development road map released in 2019 includes a promise to spend time and resources towards plugin and tool development. They also want to ensure compatibility between the framework and other Google services and products. It can be concluded that, similarly to Facebook - React Native case, Google takes ownership over Flutter framework development, but keeps it open source. This strategy leaves the opportunity for the community to contribute and enrich the set of available features improve the general framework

21https://github.com/flutter/flutter/releases 22https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22severe%3A+crash%22 23https://github.com/flutter/flutter/wiki/Roadmap Chapter 4. Technology Domain - An analysis of Application Frameworks 64 quality. However, it is definitely having more power over the key resources in the Ecosystem. It owns the language, it dominates the development activity and it invests resources in spreading knowledge and bringing new members in the ecosystem (e.g. Google I/O talks). This also empowers it to ensure Google services are supported and adopted by other members. Therefore, even though the community has a pool structure around library development, Google adopted a highly controlled platform strategy. This control is also facilitated by the tight integration between Google Product Teams (e.g. Dart Team, Flutter Team, Firebase or Youtube).

4.4 Conclusion

The ﬁrst research question proposed in this work is: “What are the main technology options in order to develop mobile applications?”. This chapter argued that the choice of technology for developing a mobile application is anchored in the Application Framework layer of the mobile ecosystem. In order to identify the relevant Appli- cation Framework categories, the chapter presented an overview of the existing development strategies. Furthermore, the research presented the three main Application Frameworks (Native, Web and Cross-platform). As this Chapter is the founding block for the second research question, the work focused on characterizing the most important Application Frameworks which are currently being used. This characterization was framed using an adapted version of Adomavicius et. al model of technology roles. Part of the characterization process, the work presented a set of relevant statistics concerning the state of the art in each of the chose Application Framework ecosystem. The resulting analysis and classiﬁcation of the frameworks will be further used as a building block in the model described in Section7. 65

Chapter 5

Application Domain Deﬁnition

In Chapter3 mobile applications were defined as all Web and Platform applications accessible from the mobile context (smartphone in this context). These apps take the role of digital channels for mobile services. Moreover, in Section 3.3.7 it was presented that mobile services involve a service provider and a customer. Therefore, it can be observed that applications are a bridge between these two actors. In order to understand how this bridge works, this chapter will try to separate and abstract the business transnational nature of the bridge from the actual use of the application. Therefore, two separate dynamics can be identified and separated: (1) User - Application and (2) Customer - Channel - Service Provider. The former deals specifically with what makes people interact with the applications and how do they react and feel afterwards. This issue will be explored in this chapter. The later discussion deals with the resulting value of the use. More specifically, what is the value offering and how can it be transferred from the Service Provider to the Customer through the channel. That issue will be addressed in Chapter ??, describing the last building block of the research model. It should be stressed that this separation works as a desideratum and not as an absolute criteria. There will be instances where the two perspectives will overlap for a better understanding of the subject (e.g. user experience and user satisfaction). In the same way in which applications have a bridging role between Customers and Service Providers, the Application Domain has a bridging role between Technology Domain and Business Domain. On one hand, a Mobile Application is the result of a development process involving an Application Framework. On the other hand, in the context of this work, the same Mobile Application is meant to be used by business units to deliver value to their customers. Therefore, the application domain needs to present the main application characteristics that are influenced by the elements in the Technology Domain and have impact in the Business Domain. Literature review and exploratory interviews have revealed that the User - Application dynamic is the most relevant approach for understanding how Applications deliver value. Furthermore, substantial evidence was found that the dynamic is influenced by technology competences and characteristics presented in Section4 Therefore, it was decided that the Application Domain will be built based on this relationship. In order to discuss the User - Application dynamic, the chapter has to follow a set of steps: (1) establish a boundary box for the search of dynamic characteristics, (2) come up with a supporting theoretical framework for presenting the dynamic architecture and (3) identify what are the main characteristics of those building blocks. The outcome of this chapter will be the second building block of the main research model. Further on, Section 5.1 will present major findings of the second set of exploratory expert interviews. Section 5.2 will construct a suitable theoretical framework. Lastly, Section 5.3 will apply the theoretical model for the User - Application dynamic in the mobile context. Chapter 5. Application Domain Definition 66

5.1 Exploratory expert interviews

Literature review revealed multiple approaches on how the Application Domain could be described (more details in Section 5.1.3). In order to filter the findings based on industry relevance and to further understand their implications for a real world scenario, it was decided to conduct two exploratory expert interviews. It is worth mentioning that both interviewees are employees (and owners) of Shape A/S, a Digital agency with over 70 employees, offering digital solution development (including Web and Platform applications) and digital business development services. Their portfolio includes over 200 products delivered, over 12 million monthly users, an average of 4.4/5 rating on applications published on App Stores and 36 Awards and recognition prizes (e.g. Best Customer Experience in an Application at Danish Digital Awards 2019 or Special Mention Award in the Web category at the German Design Awards 2019) 1. The first interview was conducted with Co-Founder and Creative Director at Shape A/S, Nicolas Linde. An expert with over 14 years of Application Design. The second Interview was conducted with Philip Bruce, Co-Founder and CTO also at Shape A/S. With 15 years of experience in the Software development industry, he has managed in the past ten years a considerable amount of the Shape mobile products. Furthermore, their management positions in a consultancy with a focus on mobile solutions puts them in a perfect position to describe the the bridge between the Technology Domain and the Business Domain. The interviews covered a broad range of subjects, including but not limited to: what are qualitative mobile applications, mobile application performance assessment, application related ecosystem challenges, application design and development considerations, distribution methods, business-user motivation conflicts and alignment in app related decision making, adoption, future trends. When discussing all these topics, Philip Bruce and Nicolas Linde were unaware of the purpose of the research. At the end of the interviews, each of them was given the opportunity to express an opinion on the topic. These findings are presented in the Web vs Native section. Furthermore, some of the findings were considered to add low value to this domain, but the can be consulted in AnnexC. The next sections presents the main findings from the two interviews. For a detailed description of the discussion the reader can consult AppendixB and AppendixC. The information gathered during the two interviews has been aggregated under a common structure. For each subject of interest, a set of key words have been identified. These concepts will be analyzed in Section 5.1.5 in order to define the domain requirements and expectations. From now on, the work will refer to Philip Bruce as Philip and to Nicolas Linde as Nicolas.

5.1.1 Findings summary Understanding applications [usefulness, context awareness] To begin with, it is important to point out that Nicolas believes that applications are tools to be used by people. He explained that whenever people have a small break from current affairs (like in the bus or in a waiting room), each person has a small list of applications where they pick their choice of use from. A successful application is one that gets shortlisted. He believes that in order to get there, an application needs to have a well deﬁned goal in order to be the best available tool. This leads to the idea of usefulness. In his view, a useful application is always within your reach when needed and always prepared to make your life easier. This implies the existence of sort of context awareness.

Users [context of use, performance expectation, mobile native, expectations] Secondly, the user was a recurring subject in both discussions. Philip, highlights the importance of understanding the user and the context of use for the application. He explains that mobile usage

1https://www.shape.dk/work Chapter 5. Application Domain Definition 67 setting is constrained by time and attention span. Furthermore, Nicolas talks about modern days standards and expectations. In the past, it was enough if applications were just able to fulfill a task. However,the level of applications became so high that the expectations rose a lot. Even so, from his experience, Android users tend to have a higher toleration towards sluggish performing and less fine crafted applications. Furthermore, he generally classifies today’s users as mobile native (they know and are comfortable with using mobile applications). Nicolas pointed out that that the general behavior of users is to use an application a couple of times and then to delete it. Only the best tend to survive.

Adoption [adoption, reviews, persuasion] According to Nicolas, users generally believe they already have all the applications they need. For this reason, applications need be very clear about why they should be adopted. This is achieved through a clear identity. The application can make itself seen if it does one or or two things very well. Nicolas speciﬁcally talks about application adoption. He claims that the the process is easier when the product is (1) as basic as possible and (2) as user friendly as possible. From his experience, Nicolas believes that positive application store reviews are important for the adoption process, but they are hard to achieve. “There is no easy way to get good reviews”. However, well crafted applications tend to satisfy users and obtain them. This is why, in his opinion it is worth developing them.

High quality applications [customized product, user experience, speed, superior experience, excellence, differentiation, investment, bugs, universal application behavior] A central point in both interviews is what high quality applications are and why is their importance. It seems that a core aspect on this topic is the look and feel. On one hand, Philip focuses on application conceptualization in terms of design and user experience. He mentions two main aspects that inﬂuence the quality of an application: (1) the nature of user interface (actual design) and (2) the user experience and how the application ends up being used. These applications usually excel at allowing users to access the features really fast. On the other hand, Nicolas focuses on execution process. He associates high quality applications with superior craftsmanship, emphasizing the execution process. These products require developers to put hard work in details (e.g. typography, layout, transitions) both at the design stage but also at the development stage ("UI/UX work can be as good as the execution"). The result of this hard work is a highly customized product. This product is usually capable of delivering a superior experience to the ﬁnal customer. It is also a mean to differentiate between applications. However, to achieve this types of products (high quality/highly customized products), businesses have to be ready to invest time. A few other quality related characteristics were also mentioned. In his 14 years of experience, Nicolas noticed that high quality are usually becoming valuable for the business. Philip adds that they have few or no bugs and that they are great at adapting to the mobile use context of the user. Last but not least, from his experience, high quality applications have to follow the platform patterns. If the application delivers a universal behavior on both platforms, the experience will feel a bit off. iOS and Android work differently.

Design process [platform differences, Google ecosystem, OS differentiation, user behavior evolution] As Nicolas has an extended experience with mobile design, a core discussion topic during his interview represented the design process and platform differences between Android and iOS. First thing to point out is that“UI/UX work can be as good as the execution is”. Designing and development go hand in hand. When discussing platform differences, it was concluded that meaningful differences exist between iOS and Android. It should be pointed out that both interviewees claimed that independently from each other. Nicolas explained that even though they started to follow some Chapter 5. Application Domain Definition 68 common design patterns, designing for each of them is still considerable different. The biggest difference is how things are already implemented on each platform. If a user needs to switch platforms, he needs to get used with a lot of different OS behavior differences (e.g.: how screens are laid out, how applications are exposed to the user, how widgets are displayed and accessed, how navigation works between screens). In Nicolas’s opinion, its easier to make custom designs on iOS than on An- droid. Android often requires special treatments when implementing the design, his reason being: on Android, the way in which applications are built is a lot more dogmatic (e.g. laying out a set of items should use a ListView and not other elements). Specific attention was give to Google’s way to coordinate the ecosystem. Nicolas explained Google’s desire to ease the building of apps and to facilitate it, it made everything look the same. Con- sequently, the default app behavior and visuals provided don’t feel like being unique and special. If one wants to build a premium Android application, one must build on top of existing user patterns and use characteristics and improve the user experience provided by the platform. However, this may be hard, as he considers Android to be less flexible then iOS. He believes that the Android tries to fit too many devices and purposes and it becomes trickier as phone manufacturers further customize the operating system. This makes it hard to find the golden rules when describing the platform Application behavior. As a result, designers are sometimes left with going for the lowest Android denominator. When it comes to the future of the platforms and design, Nicolas believes that there will always be a need for an individualized OS identity. Google and Apple will use these patterns to differentiate themselves on the market. Considering the existing trends like Zero UI, people will spend less and less time looking at the screens. Unlike before, it will be a fast paced evolution, leading to considerable changes in the job of a designer. This will also bringing with it changes for applications. However, he believes that there will always be a case for user interfaces and screen direct interaction: content consumption.

Device fragmentation [device fragmentation] Both discussions also touched the issue of device fragmentation. When discussing the design process, Nicolas independently pointed out that a “major problem is Device Fragmentation”. From his point of view, this translates in different resolutions, densities, processors. Because of the multitude of devices, he also claims that it is more complex to reﬁne the products on Android then iOS. Philip also claims that “device fragmentation is real and needs to be considered on both platforms”. When describing the issue, he adopts a development perspective, describing the testing process. It is done only on a selection of screen sizes, device models and OS versions based on usage statistics. All things considered, in his experience, device speciﬁc bugs are fairly rare (at Shape). He claims this is because (1) Developers are aware about this issue (at Shape) and (2) (Native) SDKs have become better at scaling on all devices.

Developing process and resources [library, open source, development speed, security, project costs, product evolution, product maintenance, product expand-ability] The interview with Philip covered the topic of using open source libraries. First of all he admitted that there is no universal policy about using them inside the company, adoption decisions being made on a case by case basis. He outlines two risks in using them: (1) you can’t always know what security vulnerabilities they carry and (2)you don’t know for how long they will be supported. He outlines the highly problematic nature of the second. SDK or platform changes can force a library to make fundamental changes from one version to another or even break it. On several occasions, his teams had to deal with deprecated libraries used in production. These events may force a lot of changes in the application code in order to adapt to the new situation. On the other hand, he points out that libraries can deﬁnitely speed the development process. So an evaluation should always be made. Chapter 5. Application Domain Deﬁnition 69

His way of doing it is to ask: “Does the usage of the library justify the savings and the implied risks?”. However, if you want a long-lasting code base, you have to evaluate whether this will be a beneﬁt, or it will actually become a hindrance after a while. Philip was also asked what are the usual cases when applications are being rewritten from scratch. He found 4 cases: (1) The development team boxed themselves in a corner, (2) the development team learned a lot about the product and technology over time, (3) application redesign, (4) Maintainabil- ity reasons (it costs more to continue on the existing code base). He points out that rewriting an application is not unavoidable. A key aspect in application development is keeping the product in a state where it is easy to maintain and simple to expand. Otherwise you are prone of introducing bugs. This becomes problematic if you aim for a high-quality product, as they tend to have no or very few bugs.

Performance evaluation [user perception, visual queues] The last major discussion topic revealed through interview discussions was how is performance evaluated. Philip explains that is should be centered on user perception. In his opinion, there are two types of decisions that inﬂuence it: (1) Design decisions (e.g. the user ﬂow through the application) and (2) Technical decisions (how fast the API data is loaded in the application). In his opinion, raw technical numbers are less important than what user perceives. He says that visual cues make a considerable difference, especially the quality of animations. They are critical in how users will perceive the application.

Comparing the Web and Native approaches [task-technology fit, technology capabilities, lowest common denominator, unique experience, task complexity] Philip makes a strong claim: not all technologies make sense for everything. For example, Nicolas states that the Web approach is great at displaying basic information and native is better at accessing device and OS capacities (GPS, accelerometer, processor, memory, different touch capabilities), capacities that are often harder to hook into from a mobile website. Moreover, Nicolas argues that native applications excel at difficult or complex tasks (ex: ensuring that users stay logged in your service, get push notifications, allow to user to create and move objects around). However, there is a common belief that Native can deliver a better user experience. From a design perspective, Nicolas finds the capabilities of the web rather primitive, often having to adapt the design for the lowest common denominator (“a crude and limited way to do product design”). Furthermore, he talks about how it is required to universalize the experience in order to allow a broad range of devices to access the service. Therefore, designing for web implies optimizing for users who don’t have the latest device and features. This makes it hard to create a unique experience on mobile devices. Faced with the option of Progressive Web Applications (PWA), Philip argued that if they would be good enough at delivering a suitable experience, people wouldn’t switch from web applications to platform applications. He further reiterated that this behavior is due to people having a better experience when using the native applications.

5.1.2 Initial considerations Before moving on to defining the Domain scope, a few considerations concerning issues which have been already highlighted. Firstly, both interviews confirms the fragmentation issues both at OS level and at device level. Secondly, they confirm the existence of meaningful differences between iOS and Android platforms. Thirdly they add a development perspective over the ecosystem. Further platform limitations or hindrances related to design and implementation are presented (e.g. android stock visual components and knowledge body does not encourage product uniqueness and product excellence). Fourthly, a perspective over the future of design and development has been laid out. Chapter 5. Application Domain Definition 70

From this point of view, the ecosystem is looking froward to a faced paced evolution, that will create changes both in terms in how applications features, look and behavior, but also in how these will be implemented. Therefore, applications who want to keep up with the evolution will have to adopt an agile development pace as well. Lastly, the development process is at least as important, if not more important as the design process.

5.1.3 Related research By studying connected literature (research concerned with applications), a set of possible domain approaches has been identified: 1. Focusing on application quality - A large body of research is focused on a better understanding and definition of software quality. In Software Quality - The Elusive Target, B. Kitchenham and L. Pfleeger discuss how various outlooks on quality can impact the metrics used to measure it [79]. The five perspectives on software quality proposed by David Garvin - [54]: (1) transcen- dental view, (2) user view, (3) manufacturing view, (4) product view, (5) value-based view - become a starting point in the discussion on how each should be measured. B. Kitchenham and L.Pfleeger conclude that quality is a complex concept, as “it means different things for different people”. Therefore, there can be no simple universally applicable measure. In their view, when discussing quality, one should always identify the aspects of quality one is interested in. Furthermore, the research body also analyzes the quality in the context of mobile applications. For example, J. Fernandes and A. Ferreira debate upon which are the most relevant attributes of quality concerning the mobile applications. They find that usability, performance, maintainability and support categories are considered to be the most important ones [45]. Noei et. al. focus on user-perceived quality of an app. They hypothesize that it is not only determined by application attributes but also by device attributes. In their study they analyze 150,373 reviews and 20 device attributes (e.g. display size or CPU type) and 13 application attributes (e.g. code size or UI complexity) from 280 application and 30 devices. They find that code size has the strongest impact on user-perceived quality. They also point out that some device attributes (e.g. CPU) sometimes have stronger relationship than app attributes. In order to further understand what could be a suitable approach for a quality oriented exploration of the Application Domain, the issues of quality and performance were also included in the exploratory interviews for the Application Domain (Section 5.1 2. Focusing on the value of mobile application - a considerable effort was put into understanding the relationship between business value proposition and mobile applications. One of the most relevant findings on this topic was Unlocking how start-ups create business value with mobile applications: Development of an App-enabled Business Innovation Cycle. M. Ehrenhard et. al explain how value creation is enabled by mobile applications [39]. The analysis focuses on the types of value outcomes that result from the usage of mobile application in a business environment. The outcome of their work is an “App-enabled business Innovation Cycle model” which includes: four capabilities required for creating business value through applications and eleven types of value that can be enabled by an application. As the concept of business value falls outside the scope of this component, it was decided to not follow this approach when describing the Application Domain. 3. Focusing on the how applications influence the mobile application market - similarly to the previous case, a wide selection of papers deal with describing the mobile application market. For example, in Mobile Application Market: A Developer’s Perspective, A. Holzera and J. Ondrusb analyze how Apple and Google influence the development of mobile applications [67]. Even Chapter 5. Application Domain Definition 71

though this specific discussion has high relevancy for the paper, it was considered that the theory supporting it is not suitable if one wishes to outline specific application framework implications on the Business Domain. Furthermore, this approach would propose a product oriented discussion, violating the separation between user-application and consumer-service dynamics. 4. Focusing on the development process of applications - this was a recurring subject of interest in the academic literature but also in informal resources (blogs and forums) and interviews. The area of mobile development appears to be of high interest within the research community. H. Flora and S. Chande review and analyze prevalent Agile methodologies used in mobile application development [48]. Francese et. al. conducted a two step qualitative study in order to investigate the most important concerns related to application management and development [106]. Similar to the approach this paper has, the first step consisted in a series of exploratory interviews with experienced software managers and developers. It was followed by a survey with software professionals. The result of the survey outlines five findings: (1) most of the app development work is done by junior level developers, (2) companies adopt agile methodologies and cross-platform development frameworks even if there are no approaches and frameworks considered the best, (3) tool and practice support for testing is not adequate, (4) software and hardware fragmentation is a general concern (5) application development is different from web and desktop development. Another research direction is to describe development best practices for each application type (e.g. Best Practices on the Move: Building Web Apps for Mobile Devices mentions the use of HTML5 app cache and deferred JavaScript techniques in order to speed up the page load times [50]). The interviews also covered issues of the development process and also design process. However, this discussion was found to often depend on the internal organizational architecture and use of resources. As the model tries to outline the more generic problems related to the choice of Application Frameworks, it was considered that this approach does not provide sufficient abstraction on the topic. However, as Nicolas explained that development is at least important as design. Therefore, relevant findings will not be dis-considered in the problem domain discussion. 5. Focusing on task-technology fit - in order to understand the importance of mobile applications, a popular approach is to evaluate their suitability for a specific task. Research was found studying particularly Mobile Applications used to facilitate business. J. Gebauer and M. J. Shaw use the concept of Task/Technology Fit (TTF) to evaluate the impacts of mobile technology and task characteristics on application usage inside an organization [55]. They conclude that the most significant factors in their case study were: “screen and keyboard size, setup and log in procedures, and training and support”. Their findings are in line with mobile quality research result (device attributes and support matters), but also evidenced the the user flow design and implementation are important. Another valuable take on TTF theory is the work of Chu Yan and Huang Lihua which addresses mobile application adoption in business environments. They claim that mobile business services and consumer services differ considerably, their corresponding adoption models should also be distinct. Therefore, they present an new adoption model, based on TTF theory, for applications used in a mobile context [29]. This approach is heavily relying on well defined boundary in terms of use context or use purpose. For this reason, it was also considered too hard to create an abstraction layer that would allow identifying problems without setting these in stone. 6. Focusing on user behavior and interaction with the application - this last category is characterized by research around use, use experience, user intention, attitudes, behavior and resulting phenomena like adoption. As this research focuses on describing the dynamic between users. Included in this research approach is the work of Tao Zhou, An empirical examination of users’ post-adoption behaviour of mobile services. He presents a new mobile post-adoption model which Chapter 5. Application Domain Definition 72

includes three blocks: (1) continuance intention, (2) recommendation and (3) complaint. He con- cludes that “expectation conﬁrmation, perceived ease of use, perceived usefulness and usage cost signiﬁcantly affect users’ satisfaction, further determining their post-adoption behaviour” [162]. In Shama et. al. describe user perceptions and application usage patterns [159]. This approach is also used a building block for literature with a wider focus. For example Andrej Balaz explains the impact of visual cues and style consistency on the user learning curve [2]. This approach is a suitable candidate for describing the application domain.

5.1.4 Domain key concepts Through literature and interviews a set of key concepts were identiﬁed as being important when referring to applications. They shall be further explored using a suitable theoretical framework. Considering all the information acquired, the central concept for this Domain should be the use of applications. • Use • Context of use • User Experience • User perception • User behavior • Application adoption • Application Quality

5.1.5 Domain analysis expectations and requirements The role of the Application Domain is to: (1) better understand how the choice of application framework impacts a mobile serviceand (2) provide a structure and analysis support to the problem space. Therefore, similarly to the Technology Domain, a suitable model has to be identified to present the findings. This model should present at least two types of building blocks: (1) components affected by the choice of application frameworks and (2) components influencing the value proposition (?). When considering existing theoretical frameworks and the domain key concepts it was found that an analysis concerning the adoption process should incorporate all the necessary explanations to understand how the two other domains are linked. More specifically, this analysis should include the acceptance of mobile application and what makes user continue using them. As a result, two domain related research questions are further developed: 1. What makes people use a mobile application? - This question primarily focuses more the acceptance of the application. 2. How do people use mobile applications? - This question primarily focuses on user behavior 3. What makes people continue using mobile applications - This question primarily focuses on the intention to continue using the application.

5.2 Application Domain analysis framework development

Section 2.6.2 presented some of the existing frameworks related to technology acceptance and intention of use. None of the research found during literature review is extensive enough to bridge the Technology Domain and the Business Domain. Therefore, two major theoretical frameworks will be adapted and composed in order to describe the Application Domain. Chapter 5. Application Domain Deﬁnition 73

5.2.1 UTAUT adaptation Firstly, the Unified Theory of Acceptance and Use of Technology (UTAUT) is chosen to frame the discussion around the first and the second domain questions (acceptance and behavior). The research will assume only external variables with a root in the Technology Domain. Therefore, its concise concise nature is preferred over other richer TAM models, as the analysis revealed only a limited number of relevant external variables. Venkatesh, Morris, Davis and Davis define performance expectancy as an aggregation of five related aspects: “perceived usefulness, extrinsic motivation, job-fit, relative advantage and outcome expectations”. However, this research doesn’t find all of the to be relevant constructors for performance expectancy. First of all, no proof has been found for application frameworks influencing the extrinsic motivation of users. Furthermore, Venkatesh et. al. recognize the close similarity between job-fit and perceived usefulness. That and the fact that it would require a specific task for a proper analysis make it redundant. Relative advantage is defined as “The degree to which using as being better than using its precursor”. On the other hand, the work will consider Perceived Enjoyment as a determinant for Behavioral Intention to Use a mobile application. As Thong et. al. argue that for an application oriented to improve a task performance in an organization, perceived usefulness is a critical determinant [141]. However, when applications incorporate a hedonic purpose, they are impacted by perceived enjoyment. It should be remembered that not only pure games have a hedonic purpose. For example, a streaming application (e.g. YouTube) should also aim to create a pleasurable experience, not only to offer access to information. Considering that Performance Expectancy, Effory Expectancy and Per- ceived Enjoyment are all anchored in user perception, all the information related to them is grouped and labeled Perception based information. Gender, age and voluntariness moderators will not be included in the model. The work does not assume a user profile or has any relevant data about these aspects. According to the international standard on ergonomics of human system interaction, user experience is "a person’s perceptions and responses that result from the use or anticipated use of a product, system or service" [41]. As many researchers point out (e.g. [99], [143]), the experience is the result of interaction. As use behavior in the context of using a mobile application in order to access a mobile service requires interaction between application and user, user experience can be perceived as result of use behavior. It should be noted that this concept of user experience is different then the one proposed in the UTAUT model. In the first case, user experience is a phenomena bounded by the context of interaction, during the time when it happens. In the later case, experience is seen as a body of knowledge that affects the user’s perception of the system. However, research shows that both concepts have common set of constructors (perceived usefulness, perception of use and perceived enjoyment). Therefore, to minimize the framework components, the two types of experience will be merged. It will be assumed that user’s interaction with a mobile application creates a unique user experience for that instance. This unique user interaction contributes to the larger experience the user has accumulated in using the application. Therefore, this new component is appears as a consequence of use behavior and further influences the perception based attributes [20]. The resulting version of the UTAUT framework is depicted in Figure 5.1 Chapter 5. Application Domain Definition 74

FIGURE 5.1: Adapted version of UTAUT

The modified version of UTAUT sets up the bases for analyzing the Application Domain through the perspective of the Technology Domain. However, the analysis framework also needs to bridge the user-application dynamic with the Customer - Channel - Service Provider dynamic. Hence the use of IS Continuance Model. This part of the final model will be used to address the third domain question, What makes people continue using mobile applications?. When presenting the IS Continuation Model, Anol Bhattacherjee clearly distinguishes between pre and post-acceptance stages. Prior to him, research would consider the later the point when “transcends conscious behavior and becomes part of normal routine activity”. However A. Bhat- tacherjee pointed out that this approach is insufficient if uses the pre-acceptance variables to explain post-acceptance stages. Therefore, he proposed the IS Continuation model in order to show the mechanism that makes users re-use the IS system. The research reviewed sees adoption as a process and acceptance as an attitude towards the system. The later is a pre-requisite for the former. For the purpose of this research, the adoption is seen as a continuous process that includes a pre-acceptance component (modeled by UTAUT) and post-acceptance component(modeled by IS Continuation Model). The final construct is depicted in Figure 5.2. Anol Bhattacherjee explains that the continuance model follows an “an initial acceptance decision”. He also states that the decision modeled (Should the user continue using the mobile application?) is influenced by the initial user experience. Last important consideration regarding his work is the differentiation between pre-use and post-use variables. He explains that on a use instance, people have some predefined expectations which are put against the actual experience. Based on how this evaluation the existing set of perceptions are updated. It should be noted that even though A. Bhattacherjee claims that Perceived usefulness is the only determinant affected in a meaningful way, J. Thonga, Se-Joon Hongb, and K, Y. Tama found that that Easy of Use and Enjoyment are also changed in this process [141]. Furthermore, this updated (post-acceptance) perception based information together with the confirmation assessment influence the user satisfaction over the IS. In the end, user satisfaction with system use and the perception based information can be used as predictors for future IS intention of use. Chapter 5. Application Domain Definition 75

FIGURE 5.2: Final Application Domain model

Before concluding the section, five model considerations should be mentioned. The first one concerns the use of arrows between blocks. The model does not indent to show all the relations between elements. Instead, it aims to show the relational graph, focusing on the links relevant for the mobile application context. The second issue concerns the relevance of the relations. This work developed a new theoretical framework for analyzing adoption. However, it is out of the scope of this research project to evaluate the strength of these relations. Further studies should be done to asses the robustness of each prediction. The following two considerations are related to the interpretation of the theoretical foundation. Literature review outlined multiple perspectives over how adoption, acceptance and and use continuation concepts are related. This work decides to perceive the adoption of a mobile application as a finite process that can span over a period of use time and use instances. Nicolas talks about how phone users tend to define a shortlist of applications and that is where most of their use decisions lie. He says that a successful application is one that gets shortlisted on people’s phones. The work will consider the adoption process completed for an individual when the application gets shortlisted. The theoretical explanation of this shortlisted process can be grounded in A. Bhattacherjee description of IS transcendence from conscious behavior decision making to a routine activity. Acceptance is also Chapter 5. Application Domain Definition 76 seen as a process that models the attitude of a person towards using the mobile application. Since acceptance is a pre-requisite for adoption, the work will see them existing in parallel in relation to usage. A person develops a positive attitude towards using a mobile application. This development is part of the adoption process and this results, at some point in the usage time-line, in shortlisting the application. At this point in time the both processes are considered completed for the purpose of this work.

FIGURE 5.3: Acceptance - Adoption - Continuation - Use relationship diagram

Once the first use is achieved, a new issue arises. Will the person continue using it? As was previously pointed out, the acceptance attitude is not enough to describe this issue. Therefore, for some period, building the acceptance attitude and making continuation decisions will exist in parallel. For the purpose of this work, both models use a common set of constructors. This allows the two constructs to be connected. However, it should be noted that not all applications get to be adopted, that the acceptance process may continue for an indefinite period of time and that the continuation process can result in abandoning the application. Last but not least, TAM has been initially created to answer organizational internal technology adoption challenges. In the context of this work, it will be used to describe the technology acceptance of mobile applications without the organizational constraints. This shift requires a minor reinterpre- tation of Venkatesh et. al. work. Since they talk about organizations, when they refer to performance expectancy and facilitating conditions, they refer to the context of a job place. For example, some of the items proposed to measure performance expectancy are “I would find the system useful in my job.” or “If I use the system, I will increase my chances of getting a raise.”. In the context of this work, the use will abstract way from the organizational related terms activity and environment. Therefore, these questions would for example become I would find the system useful in my activity. or “If I use the system, I will increase my chances of getting some extra benefits”. However, the research is not a pioneer in this area. Other research projects studying mobile applications and services have done it before [115, 108]. For example, Alzubi, Mohammad and Mustafa Al-Dubai took a similar approach to TAM theory to understand the behavior intention of Jordanian citizens to use m-Marketing. The success of their studies offers a strong motivation to pursue this approach.

5.3 Application Domain analysis

This last section will present a brief characterization of mobile applications and mobile users, as they will be the target of the use action. Later on, based on the framework presented in Figure 5.2, Chapter 5. Application Domain Deﬁnition 77 the work will outline the speciﬁcs of the pre-acceptance and post-acceptance when interacting with mobile applications. Each UTAUT block will be described guided by the estimation items proposed by Venkatesh et. al. [148].

5.3.1 Who are the App and the User? As was previously defined, mobile applications incorporate both Mobile Platform Applications and Mobile Web Applications. Section 3.3.4 highlighted different types of classifying applications. Rel- evant for this chapter is to further differentiate between hedonic apps and utilitarian apps. This categorization looks at the purpose of use [89]. On one hand, utilitarian apps are considered to be task-oriented, rational and mostly for a work or chore related role (e.g. MobilPay Business solutions application). On the other hand, hedonic apps are more used for activities associated with “fun and playfulness” [122] (e.g. Spotify). However, a considerable amount of applications partially fall in both categories (e.g. Nordisk Film Application). When it comes to users, one could use multiple segmentation criteria to differentiate between them (e.g. age, gender, country of origin, education levels, income). As UTAUT Model points out, some of these user characteristics can moderate behavior but also can lead to specific characteristics in the context of use (e.g. Internet QoS parameters). Moreover, as smartphone ownership increases, the growth is uneven between economies[135]. Therefore, they can also influence the device type used to access the application (feature phone or smartphone). One segmentation research studies tend to make is based on the use context and motivation: business purpose (enterprise use) or personal purpose (consumer use) [50]. According to a recent study [50], consumer applications require more focus on User Experience (U.X) design, visual representa- tions, user ability and the general look-and-feel. This was partially confirmed during the exploratory interview with K. Friis. However, he pointed out that this was more the approach of the past. Appli- cations used for a business purpose, even though they may differ in motivation, they are still accessed by ordinary people. Therefore the design and user experience are still playing an active role in the acceptance and continuance processes. User evaluation of the application may also be influenced by past experiences in other applications. Last but not least, Nicolas characterized today’s users to be mobile native (experienced in mobile phone usage). This in turn makes users more capable of making critical use assessments and having higher expectations from applications.

5.3.2 Mobile application finding As was pointed out by C. Risom, the search process differs between Web Applications and Platform Applications. In the case of Web Application it is mainly centered around web search engines and link sharing. On the other hand, Platform Applications are distributed through App Stores. There- fore, users must somehow land on the app store entry for that specific application. Through a survey of over 10000 mobile users, Lim et. al. discovered that: the majority of people (43%) found their applications using keyword search in an app store. They were followed by people browsing randomly (43%!) and by people who used a Web search engine (e.g. Google). 35% of the people reported that they sometimes look at the mostly downloaded applications chart in the store [85]. A small percentage of people (1%0) go for the first application they find. This means that people put effort into choosing their applications, even if there is no financial cost associated. Chapter 5. Application Domain Definition 78

5.3.3 Perception based information Numerous literature findings emphasize the importance of user perception in mobile context. User enjoyment, performance enhancement (through saved time or improved personal comfort) and ease- of-use, are considered to be indispensable for a correct evaluation of a mobile application [59]. This research will adopt the belief that perception and later on usage are determined by technology robustness associated with the design [62] and development work. Some specific research work has been conducted in order to find whether the use of hybrid development frameworks can influence one’s perception of a platform application by measuring App Store reviews [87,9]. Results were mixed. One thing that can be concluded was that Hybrid applications have the potential to obtain similar ratings as Native developed applications. In order to understand how technology robustness can impact application usage, the following three sections will describe what is the relevant information perceived by users.

Performance Expectancy (Perceived usefulness) . . . when we did not have any of these technologies. Doing any kind of job was really hard back then. I can tell you that the cell phone really is a tremendous safety and access device. - Elder woman about the times before the smartphone [75] Venkatesh et al. present 4 items which can be used to evaluate user’s performance expectancy. They are related to: (1) how useful is a mobile application for a specific activity, (2) whether it speeds the completion of the task, (3) allows more productivity or (4) leads to some meaningful benefits after its use. Following a large international focus group, S. Jarvenpaa and K. Lang concluded that that mobile applications can be used for (1) Communication, (2) Coordination, (3) Efficacy, (4) Coordina- tion, (5) Mobility and (6) Sociability. One common issue affecting all these activities is that application does not work as expected. According to a report from 2016 [8], 62% of the people surveyed reported at least a crash, freeze or error, 47% encountered prolonged loading times and 40% had at least one platform application that would not even turn on. All these malfunctioning scenarios of an application contribute negatively to the performance expectancy. This is extremely problematic especially considering user expectation and patience. For example, approximately 81% of Millennial smartphone users report that if the platform or web app feels "buggy, slow or prone to crashes" during shopping activity, they would change the service. The same if the application fails to load in less than 3 seconds. In many cases, this is because they expect the same loading time from a mobile application as from a desktop one [118]. Therefore, it can be concluded that some of the major performance expectancy determinants are application loading speed and correct app behavior. Research further shows users evaluating the usefulness of an application care a lot about app inventiveness an customization [13]. A key take on customization is being able to understand and adapt to the context of use. User characteristics, device and environmental conditions can all be transformed in facilitating conditions for the use of the application. For example, a user opening the bike sharing application Donkey Republic from inside a building probably has a different motivation and need than one that has already rented a bike and stays at a parking location. As B. Philip pointed out during the interview, a successful application needs to understand the user and the context of use. This will allow it to be perceived as being more useful.

Effort Expectancy (Perceived Ease-of-Use) “A user interface is like a joke. If you have to explain it, it’s not that good” — Martin Leblanc Chapter 5. Application Domain Deﬁnition 79

To begin with, both interviews and literature review linked mobile application perceived ease-of- Use with the degree to which it follows the platform design rules (e.g. tabs placement, the use of a floating action button, navigation). One of the biggest challenge mobile applications have to overcome is to deliver the best compatible UI/UX for each platform [50]. Both Nicolas and Philip focus on user perception as a key measure of platform differences. It has been found that one of the most influential determinants on user perception in the mobile context is the information architecture - the system used to arrange the content and features of the app (e.g. includes how navigation, search and labelling of data is made) [159]. In A Case Study on Cross-Platform Development Frameworks for Mobile Applications and UX, E. Angulo and X. Ferre further enforce the claim that platform-application design alignment influences user perception. They measured user perception of the same application concept, implemented twice: using a Native and a Hybrid framework. The difference in perception was so significant, that 86% iOS users formed a higher intention to use for the Native version than for the Hybrid one [a_case_Study_on_cross_platform_development_frameworks_for_mobile_applications_and_UX_angulo]. This brings the discussion to a second point, differences in perception for iOS users and Android users. As Nicolas pointed out, it seems that Android users are more lenient in interpreting platform conventions. One reason for this would be the monopoly Apple has on the design process for the iPhone and iOS. This leads to a more uniform design across all devices that creates a stronger design based switching cost for the user. As smartphones and operating platforms are rather complex pieces of technology, the user learning process is not that short and straightforward forward. This reflects in how users perceive the platform as well. Nicolas mentioned that: “A user coming from Android to iOS will feel claustrophobic because of the platform design”. Therefore, there is an increase in the required user effort whenever an application doesn’t follow the platform changes, especially on iOS. One of the interviews conducted during Google I/O 2019 focused on accessibility (AnnexE). Dur- ing the interview it was reveled that people with accessibility issues (e.g. visually impaired, death) have different navigation and engagement patterns than the default users. Moreover, oftentimes if you tackle the issues faced by one user category you partially solve the problems encountered by other categories as well. This happens because the issues overlap. Therefore, the perception of Ease- of-Use for this category is strongly influenced by how applications manage to provide interaction and use enhancements for their needs. Last but not least, N. Basoglu et. al. conclude in their study that adaptability and completeness are important for users who look for Ease-of-Use characteristics in mobile applications. They show that fine-tuning the application features to match the needs of different type of users generates better result [13].

Perceived Enjoyment According to the emerging trends in mobile application market, user engagement is also inﬂuenced by enjoyment [159]. As was previously mentioned, users tend to choose applications for different purposes and use a various criteria to form their use attitude. This is determinant is especially powerful when addressing youngsters [159]. For this purpose an intuitive and entertaining user interface could be used.

5.3.4 Social Influence Social influence especially impacts platform applications, as they are often published on a publicly available market place. As Nicolas pointed out in the interview, the reviews (stars and comments) are capable of influencing users expectations and use decisions. This was further confirmed by a study looking into what affects paid application adoption decision. It found that 84% of the users claim that the application score greatly influences their adoption decision. Furthermore, there a general Chapter 5. Application Domain Definition 80 attitude around millennial smartphone/tablet users is to support platform applications rather than websites [43]. However, it was not found whether this actually influences the attitude of new users.

5.3.5 Facilitating Conditions The key idea behind Venketesh et. al. inclusion of these issues in the discussion is that their existence supports the use of the system. Therefore, facilitating conditions will be defined as user related context factors that can influence their motivation, goals and usage patterns [75]. Therefore, in order to form a positive attitude the user needs to have all the resources and knowledge to use the technology [89]. However, these conditions aren’t always facilitating the use. Sometimes the lack of resources or improper context can hinder the application use. The discussion around facilitating conditions for mobile applications revolves around: the existing knowledge regarding the app use, how compatible is the application with the rest of the system (platform itself and other applications), use environment, network and device qualities. During the interview addressing accessibility issues, two distinctive categories have been identified: permanent disability (discussed in the Ease-of-Use section) and situational disability. The later refers to a temporary disability of the user to engage in normal conditions with the application. This can either be related to the user’s condition (e.g. has suffered an eye surgery) or due to environmental conditions (e.g. powerful sunlight that blocks the screen use or loud noises). This affects the quality of use of the application (Interview in AnnexE. According to Google, there are over 1 billion users that deal with accessibility issues (permanent and situational). Environment does not only have effects on the user. It can also affect the connection to the internet [93] and device qualities. As was pointed out in the Ecosystem Analysis (Section 3.4), not all users have access to the same internet technology and speeds. Furthermore, it was pointed out that devices themselves can serve as a use bottleneck. Performance of mobile applications can be considerably affected by network quality, OS speed, signal strength or device type [37]. This in turn can further impact the Ease-of-Use, usefulness and how the actual use behavior evolves (e.g. some phones slow down or even shut down during cold whether 2). Therefore, even though they cannot control them, applications have to cope with these challenges in order to generate a positive use behavior. Lastly, according to Philip Bruce, the today’s users are constrained in terms of available time and attention span capacity. This can further influence their use behaviors.

5.3.6 Behavioral Intention of Use To sum up, until now the work has discussed what is the relevant information that users consider when developing their use intention towards a mobile application. Furthermore, the section discussed how they actually perceive this information. Before describing the usage of application, it must be pointed out that platform applications require an extra step before the actual usage: installing and downloading. On the other hand, Pro- gressive Web Applications allow users to access the application features and content without forcing them go install it. This action can be postponed for a later moment in the use journey. This step is extremely important however, especially for the initial use. If an application fails to download or install it can mean a (failed) end of the adoption process. According to existing research [85], this step can fail for other reasons than performance, effort and enjoyment related perceptions. Features unrelated to functionality and usability like application name or application icon can stop this process. Furthermore, there is also a different attitude towards installing applications between iOS and Android users [97].

2http://time.com/5084043/cold-weat(her-protect-phone/ Chapter 5. Application Domain Deﬁnition 81

5.3.7 Actual Use Behavior The actual use of an application can vary a lot from one app instance to another. This is due to different use purpose, requirements and motivation. For example, it is expected that the use of a alarm app to have utilitarian purpose and short use interaction instances. On the other hand, a video streaming application (e.g. YouTube) may have a stronger hedonic purpose and longer usage instances. The in app behaviors differs as well, based on the purpose and features of the application. However, the following discussion will try to incorporate considerations related to the general mobile applications use, differentiating, when it is possible, between web and the platform applications. First aspect relates to time spent in mobile applications. A considerable time of one’s day is spent on mobile devices. According to a study from 2016 3, US mobile users spend on average 51 minutes on the web, while platform applications take 3 hours and 25 minutes of their day (Figure 5.4). Nevertheless, it should be kept in mind that these is only internet based usage. A considerable amount of platform applications do not require internet to be used. Therefore, the difference may be even bigger. Furthermore, it seems that Web use is unmodiﬁed, while application usage is on an ascending curve.

FIGURE 5.4: Average time spent on mobile internet (Source: )

Note*: “The study included people aged 18+. The time spent with each device includes all time spent with that device, regardless of multitasking. For example, 1 hour of multitasking on multiple apps while on a mobile website is counted as 1 hour for in-app and 1 hour for mobile web. The use only took in consideration smartphone and tablet based use instances”. When it comes to behavior tendencies, C. Tossell. et. al. split mobile users across a spectrum with two endings: Pioneers and Native [10]. Pioneers are characterized by a tendency to explore the web on the browser, while Natives avoid it, focusing mainly on accessing platform applications. The later group tends to use the browser exclusively for quick searches. The behavior of Pioneers results longer sequences of URL accesses, more diverse content encountered, more searches within every session and higher rates of revisiting the Web Applications. One conclusions they draw based

3https://www.emarketer.com/corporate/coverage/be-prepared-mobile Chapter 5. Application Domain Definition 82 on their finding is that Pioneers tend to settle on a fewer number of applications than Natives, but to use more of the browsing resources for anything else. This settle is equivalent with the shortlisting concept proposed by Nicolas. However, he does not distinguish between these two types of users. Therefore, it can be concluded that this shortlist size differs based on the type of users. This also means that in the case of pioneers the adoption process of a platform application has lower chances of success, while a Web application has higher chances of success. Statistics allows for a further particularization of platform application use. First of all, the average number of platform applications accessed in a month by a mobile user is on the rise. If in 2014 an US person would use on average 27 applications in a month 4, in 2017 that number went up to 40 5. However, when time is taken in consideration, the concept of a limited shortlist is once again validated. 50% of their time is generally dedicated to the use of the top application on their phone and 88% of the time goes to Top 5 6. Lastly, Nicolas pointed out a difference between iOS and Android behavior. According to him, more use activity happens on the iPhone. However, this finding may be limited to the use behaviour in Denmark. Even so, the main take away is that use behavior may differ based on platform and country.

5.3.8 User Experience (U.X.) If a particular [use context] combination doesn’t exist today, it very well could tomorrow. - Andre Charland and Brian LeRoux [27] When a user embarks on a use journey in a mobile application, the discussion of user experience can be brought up. It reflects the overall experience generated throughout the use process. L. Nicolas and P. Bruce and literature review [159] pointed out that user experience vital for ensuring a successful adoption process of a a mobile application. They all also emphasized that the only way to achieve it is to have a user centred approach during the development process. Part of a qualitative study, R. Francese et. al. point out that mobile users are considerably different from those of desktop applications (e.g. they have access to other types of hardware, screen). They also outlined ] different user expectations for web and platform applications: [web and platform] apps need an experience “in motion”, immediate, fast, in every place, uncomfortable, so giving the user new opportunities for interaction... [platform] Apps are characterized by more interactions with other components on the device: GPS, WiFi, Bluetooth, Accelerometer, and touch-based. Moreover, the mobile user requires that the most significant information has to be immediately available and that each feature has to be implemented in less than 3 steps. [50] In order to address these, it is important to understand what created the user experience in the mobile application context. UX can be divided in two: context-elements (e.g. hardware affornaces, platform conventions and capabilities and the use environment) and implementation elements (performance, design or platform integration) []. The former cannot be changed, but as was explained in under the Facilitating Conditions and Ease-of-Use components (Section 5.3.5) they are important to be understood and to be taken in consideration in order to ensure optimal use. They can create user expectations and influence the final experience. Failing to fulfill the expectations could contribute to the discontinuation of use. However, this creates a huge challenge for developers. When addressing the user context, it was observed that there are multiple dimensions to be considered (hardware attributes, platform, environment, time and so on). The combination of these external-context elements

4https://www.nielsen.com/us/en/insights/news/2014/smartphones-so-many-apps–so-much-time.html 5https://www.appannie.com/en/insights/market-data/apps-used-2017/ 6https://www.comscore.com/Insights/Blog/How-the-Power-of-Habit-Drives-Mobile-App-Usage Chapter 5. Application Domain Definition 83 can influence how the application will appear and what are the available affordances [27]. Therefore the general fragmentation problem previously presented in the Mobile Ecosystem Considerations (Sec- tion 3.4) is further amplified by the multitude of uncontrollable use contexts. In order to obtain a positive user experience, existing guidelines emphasize the need for style consistency in the application and with the platform conventions [2]. Style alignment contributes to the actual user enjoyment through aesthetically appeal, improved usability and can help reducing the learning curve of users. If today’s design is focused more on the visual elements encapsulated in an application, Nicolas talked about the future trends like Zero UI. As more and more device and platform features will allow it, designers will be able to create a voice centred experience. Lastly, one should be aware that user experience does not exist solely when the user is the Mobile Application. Applications have the possibility to use platform features like Push Notifications (e.g. to remember a mobile owner that a new email arrived), Intents (for communicating between apps, e.g. share a link to a Chatting app) or Slices (display rich, dynamic, and interactive content in the Google Search Application). C. Risom pointed out that especially Platform Applications have to “be able to reactivate themselves”. This means making sure the user is aware of their existence and utility even after the first use. To conclude, it can be observed how perceived aspects and contextual conditions are also involved in the user experience component. Therefore, it is not only enough to create expediencies regarding what the application can do and feel, but also deliver them. Otherwise, app continuance may be endangered. Furthermore, after every use instance people acquire use experience but also update their expectations. Therefore, in the case of mobile applications, creating UX has to be considered both a short term investment (to ensure rapid acceptance) but also a long term investment to ensure continuation.

5.3.9 Confirmation A well-though mobile solution has to confirm the user expectations through the user experience. This translates into aligning app content and functionality with the users needs. Based on the confirmation, good or bad opinions may be shared by the user (e.g. AppStore reviews and Stars). B. Fling emphasizes that users share especially bad experiences in their network [47].

5.3.10 Satisfaction Based on whether the application usage has lead to a positive confirmation or not, the user ca end up being satisfied or dissatisfied with the mobile application. One critical phenomena resulting from poor user experience is technology frustration - “the emotional response of a negative computing experience with the technology” [19]. In this context, it occurs when a user encounters an issue when trying to use a mobile application and it fails to deliver the expected outcomes. The main issues for this to happen is crashing, poor internet connection quality, confusing or inexpressive design [62]. It often leads to loss of efficacy or diminish usefulness, therefore, reducing user’s satisfaction. In some cases it can also lead to user anxiety or even anger [32]. Therefore, it not only negatively affects user’s satisfaction over the application, but also the willingness of the user to complain about it across existing communication channels .

5.3.11 Mobile Application Continuation Intention Last but not least, the continuation intention will inﬂuence whether the user will want to come back and use the application or not. The decision making process can differ based on country or even person. However, one common factor worldwide is that bad quality application (e.g. poor performance, Chapter 5. Application Domain Deﬁnition 84 crashes, counter-intuitive use, with crashes) is very likely to face use abandonment [85].

5.4 Conclusion

Chapter5 has focused on exploring the user-application dynamic and outlined the most important concepts in the Application Domain. In order to identify what should be the domain scope and analysis objectives, a set of exploratory interviews were conducted. Based on these interviews and an extended literature review, the chapter proposed a set of key concepts for describing the user- application dynamic and 3 guiding questions for the domain analysis. Central for this discussion was the concept of use and how does it manifest for mobile applications. In order to frame the knowledge, the research proposed an analysis framework derived from UTAUT and IS Continuation. This model was adapted to match the mobile context. Finally, based on the proposed framework, the chapter discussed the main considerations related to mobile application acceptance, adoption and continuation. All these will further serve for identifying what elements in the Customer-Channel- Service Provider dynamic are being affected by the choice of Application framework. 85

Chapter 6

Mobile Applications - Deﬁning the problem space

Chapter4 and Chapter5 presented the main relevant considerations related to technology competences and mobile application use characteristics. The work of this Chapter will build towards the Customer - Channel - Service provider dynamic. Firstly, it will focus on the channel identifying the main problems stemming from the technology choice. Secondly, it will focus on the Customer - Channel dynamic, in order to deﬁne the user related issues caused by the technology choice. Lastly, Section 6.3 will identify the major areas of possible change related to the mobile service.

6.1 Technology related problem space

Firstly, this section will focus on the root of the problems, the Technology Domain. The ﬁndings of this section will be later used to explain issues present in the other Domains.

6.1.1 Framework ecosystem structure and maturity Based on the analysis provided in Section 4.3, one can define a set of possible ecosystem problems anchored in its structure and maturity. These issues include: • How large and accessible is the resources body (libraries, community, knowledge)? Applica- tion Frameworks are as powerful as their resources allow them to be. Developer community, libraries or knowledge are just some of the enablers of mobile application development. As was observed in the Technology Domain discussion, different Application Frameworks ecosystem have a different resource layout. It has been noticed that this issue is further influenced by how ecosystems are interconnected. For example, in the case of Web Technologies, even though they use the same Technology at base, the fragmentation and inter-operability issue stop developers from sharing framework specific libraries. This can hinder the development of the community and the development process. At the other extreme there are ecosystems like the Hybrid based Cordova, which have more capacity to share these resources. • How qualitative is the resource body? It is not enough to have access to resources, but in order to speed the development and minimize product risks, these resources have to be well established. Quality of the resource system defines both the number of features which can be supported by the Application Framework, but also how strong is that support (e.g. manifested bugs, supported devices and platforms, crashes). As it was discussed in the Technology Do- main, different ecosystems face different degrees of resource quality. Community is involved different in its development (e.g. degree of framework contributions, degree of discussion involvement on public forums). Quality of the existing libraries can also differ. Section 4.3 showed Chapter 6. Mobile Applications - Defining the problem space 86

that the stability of the libraries can vary considerably (Native and React Native rather strong and Cordova rather weak). • How compatible is the framework ecosystem with the rest of the ecosystem? An important reason for low quality libraries and unequal feature support represents the platform integration architecture and how well is it supported. The more bridges exist between the user facing component and the device, the more challenges the framework has to overcome. For example, for a feature to be implemented using Web technologies it needs to have all the Application Frame- work - Browser engine - Platform - (optionally) Device layers properly integrated. In the case of Hybrids, the alignment is even deeper: Web Technology Framework - Browser engine - Hybrid Application Framework - Platform - (Optionally) Device. Compared with Cross-Compiled or Native frameworks, this chain is considerably longer. • How predictable is the evolution of the application framework ecosystem? Research has tried to predict the popularity of cross-platform application frameworks. After conducting a qualitative investigation, R. Francese et. al. claimed: “On the basis of the responses to Q7.15, PhoneGap will be the development framework that will be largely used in the next 5 years”. However, 4 years later it seems that React Native is ahead by far. C. Risom talked during the exploratory interview about unpredictability of cross-platform frameworks. Looking back at how community interest evolved across time (Figure 6.1), this hypothesis can be partially conﬁrmed. Most of the frameworks had a spike of popularity at some point in time and then it decreased. The only exceptions are the more modern Flutter and React Native. However, this is not the case for the Native frameworks that have been in use since the beginning of iOS and Android. Furthermore, as cross-platform development also relies on the platform APIs in order to exist, it is expected that the Native frameworks will exist as long the platforms exist.

FIGURE 6.1: Comparative App. Framework interest evolution (Created with Stack Overﬂow Trends Insight tool)

Interviews revealed that the developer community has a tendency to follow trends and new Chapter 6. Mobile Applications - Deﬁning the problem space 87

technology. It could be argued that the Framework ecosystem fragmentation (e.g. Cordova) and the poor performance output of older frameworks has driven the community away. One change on that matter are the new Application Frameworks (e.g. React Native, NativeScript or Flutter). They seem to have considerably higher traction then the previous ones. This may be because the entry barriers in these communities is lower then before (Flutter development is similar to Android and ReactNative and NativeScript leverage existing JavaScript knowledge). It may also be because of the new architectural approaches (e.g. Flutter’s UI rendering mechanism) that allow for improved performance and better User Experience. Last but not least, the evolution is strongly related to the control type of the ecosystem. As was presented in the Technology Domain Analysis (Section 4.3), different application frameworks have different entities (e.g. Google, Apple, developer community, Facebook, etc.) controlling key resources. These entities have different motivations that on the long run will guide their decisions regarding how they support the ecosystem. Furthermore, it is important to highlight the impact of communities on open source frameworks. On one hand, it seems that they are capable of maintaining older frameworks to the degree to which they are used for developing new applications. On the other hand, it can be observed they are not capable to achieving a qualitative job (e.g. PhoneGap, Cordova, Framework7) all by themselves. By qualitative job, the work refers to ensuring they are compatible with the latest platform updates, device features and general resource quality. As was previously mentioned, this attitude, on the long run, can lead to a general disinterest in the Application Framework. However, when a large organization takes ownership on the development of the Application Framework and community is allowed to contribute, the effects are considerably more positive. Therefore, even though Na- tive ecosystems are currently richer in terms of existing resources, companies like Facebook or Google can ensure that the community effort leads to a more qualitative resource body. • Third party dependency Section 4.3.4 and Section 4.1.5 showed that the development using Web Application Frameworks and some of the Cross-Platform Frameworks requires the use of third party resources. These Frameworks enable the development of the core functions of an applications. However, in order to customize an application, developers have to access other features like (platform, device APIs, custom animation behavior). This approach speeds up the development. Moreover, based on application complexity it can lead to lower development costs for the application. Nevertheless, third party dependencies bring a series of risks and issues for the company developing mobile application: – According to Philip Bruce, it creates a code liability and a possible security risk. – Also according to P. Bruce, it creates an application feature dependent on that library. Fur- thermore, this is especially important as both interviews and literature review [86] revealed that libraries are vulnerable to maintenance interruption. P. Bruce even mentioned cases where the application suffered signiﬁcant changes because of a library support was dis- rupted. This can further impact the code base structure of the application. If the feature is a core element in the application, this can cause service interruption or can affect user experience. – Affects the design and implementation. There is no certainty that library development keeps up with the platform or browser updates. Furthermore, a change in the library can cause, if the quality of a library is not good enough, to match the needs of the application (or it simply leads to crashes or malfunctioning on various devices) the development is forced into to either eliminate the feature or to create its own version. In case the feature is required on multiple platforms, the library has to be implemented for each of them. Abandoning the feature diminishes the potential user experience, while developing it in-house affects the development time, project cost and further adds complexity to the code base. Chapter 6. Mobile Applications - Deﬁning the problem space 88

To summarize, the use of third party libraries can speed the completion of the application, but it comes with the cost of losing some of its control. It should be also considered that Native Frameworks also take advantage to libraries. However, two aspects are different: (1) The richer nature of the Native SDK and (2) The lack of bridge alignment in case of in-house development. To summarize, the Application Ecosystem varies in terms of resource existence, accessibility and quality, compatibility with the rest of the Mobile Ecosystem layers, evolution tendencies and the degree to which it forces control externalization.

6.1.2 Available features Section 3.3 described four different APIs layers which inﬂuence the development of an application: (1) Device level (e.g. accessing sensor data), (2) Platform level (e.g. Notiﬁcations, accessing contacts or Slices), (3) Browser level (e.g. changing browser behavior or accessing platform or device features), (4) Application Framework level (e.g. building interface and interaction). One special consideration for Hybrid applications, as they have to further deal with an extra layer of complexity. In their case, the application framework is formed from two separated technology stacks: the container stack (e.g. cordova container and plugins) and the web technology stack (e.g. Angular stack). As was described in Section 4.1.2, each framework class uses these layers differently. Through abstraction techniques and framework competencies they each expose a different development approach to developers. This approach can rely at different degrees on third party libraries or on developer integration effort. However, as it was mention in the previous section, each abstraction layer is like a bridge. The bridge needs to be built and to resist in order to facilitate it’s use. The maximum number of available features exists at the platform level. They incorporate low level access to device features and expose the platform APIs to use their features. Each platform develops an SDKs (Application Framework) level that provides a set of functions over these features. These functions can be further used by other Application Frameworks or Application Frameworks can develop their own bridge to the platform (e.g. Flutter). However, in case the platform developer and the application developer are not the same entity (e.g. Google in the case of Android and Flut- ter), but separate ones (e.g. Facebook an Apple), this may possible result in a lack of functionality alignment. For example, the React Native core Framework (v.58) still doesn’t support Voice Based Commands or the Android Slices feature. There are means to tackle this issue (e.g. beta stages), but it depends on how large are the changes and how dedicated is the Application Framework community. As was previously discussed, Development has three possible approaches in these scenarios: (1) use open source frameworks and externalize part of the control over the application feature, (2) develop an in-house library if the framework allows and bare the costs (time, money and code base complexity) or (3) abandon the use of the functionality (limiting the application). On top of these, for frameworks using the browser to deliver the content (especially Web) they are further bounded by the capabilities of the browser. For example Safari browser, the most popular way to access the Web on iPhone still doesn’t support features like PWA installation or the Web Push API (May 2019) 1. Therefore, for applications developed with these Application Frameworks there is no solution to circumvent the limitation. Lastly, another discussion revolves around availability of native design components. These components are used for building the User Interface and interaction. Native SDKs support them part of the UI library. Web Applications use a universal (Web based) set of components. In the case of cross platform development, application designers have a spectrum of approaches where they can choose from. On one extreme, they can deliver a universal UI on all devices (the web way). At the other extreme, they can choose to customize the looks on each platform up to the point where they

1https://caniuse.com Chapter 6. Mobile Applications - Deﬁning the problem space 89 are entirely different. However, the more they depart from the universal approach, there is a set of costs that arise. Firstly, they have to split the code between the two approaches. Secondly, more time has to be spent developing the custom look. Thirdly, no framework translated all important native UI elements in their libraries. Therefore, for some approaches, either further external libraries are required or native experience development can be used to create the element using native code (if allowed). What can be concluded from this section is that due to the nature of bridging, the more applications framework abstract from the native approach, the more complex it becomes to use platform and application speciﬁc features. In certain situations, the access is barred entirely. When it comes to design components, when moving away from Native frameworks there is a strong trade-off between customization and costs (time, code base complexity and control over the application)

6.1.3 The cost for achieving performance Previous section talked about feature availability. As was discussed in the previous chapter, it is not enough for an application to have strong usefulness but also score good points at Ease-of-Use and at the management of contextual use challenges. The interview with P. Bruce highlighted that relevant performance metrics should be based in user perception. However, as was discussed in Section 5.3.3, use is also influenced by technical performance (e.g. load time, crashes or bugs). Imagine using an application like Snapchat and having to wait 30 seconds for the filtering process execution. It is out of the scope of this work to assess exactly how technically performant is each framework. Literature findings will be used to paint a general impression of the performance landscape. Throughout the literature review, the following concept were used to describe the technical performance of an application: buginess, energy consumption, storage, data payload, time to first byte, response time, memory usage, latency, reaction time, memory usage and execution time [155]. The evaluation is generally made considering Native applications as the baseline. Some of the relevant findings will now be summarized. Cross-platform frameworks tend to consume more energy, mainly due to the rendering process [30]. However, research claims that development practices can be used to minimize this impact. Moreover, JavaScript based Cross-Platform Frameworks tend to consume more memory and to start slower [155]. When it comes to storage, the main challenge for Platform Application is that they have to be downloaded and installed on the device and consume a lot of storage space [109]. This aspect is extremely problematic as, according to a recent study (2018), 25% of application users deleted at least one applications because they needed more storage space on their smartphone [109]. To wrap up, the general Academia impression of Cross-Platform performance, it is generally considered to suffer a performance penalty (on some of the above mentioned criteria) [154, 155]. How- ever, as P. Bruce mentioned, it is not about the raw numbers, but about user perception. From that point of view, it seems the performance penalty is only perceived on low-end devices (considered resource constrained). Further research has to be done however in order to define what are the exact characteristics of these devices. An equal performance between cross-platform and Native was especially noticed when no Runtime computation is required (e.g. an Interpretative framework) [155]. An argument for this could be the extra bridge that slows down the internal framework communication. Furthermore, differences can also be seen based on the underlying platform [155]. The integration with different runtime environments leads to different results. When it comes to performance for Web Applications, things become more complicated. In order to achieve performance on the Web, applications have to deal with performance budgeting. A Plat- form Application has to be installed before it is used. Therefore, many of the resources and logic, required to boot and offer an initial user experience, is available offline, on the phone. Considering the negative user reactions to slow web loading times presented in Section 5.3, Web Applications Chapter 6. Mobile Applications - Defining the problem space 90 have to pay attention to the Internet imposed limitations. This results in budgeting the page weight in order to obtain better page speeds. When delivering a Web Application through the browser, the server has to provide all the libraries and resources required to load it. Figure 6.2 represents the evolution of the Page Weight over time (based on the HTTP Archive).

FIGURE 6.2: Average page size broken by content type (Source: SpeedCurve.com

It can be observed that the page size has is on an ascending trend. This may be a result of the active web developer community. Their libraries allow for creating a richer user experience. How- ever, for every extra feature added to the Web Application, another set of files is required. Let’s take for example the swipe gesture. This is not an interaction supported by the core Angular Framework, therefore another import is required (e.g. Hammer.JS 2). This will add extra 8KB to the page. Fur- thermore, as Figure 6.2 shows, the same goes for other UX related elements like media. To have an idea, just the base Angular web page footprint is 100kb 3. There is a set of technical solutions that allows for optimizing the Web Application content based on the device served and the quality of the internet connection (e.g. Adaptive delivery). However, two considerations from this point of view. Firstly, it requires further implementation effort as describe in Section 4.1.4. Secondly, in situations where the internet connection works as a bottleneck, this will just speed up the user access to the base functionality. It is assumed that the swipe gesture proposed above is less important than, for example, the main header of the page. For this reason, internet constrained users will mostly access the base functionality of the Web Application, while the rest will be hidden. One further solution for this issue is proposed by PWA. As they allow to be installed on the device, they can solve this issue by storing most of the necessary files on the first access. On later uses they are just reused. However, one extremely important limitation is that not all Browsers support this feature. The most important being iOS Safari, the most accessed browser on the Apple platform.

2https://hammerjs.github.io/ 3https://www.syntaxsuccess.com/viewarticle/size-of-angular-applications Chapter 6. Mobile Applications - Deﬁning the problem space 91

As a general consideration, testing is not a really optimal tool to identify performance issues. Both existing research [30] and P. Bruce explained that the diversity of devices makes it impossible testing applications on all devices. This may further cause unidentiﬁed performance issues, for cases where an application framework is used to build a single application version for two platforms (e.g. Flutter, Cordova, React Native). Furthermore, he mentioned that the robustness of the Android SDK allows for less bugs in development. A second general aspect is related to development overhead. Both K. Friis and C. Risom claimed during the interview, that in time, when a cross-platform develops, it becomes larger with a more complex code based. He explains that this happens in order to accommodate all the platform differences and incompatibilities. In the end, the code being harder to maintain. This issue could be anchored in the overhead created by having to abstract over two different platforms, with different APIs, design guidelines and different features. No research was found to support this claim directly. However, considering the ecosystem problems highlighted at the beginning of this chapter, this is a plausible claim. To summarize, research does not reveal strong differences related to technical performance. No broad conclusion can be drawn based on existing research. However, some more speciﬁc performance related issues can be mentioned: • Cross-Platform Applications are capable of delivering native results on high-end devices, but it can lead to noticeable resource constraints on low-end devices; • Internet speed is more powerful natural constrain for Web Applications. • Web application face a speed vs. rich user experience trade-off

6.1.4 Fragmentation Chapter3 outlined the fragmentation phenomena existing in the Technology Domain: Device fragmentation, Platform fragmentation and Browser fragmentation, Application Framework fragmentation. Chapter5 outlined the fragmentation phenomena present in the user base. The later was further detailed based on different aspects of use: • The perceived information and facilitating conditions are fragmented based on user needs and context; • The behavior is fragmented based on user type (Pioneer or Native). • The pre-post acceptance state of the use have different building blocks In order to build a pleasant use experience for as many users as possible, the application has to deliver a customized experience to each user in particular. This customize experience has to be anchored in personal use type, individual technology domain characteristics and ensure that positive information about the application is maximized. Constrained by the lack of user context information and technology limitations, some Application Frameworks can’t manage all the fragmentation issues. The work does not deny the crucial role of the actual software development process in this issue. However, as was previously pointed out, some technologies are either inherently limited or propose a high opportunity cost for delivering a feature or a customized application. Therefore a common strategy to deal with the fragmentation issue is to deliver an app matching the least common denominator [2]. This means, identifying the common ground in a fragmented domain and building the application in order to match it. For example, creating the same User Interface and interaction patterns both for Android and iOS. This results in an sub-optimal user experience for all use scenarios. This challenge of delivering the best UX for each platform has also been highlighted in real industry cases [50]. Based on how much the individual needs are ignored, the user experience can actually push the user away (e.g. if an Web Application Chapter 6. Mobile Applications - Deﬁning the problem space 92 for a store does not load in less than 4 seconds, the customer has high chances to go somewhere else [8]. Furthermore, there are application instances where access to context information is the main enabler for the overlaying service. In these cases, sensors are some of the most important tools an application can use, in order to access the information. Considering that Native Application Frame- works are part of the platform ecosystem, Google and Apple can ensure full integration with these. But this is however not the case for the other frameworks. For example, a common m-banking service is mobile payment through NFC. This is a huge revenue generation opportunity for banks [51]. However, no browser supports the NFC API standard (May 2019). Therefore, in situations like this, the failure of Application Frameworks to handle fragmentation, can lead to signiﬁcant limitations. This customization issue leads to the following claim: expectations borne out of the context are not inherently Cross-Platform. Going back to the reason why cross platform concept appeared: "Write once run everywhere", one can notice that the main purpose is not to support customization. On the contrary, it aims to ensure a common way to solve the same problem in multiple situations. This issue was further studied by E. Angulo and X. Ferre [24]. The concluded that “the Native approach provides a better set of tools for implementing good user interfaces and user experiences” [24]. This further builds on the assumption that less bridges between the Application Framework and the underlying platform and device means a higher chance to deliver a stronger user interface and user experience. Once again, the work acknowledges the value of the design process. It is arguably even more important than technology. However, as N. Linde pointed out, “design is as good as implementation can be”. To conclude, based on how well the Application Framework integrates with the mobile ecosystem, an optimal user experience may or may not be delivered.

6.1.5 Application code base evolution Up until now, the chapter presented various reasons for which the application code base could grow in a non-native environment: choosing to develop a feature in-house instead of using a third-party dependency, supporting features not provided by the Application Framework, for performance reasons and for creating customized experiences. It is important to understand what are the implications of this the mobile context. Firstly, A. Nico- laou highlights that: “most of the app development work is done by junior level developers”[106]. This can have consequences over the degree to which the code can be further extended and the quality of the code. This is especially important considering that app maintainability and code size are connected [107]. K. Friis further admitted that, initially, in absolute terms, there is more code required to develop two Native applications. However, he emphasized that, in order to particularize the experience to the speciﬁc needs and context of the user, but also to cope with the fragmentation issues, projects tend to increase in complexity rather quick. The same claim was made by C. Risom. P. Bruce also talked about code base management. He claimed that it should always be kept in an extendable state. He claimed that inexperience teams and high maintainability costs can require an application to be rewritten. Considering the challenges Cross-platform and Web technologies face during feature selection, design and development, there is a reasonable belief that long term maintenance effort and application expendability will be negatively affected. However, empirical research was found to support or deny this claim. Therefore, this is a subject that should be empirically validated. Chapter 6. Mobile Applications - Deﬁning the problem space 93

6.2 Application related problem space

6.2.1 User Experience "The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it." - Mark Weiser, Chief Technologist at Xerox Last but not least, the aspect of user experience has to be independently addressed. Chapter 5.3.8 highlighted that user expect form apps “an experience “in motion”, immediate, fast, in every place uncomfortable, so giving the user new opportunities for interaction”. Issue related to framework performance on low-end devices, fragmentation challenges, feature use limitation and quality of libraries directly influence the best potential user experience that the application can deliver. Furthermore, the issues highlighted in this chapter have the potential to stem visual inconsistencies. For example, a universal implementation approach across platforms leads to the loss of platform specific use feeling and perception. The lack of Native touch gestures in the Web context, can poten- tially be as harmful for the UX. The lack of Native support in Application Framework libraries for various visual Native components can also create a less unique experience. The analysis conducted for the Application Domain highlighted the importance of User Experi- ence. It is crucial both for forming a positive acceptance attitude of the application, but also to keep the customer satisfied with the service. In this context, smartphones and platforms should be invisi- ble. Users should be focused on their intended activity and continue their use behavior. However, if an application crashes, has high loading times or does not behave as expected the user is suddenly distracted from its activity. This is not the expected behavior from any application. In conclusion, the choice of technology can harm the end user experience or can create an artificial limitation to what the application can deliver.

6.3 Service related problem space

Lastly, building on top of the issues outlined in Section 6.2 and Section 6.1, this section will draw the major issue revolving the mobile service. As these are the mobile service characteristics impacted by the choice of the mobile framework, they will form the Business Domain.

6.3.1 Time-to-market One of the common discussion subjects when deciding on Application Frameworks is how fast can the application be published. As was pointed out in Section 6.1.1 the user of third party libraries can speed the development. Furthermore, assuming a low complexity project, development using a Cross-Platform (or Web) framework can speed the time required to have to final products with a resource constrained team. For example, this can prove to be advantageous during the initial iterations of a MVP. On higher complexities, this evaluation is hard to make. Considering the challenges outlined in the Application code base evolution section and the platform-application framework integration issues the development may run behind. It must be said however that this speed boost comes with the price of technical debt. Whenever the development speed is boosted it means that some of the development is abstracted away from the developer. This can either happen through framework auto-implementation or through the use of a library. However, this further generates lost of control over the application development. As it was previously mentioned, the code should always be in an expandable state. Therefore, it is a chance that if corners are repeatedly cut without implementation considerations, the application Chapter 6. Mobile Applications - Defining the problem space 94 application to get box out in a corner and not support further feature evolution. For example, taking the m-banking NFC scenario presented earlier. If the Bank would have opted for a Web Application, they would be blocked from evolving their application while all their competitors would not. This further brings the discussion to the third discussion point, the effect of path dependence. Taking a decision based on development speed should definitely be calculated considering that it will have future impacts on what be cone and can not be done. Furthermore, the adoption of an Application Framework and using it to develop an application imply a high sunk. This is especially problematic if the company finds it important to develop a feature based on an unsupported functionality (e.g. NFC case).

6.3.2 Customer service access Going back tot the Consumer - Channel - Service Provider Dynamic, it is important to understand that consumers of the service are users of the application. Therefore use limitations can become service access limitation. More speciﬁcally, the research explained that it is important understand the use context and adapt to the existing constraints. On the other hand, in Section 6.1.3, the analysis showed that framework performance can differ based on Device quality and Internet quality. If a business chooses a channel which is not aligned with their target customer segment and with the broader characteristics of the market, the service may perform poorly or may be even inaccessible. For example, when comparing the use context between economies and developed ones, one can point out various different characteristics. In emerging economies: devices are more resource constrained 4, internet technology is older and less efﬁcient, smartphone ownership is smaller [159]. As it was pointed out, some of the technologies are limited in terms of either (1) delivering a strong user experience or (2) offering service accessibility (e.g. lack of internet connection or smartphone to access the mobile service). Therefore, when considering the underlying Application Frame- work, business have to consider the existing framework limitations in relationship with the target customer segment. For example, devices used in China are not shipped with Google Play Store[2]. As a consequence, the framework choice should consider this Platform Application disadvantage. One interesting consideration is the market share raise of KaiOS and Feature Phones in Emerging Economies. Therefore, business owners should also evaluate whether it is worth creating this new customer touch points. If it is, this should also be part of the framework discussion.

6.3.3 Application distribution method Based on the chosen Application Framework the resulting app will either be Web Application or a Platform Application. Each of them is distributed differently to potential customers.

Web Application distribution As was discussed in Section 3.3, Web Application are accessed through the mobile browser. In order to land there, the user needs to ﬁnd it. It was already discussed that the nature of link sharing provides a simple redirect system. The web approach also allows for Over-the-air updates. This enables application owners to instantly deploy a new application change to all users.

Platform application distribution Platform applications are distributed through application stores (AppStore or PlayStore). This rises two other important issues: (1) what publishing strategy will be chosen and (2) whether the install

4https://mobiforge.com/research-analysis/mobile-software-statistics-2015 Chapter 6. Mobile Applications - Deﬁning the problem space 95 concept is desirable. In the case of Platform applications, updates are delivered through the store. They happen automatically, however developers have no control over the time when this happens. Moreover, even though it requires no user effort, the process disturbs the user if it happens during actual use time.

Installing applications As was discussed in Section 5.3, the installation step is an extra persuasion process for the user. The first step is for users to find the application in the store. As was previously pointed out, users take in consideration app store reviews and stars. Therefore, it is important to ensure a good image on the marketplace. However, as N. Linde pointed out, positive reviews are hard to obtain without a superior user experience. Otherwise, the business requires other strong motivators in place, in order to have the user download the application. As Nicolas pointed out through an eBook reader application example this is hard to achieve. Moreover, the reviews will remain on the app store as long as the application exists. Therefore, the long term reputation can be affected with an initial poor user experience. This is why Nicolas pointed out that a business has to be careful what approach it takes when it builds a mobile application. This strategy can further hurt the business in the future for the reviews it will obtain in the present. Is the installation process desirable? - Yes, if the application manages to be shortlisted. As was described in the application domain, users can be split in Native (Platform App focused) users and Pioneers (Web focused). For what it matters, installation benefits the former. However, there is a general tendency that people are unlikely to install new applications [2]. Therefore, there a considerable amount of effort is required to get on a users smartphone. On the other hand, the competition for the screen space is incredibly high. As all people interviewed mentioned, the application stores are full of great applications that rose the general standard. Furthermore, there is a tendency that popular applications break in order to separate their concerns (e.g. the Google suite or Facebook App and Facebook Messenger). This makes the competition even harder. However, it will be assumed that the application was installed. The challenge is not over, as users tend to remove an application (on average) after 2 uses. Therefore, the application needs to ensure it provides continuous satisfaction and utility. Of install-able PWA. It is not enough to get on the screen, they need to stay there. In the previous chapter, it was discussed that users tend to create a short list of applications where they spend most of their mobile use time. Therefore, if the objective of the application is to keep him as much as possible in the app context, the application has to fight with even better ranked applications (as they are shortlisted by Even though, you may not be the best application on the phone in terms of user experience, being one of the 40 applications a user has on the phone has its benefits. C. Risom talked about the need for an application to re-activate itself. This can help the user remember the perceived qualities and satisfaction and generate a new use instance (e.g. the email push notification). Another scenario for which passive existence is still valuable to read the user context. It was discussed that in order to maximize utility, the application should be able to read user context and adapt its behavior based on data acquired (e.g. Driving mode for navigation applications block driver touch when detecting speed). However, for these sort of interaction it is required to have a strong app-platform and app- device integration. In order for an application to get installed and remain successfully installed, it needs to compete with other applications for the screen space. To achieve this, an application has to present a competitive advantage over the other. Porter explains four Generic Strategies that can be employed in these situations: Cost Leadership, Differentiation, Cost Focus and Differentiation focus[strategy_porter]. In order to win against the competition, an application can employ the differentiation technique by delivering a unique application experience (present some unique properties valued by the owners). This can have a few impacts over the business: Chapter 6. Mobile Applications - Defining the problem space 96

• It can ensure positive reviews on the market. On the long run this can lead to a better customer acquisition; • It allows the app to ensure a screen space; • Builds the general positive customer experience of the service There are not many other options for an application to become visible and get installed from the application store. There are many free applications and the store search engines tend to favor well reviewed applications that have a strong user experience. Therefore, the chance for an application to be discovered if a different strategy is used will lower. However, it must be noted that these are not the only means to make a user download, install an application. In situations where extrinsic use motivation exist this whole competitive environment is no longer valid (e.g. a business requires employees to have installed a chat application on their phones).

Choosing the publishing strategy Companies can opt to publish an application on a single market or on both of them (process called multi-homing). Serving one market can allow a platform centered design. However, when two marketplaces are target, there is once again a trade-off between development costs, time and degree of customization.

Mobile store presence: a benefit or a liability? According to the interviewees, application stores a great concept. Nicolas invokes the review effects on possible customers and Philip the easy centralized distribution. Other benefits involve: large presence on almost all devices, ease of use, compatibility with all platform applications and the possibility for developers to get feedback on their products. Furthermore, they also reduce the transaction cost for acquiring a new application and build consumer trust. As users consider marketplaces a trustworthy source, updates and interaction coming from the app stores are easily accepted by users. All these factors ease the acceptance process of users and contribute to a simplified user acquisition for a service. However, when it comes specifically for how Apple manages its App Store, a new set of trade-offs appear.

The case of Apple’s App Store As the only access point to the iOS Application ecosystem, the App Store is critical for companies aiming to deliver a Platform applications on iPhones. A major difference between Google and Apple is the way they review their marketplace applications. Google has a rather short review process, that can lead to app store acceptance after a couple of hours after the application has been submitted. However, Apple has a set of control criteria. One of the most important set is the iOS Human Interface Guidelines [2]. These are a very strict set of guidelines, functionality and development practices. In case they are violated, there is a very high chance that the application is rejected. Moreover, Eaton et. al. discuss about the slow acceptance process, arbitrariness and sometimes aggressive use of their control mechanism. [38]. For a long time, their guidelines contained “If your App is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps.”. For example, one of the victims of the control mechanism was App-Gratis, an application that recommended other applications to users. Even though the company was rather established and the application had 12 million users, it was removed from the store. The reason, according to Apple was the adoption of a new guideline stating:“Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected.” [85]. Chapter 6. Mobile Applications - Deﬁning the problem space 97

Conclusion To conclude, publishing an application on an app store comes with beneﬁts but also with a set of risks over the future of the application. Apple can take advantage of its ecosystem power structure in order to eliminate unwanted applications. On the other hand, browsers, strictly from a distribution point of view, an simple platform to deliver an app to customers. However, the browser lacks the powerful re-activation mechanisms an installed application has. Therefore, each of them has beneﬁts and downsides when it comes to customer acquisition and customer retention.

6.3.4 Service costs implications The main downside of using Native development represents the need to develop two different applications, with two separate knowledge requirements. This translates in higher costs for the business. On comparison, JavaScript based framework have two major advantages that can reduce the development costs. Firstly, they employ the "code once, deploy everywhere" technique. Secondly, if the company already has a Web development team, part of the know how and resources could be aliened in order to minimize future maintenance.

6.3.5 Customer experience and customer satisfaction Competition strategy and customer experience are the most important concepts linked to the choice of mobile framework. Customer experience is the internal and subjective response customers have to any direct or indirect contact with a company. [128] Customer experience describes every aspect involved in the company offering to the customer (e.g. packaging, service features, ease of use reliability). In time, users create expectations about a company and their services and products through touch points. At every touch point, the customer compares the set of expectations build against the experienced delivered through the channel. There- fore, based on the importance of the touch point, specific channels can have more or less impact on the customer experience. Nevertheless, in the case of digital channels and digital services, there is unique characteristic: the personal interaction is missing [116]. Therefore, in these situations the experience delivered through the channel is critical for forming the customer experience. Furthermore, channel interactions matter even more if the business core offering is flowing through the channel [128] (e.g. the mobile application in the case of Uber). If the mobile application is the main channel for the core offering, it is important to ensure that the contact of the user with the business creates a good experience. This can be achieved when the experience is built for that specific context and intent of the mobile customer. By delivering a customized experience, there are higher chances to match the specific expectations of that user. This can in turn generate a positive customer experience. One thing that should be remembered is that mobile customer experience does not have to stop after one use instance has ended. By opting for a framework with a tighter platform integration, features like Slices, Assistant integration and Push Notification to ensure the service use continuation. If used in the right manner, these tools can not only improve the customer experience, but also increase the user engagement with the system. As was explained before, the use of the mobile application is evaluated and can generate positive satisfaction. However, based on the choice and implementation of the technology, customers may face negative experiences like technology frustration. This frustration will further reflect in the overall experience. Moreover, when dealing with Millennial customers, they are mobile natives. They have been exposed to applications from huge brands like Google or Uber. Therefore, their expectations are even higher, rising the requirements on digital service experience even more. Chapter 6. Mobile Applications - Defining the problem space 98

However, if these expectations are successfully met, businesses can have huge beneﬁts in terms of more loyal customers, lower churn rates and, as all interviews pointed out increased revenue.

6.4 Conclusion

This chapter has presented the Technology related problem space, the application related problem space and the service related problem space. 99

Chapter 7

Model Presentation

The resulting model after putting together all three building blocks (T.D., A.D., B.D.) and the identi- ﬁed problems are depicted in Figure 7.1.

FIGURE 7.1: Final discussion support model

The model is meant to be used a discussion support model. Based on the interest and knowledge of the people participating at the discussion, a set of Application Frameworks are selected. After Chapter 7. Model Presentation 100 that, the participants should identify all the relevant information related to each building block and discuss the problems proposed. 101

Chapter 8

Work limitations and further improvements

8.1 Work limitations

The work was limited by the availability of possible interviewees. This lead to insufficient researcher extended interviews with experienced professionals coming from the Cross-Platform development industry. In order to tackle this issue, during Google I/O the talks were selected in order to maximize exposure to Web and Cross-Platform frameworks. However, the lack of formal discussions during the exploratory phase may have directed the research to adopt a Native driven point of view. Even so, the findings are still considered to be valid and relevant discussion topics. Another limitation point was the degree to which technical research is up to date. Even though research tried to anchor it’s literature references in recent work, the whole mobile ecosystem is rather innovative and fast changing. In order to mitigate this effect, the research tried to avoid relying on hard numbers and only use technical evaluations (e.g. performance metrics) if multiple sources would confirm them. In order to scope the research, the work didn’t create a model component for the development and management of information systems and for the design process. However, these plays a role as important in facilitating the discussion around Application Framework choices.

8.2 Further improvements

To begin with, future research should start by validating the model proposed as part of this work. The assessment should look for empirical proofs in the mobile ecosystem, to see whether any part or all of the problems proposed for discussion in this work are actually valid. For example, one way to achieve this would be to conduct a survey among mobile business developers, mobile application architects and mobile users to create a better representation of the industry problems. Secondly, a secondary study following the same methodology should be conducted. However, it should focus on interviewing experts and entrepreneurs with a richer background in Cross-platform development. They may approach the discussion with a focus on different aspects (e.g. development process). With such an exploratory set of interviews, the work could end up identifying a totally different set of problems. This would contribute to the existing model, enriching the discussion and rising awareness on relevant topics uncovered in this paper. The work conducted part of this research started with a set of self imposed limitations. Some of these can be further explained as well: 1. Create a model with more descriptive components, but with a lesser degree of depth for each of them/ Chapter 8. Work limitations and further improvements 102

2. Attempt to use other types of adoption theories (E.g. Diffusion of innovation or Organization Structure Theories) 103

Chapter 9

Conclusion

The research identified a knowledge gap related to mobile Application Frameworks. Specifically, what is important to know for a business organization when deciding how to build an application for their mobile service. the decision making process. With that in mind, the work proposes two main research questions. What are the main technology options available for developing a mobile application? In order to answer this question, the work identified the main layers in the mobile ecosystem. Once the general dynamic around mobile applications has been identified and described, the research focused on the technology options. In the context of this research, it was found that technology options consists of Application Frameworks. In order to understand their characteristics and competences, the analysis presented in Section 4.3 was conducted. The analysis resulted in an Ecosystem based model describing what are the main Application Framework categories (Native, Cross-Platform and Web) and what are their characteristics (technology characteristics, development resources, development community and ecosystem control). In order to enable a deeper understanding of the issue, the work analyzed a diverse selection of 6 frameworks using this analysis block. What are the main problem areas to be discussed by a busin that considers the usage of one of these technologies in order to build an application that serves it’s mobile service? and What impact can this choice of technology have over the mobile service? In order to answer the second set of questions, the research had to develop a model that can facilitate the discussion around Appli- cation Framework choices. The model started from the analysis block developed part of the answer for the previous question. The block was called Technology Domain (T.D.). Further on, the research had to find a bridging descriptive component in order to facilitate a more thorougher discussion around the existing choices. In order to identify the most relevant approach, two steps were taken (1) extensive literature review based based on the concept of "application" and (2) 2 exploratory interviews to filter the relevant knowledge and to understand the industry perspective over applications. It was discovered that mobile applications exist in strong relation with users. The central view on this dynamic is based on the concept of use. Therefore, a second descriptive block was created in order to describe this dynamic called the Application Domain. In order to focus the analysis of the block proposed three domain related research questions: • What makes people use a mobile application? - This question primarily focuses more the acceptance of the application. • How do people use mobile applications? - This question primarily focuses on user behavior • What makes people continue using mobile applications - This question primarily focuses on the intention to continue using the application. In order to answer these questions, the research developed an new theoretical framework that would incorporate existing theory on technology acceptance and technology continuation concepts. This new model was used to answer the three domain questions mentioned above. This analytic model is also used as the Application Domain (A.D.) building block. Chapter 9. Conclusion 104

Finally, the work has used the ﬁndings from T.D. and A.D. analysis in order to identify a set of six central problems resulting from a choice decision: • PB: 1: The cost for achieving performance • PB. 2: Framework ecosystem structure and maturity • PB. 3: Fragmentation • PB. 4: Application code base evolution • PB. 5: Available features • PB. 6: User experience These 6 problems were analyzed and it was found that they can modify ﬁve mobile service properties, forming the Business Domain (B.D.): • Application distribution method • Time-to-market • Customer experience and customer satisfaction • Service costs implications • Customer access to the service The resulting model was presented in Section7. This model can be used by people interested in making an adoption choice related to an Application Framework. The respective person, can use the framework in order to identify the main topics to be discussed in such a situation. It can be concluded that the work has successfully achieved its objective: creating a model to support the knowledge gathering process required for making an adoption decision related to an Application Framework. 105

Appendix A

Interview - Kristian Friis

I. General opinions on Mobile Web vs Hybrid vs Native A. Web / Hybrid technological attempts are more mature on Google’s side compared to Apple. B. Hybrid technology: i) The case behind them is to build once and distribute on multiple devices types; ii) You can’t go as far as you can go with native. When asked what does “far” mean, he replied that you Can’t directly hook in native components (mainly sensors, voice commands, push notifications, connectivity elements ex. Bluetooth) because of the consequences of splitting the code base and therefore losing the advantage. Moreover, it is harder to achieve an OS embedded app experience, because of the same consequence of splitting the code base and also losing the advantage. You can’t make the user journey that is required for today’s application. Here, the consequence revolve around limiting the user experience. Thus affecting the way in which you can compete on the market. You can differentiate yourself through (1) price or (2) User Experience General take away (analogy): When using this approach, you can build fast the first 80 iii) There is a tendency to stick around 2-4 years and then developers move away to some other platforms, to the next big thing. (1) Plugins/platform is left unmaintained. You need to take control in your own hands. By this, you create a (1) long term risk of the project, (2) gain extra responsibility. C. Native 1. Has a higher initial cost 2. It is good for longer planning, complex products. 3. It is the more secure choice when it comes to control and maintainability D. Total cost of ownership of a mobile application - is not only defined by the application development project. But also, the maintenance, further development, costs for improvement and fixing. Native may have a higher starting cost, but that also comes with a given framework stability. This can be seen as one of the Value Propositions of Native Tech. II. Discussing the value of mobile applications: A. How do clients usually respond to your pitch- ing of Native? What is the criteria they decide on projects? 1. Points of view (PoV): a) From the business development PoV, native is the choice b) Economical PoV (=How much does it cost to bring the project to live?) 2. Comments: a) Can you afford not succeeding with the application you want to build? A competitor can do it and steal your competitive advantage. Can you afford not being the best one to deliver customer experience? b) McKinsey studies “Clean thread from Customer Expe- rience (C.E.) delivered to your bottom line in your financial statements” Business Success is heavily influenced by C.E. B. Regarding customer interaction, the trend is that it happens in the digital environment. Your digital channels deliver customer experience and build relations. A business has the core product (part of the C.E.) and the supporting layer around the core product the facilitates it. They are both evaluated by customer when you are on the market. There are many competitors. Both components can help you differentiate, offering various competitive advantages. In this context, a digital product can be the core product (In a pure digital business) and facilitate the core business (often a physical product). a) Try to answer the question: b) How can you make it as easy to deal with the core product? “That is where I still see apps as being one of the main things that does makes sense on the market. Because you wear your mobile everywhere around.” Appendix A. Interview - Kristian Friis 106

C. Is there a case when you don’t want a mobile application? (YES) 1. If you have a long user journey between downloading the app and first experience inside it. The customer perspective is important (How many clicks does it need until the app gets on the phone?) 2. Applications have a long process until they are used: a) I need to be aware there is an app b) I need to find the right place in the app store c) I need to download it d) I need to go in the app e) (Maybe) I need to sign up 3. Web is more accessible for achieving a lightweight task (Involves many people for a short interaction) III. Business approaches of Google and Apple A. Very Different Business Model focus. While Ap- ple focuses on selling Hardware and supporting services on top of the hardware (app store, iTunes), Google focuses on advertising. This results in their market initiatives are driven by the business model they adopted and balance sheets (what brings money). They try to defend and extend that. (I) This is the reason for which Google is experiencing with Instant Apps, progressive web. Funnelling more web behavior in the app experience = Opportunity to bring advertising to your phone. (II) Apple tries to justify the cost of their hardware via: • The nice design they use. • The great User Experience they provide. • A guess for the future would be a claim in the privacy area and Google can’t claim it because advertising Business model relies on data. The conclusion is that it is not a joint movement between Google and Apple, towards Web Technolo- gies. It is more of an Google movement because it supports its B.M. IV. How organizations approach mobile applications A. Do mobile apps for you to change the way in which you think about your business and how? 1. Digital is making you reframe how you think about the business. Mobile is just one of the underlying components. 2. There should be no Digital Strategy BUT Business Strat- egy with a digital core component. 3. Unique mobile considerations: a) You have access to more context of the digital experience delivered; Web has cookies, but no sensors. b) Human beings want to minimize cognitive effort done by their brains. Thus they strive towards the more intuitive to use, meaning shortcuts. Bringing these shortcuts into the digital world creates intuitive experience. B. Changes for the digital strategy 1. 3 years ago a major transition has happened. The discussion about creating applications was brought closer to the business the decision maker (C-Level). You no longer have to go through middle-man with various incentives, motivation, expertise. The Reason of change was that they saw how much business value you create with apps. As a consequence, there is no longer a need to argue that an app is useful! People understand opportunities and importance. But rather, what sort of app fulfills your needs and therefore you should build. C. Does this shift bring any changes in my organization? Is there a need to add/modify/adapt something? 1. The digital department was traditionally used with Web. Now, there is a new channel they have to manage. Thus it is important to understand what is each of them good at? a) How should we do customer acquisition? (Web) b) Which one should serve the new and the existing customers? c) Do we need to have a 1 to 1 functionality? Can you split it apart? d) How do you use them in relation with Omnichannel strategies? Take away: Identify what the channel is good at and optimize your flow! 2. There still is a competition between Web and Apps: a) Businesses need to identify what is growing in their business (Web or App?) b) Are people moving from one to another? (1) Tendency of people moving from Web to Apps; c) They have cases where web 1 to 1 feature pairing with Apps, or even more features on Web, but people still migrate to apps. The take away here is that it is easier for people to be inside applications (they are more intuitive, offer better customer experience). Not only feature number matters. V. Differences between B2B and B2C when regarding mobile applications A. In the past the Customer experience was not so Appendix A. Interview - Kristian Friis 107 important for B2B. 1. Businesses slowly understanding that It is still humans using and deciding on applications. Therefore, Customer Experience slowly becomes a competitive advantage in the B2b sphere. 2. STILL “If you take 10 application cases in B2B and 10 application cases in B2C, a higher percentage of technological choices try to cut corners in B2B 3. The consequences are that either Case A, a Mobile application as an internal tool for a company, (it aims to make more efficient your business processes). Because of a low customer experience, it has a lower adoption rate or Case B, where a Mobile application as an external tool of interaction (it allows other businesses to interact with you). Low customer experience means that they may pick a different business partner because it is easier to handle the interaction (Remember, you compete on Price & Customer Experience here, as well) VI. Consideration on Customer Experience: In 10 years the technology will change, but there will still be a battle to deliver Customer Experience. Take Apple growth for example. Devices have changed over time, but focus was kept on Customer Experience! They are never early adopters, sometimes fast followers or mostly when tech is mature enough to support the Customer Experience that they intend to deliver. 108

Appendix B

Interview - Nicolas Linde

[Deﬁning the application domain] 1. What is your understanding of a high-quality application, a successful application and a useful application?

[Understanding high-quality applications] According to Nicolas, a high-quality application is strongly tied to how well it is executed. It requires a lot of work invested in detail like typography, layout, transitions, which generate a highly customized product. Furthermore, he introduces the idea that applications are tools, where high quality ones differentiate themselves from ordinary tools by being well crafted, and that results in a superior experience (“nicer time”) when people use the application.

[Understanding successful applications] When it comes to characterizing successful applications, Nicolas believes they are the ones that make people reach for them when they have small breaks (like in the bus or in a waiting room). From his experience, each person has a small set of applications that they reach for during those times, and those are the successful ones. From his point of view, these applications have a well- deﬁned goal that they want to help the user achieve. He points out that the application is often not the product in itself, but just an extension of the actual service provided to the users. A successful application excels at allowing people to use the service, by being the most convenient channel.

[Understanding useful applications] Lastly, he believes that useful applications are the ones in your reach and ready to make your life easier. This readiness is often achieved by having information about the user or the task he wants to achieve. (a) So, in the case of successful applications users reach for those applications by themselves.

[The importance of reviews] Mobile application products are different from other types of products, since you can see other people’s opinions (reviews) of the product before using it. Moreover, he believes that there is no easy way to get good reviews. Therefore, this is a strong reason to invest time and effort in making well-crafted applications. From what he remembers, on average, an app is used 1.7 times before it gets deleted again. And that only happens after it has passed through “the review test“ (obtaining good enough reviews to be installed). Therefore, you need to ensure that the application has good reviews, as users will confront (and follow) them even before using it. Nicolas argues that this is a beneﬁcial aspect for application Appendix B. Interview - Nicolas Linde 109

owners because they don’t have to target and convince individuals one by one to adopt the application. Instead, users can rely on other user’s reviews to build their opinion towards the application. Therefore, spending time on reﬁning the product is important. This will generate more positive reviews. Less time spent means, in his opinion, getting worse reviews. In order to support his claims, Nicolas presented an example about an eBook application that was executed using sub optimal resources (time and costs). This generated a huge release delay and even though the product had huge potential and an untapped market segment, the application did really bad and obtained an average review rating less than 2 out 5. After a remake of the application that allowed the design and execution process to dedicate towards details, the application obtained a review average rating of 4.5 out of 5 on the application stores. Furthermore, he pointed out two other take aways (1) always dedicate yourself to the product and make it as it was yours and (2) one must be careful what approach it takes when building a mobile application, as it can hurt his/her business. You will struggle to convince the people because it had obtained bad reviews in the past.

[Exploring Business motivation – User motivation alignment] 2. He mentioned two incentives for businesses when taking decisions regarding application development, costs and time spent. What other incentives did he encounter?

[Defining application features] Nicolas identified another aspect that companies take in consideration when building applications: the purpose and scope of the application. According to him, many companies who want to develop mobile applications want to include many features and ideas in the first version of the application. He believes this can be harmful for three reasons: (1) often the companies don’t have the necessary budget that allows for developing a well-crafted application, (2) this approach can hurt the resulting user experience and (3) the product can feel a lot less focused. Consequently, he always militates for starting with an excellent single scope application. The product owners should identify which are the 1 or 2 important things the users should be able to do in the application. Once this is achieved, you can slowly extend. However, this implies that you need to find a balance between designing an extendable architecture, that can also perform good at every version of the application. One successful example of a focused application that evolved in a good complex application is Fitness World App. It started from booking and cancelling classes and it became the main channel to reach the users.

(a) Is there an adaptation period for users to get accustomed with the features? Is there a problem if there are too many features?

[Impact of feature number on how users adopt applications] In his opinion, users generally think they already have all the applications they need. There- fore, the application needs be very clear about why it should be adopted. As it was previously mentioned, this happens when you have a clear identity, which is achieved through those one or two things your application should do very well. From Nicolas’s experience, the adoption is easier when the product is (a) as basic as possible and (b) as user friendly as possible.

[UI/UX design process] Appendix B. Interview - Nicolas Linde 110

3. Why is it important to dedicate time to the design process, from a UI/UX designer point of view?

[The importance of UI/UX design process] The design process at Shape involves understanding what the client’s goals are and what would they want their users to be able to do. He points out that it should combine empathy for users with a business strategic perspective. Furthermore, the design process involves bridging this product owner view with the engineering domain, ensuring that the final user experience is a friendly one. He points out that when engineers are in charge with the experience, they tend to focus on efficiency and be less empathic towards the end user. He points out that designers focus on user perception over the application, while they consider what is possible for code to build and deliver in an application context. Moreover, he noticed, that sometimes application requirements come from inside of an organization (ex: how the it is structured). However, he emphasizes that it is important to focus on what users like, because that will bring the benefits for the business. Main observations: (1) Have an empathic approach when designing applications. (2) Separate the technical developer role from the designer role, or you may otherwise end up optimizing the behavior and look based on your knowledge of technology limitations. The role of the designer is also to push the limits of the developers in order to find new ways to solve design proposals. (a) Where does the UI/UX work help a business?

[Business importance of the design process] Firstly, Nicolas outlines that UI/UX work can be as good as the execution is. Designing and building go hand in hand, therefore behind a great designed application is also a great team that implemented it. He believes that this work has mainly a revenue optimizing purpose. A good UI/UX design will make a significant difference if you want to make it easy for your users to buy, register, login or whatever is included in their shopping behavior. This work will help the business achieve their financial goals. However, to achieve an optimized flow, businesses need to be ready to invest time. Two examples he offered were the Danske Spil and OK Gas Station applications. In both cases the management level has recognized the large amount of revenue generated through the mobile services. Furthermore, in the OK case, the application increased the sales of car washing services and reached to the point where more than a third of acquisitions go through the application. (b) i. Is there a change in the recent (general) user behavior that supports this amazing result? Do you believe there is an external factor, besides the internal ones linked to application design and execution?

[Changes in user behavior] From his observations, users demand more from mobile applications. In the beginnings of mobile applications, it was enough that an application could just do something. Since then, the general level of mobile applications has become so high, that the expectations rose a lot. Therefore, anyone who wants to compete, must at least match those expectations. Moreover, nowadays users are mobile native (they know and are comfortable with using mobile applications). This makes it easier to deliver more complex UI because users already know how to use it and you don’t have to limit yourself to simple approaches (ex: just some call to action buttons). Appendix B. Interview - Nicolas Linde 111

[Platform differences from a designer perspective] (c) How different is designing for the 2 platforms (iOS and Android)? And how does 1 common design inﬂuence it? Even though it is different to design for each of them, they started to follow some common design patterns, which makes it easier to make something that feels native on both. Android material design and iOS design guidelines seem to evolve towards each other. The biggest difference is how things are already implemented on each platform. In his opinion, it is easier to make custom designs on iOS than on Android. Android often requires special treatments when implementing the design. Initially many clients wouldn’t pay for 2 designs. In this context he points out that the Danish iOS market is stronger, even though there are more Android devices in use. The strength is given by user behavior, as iOS users tend to use application much more than their counterparts (ex: 60% to 70% of Fitness World bookings come from iOS). Therefore, since iOS user behavior is more active, in cases where there wouldn’t be a budget for two designs, the team would focus on making a strong UX/UI for iOS users and then try to put it in an Android Framework. He doesn’t believe that this is generally a good approach, but there isn’t much that can be done with such budget constraints. They also try to make designs as platform agnostic as possible and then they would spend time with developers to adapt it to each platform. Nicolas noticed that on Android, the way in which applications are built is a lot more dogmatic (ex: laying out a ListView). Another major problem is Device Fragmentation, which translate in different resolutions, densities, processors. Because of the multitude of devices, It is a lot more complex to reﬁne the products on the Android, then on iOS.

(d) Is there a specific set of problems derived from letting one platform behind in terms of following the design platform standards/guidelines? Doe that affect the user behavior and perception in a meaningful way? Nicolas views this situation to be a lot like how Mac and Windows users perceived their products some time ago. Android users (like Windows ones), tend to have a higher toleration towards sluggish performant and less fine crafted applications, than their counterpart. From his perspective, a lot of this comes from the way in which Google build its ecosystem. It tried to make it as easy as possible to make Android applications and that is easy when everything looks the same. Consequently, the default app behavior and visuals provided don’t feel like being unique and special. If you want to build a premium Android application, you must build on top of existing user patterns and use characteristics and improve the user experience provided by the platform. However, this may be hard, as he considers An- droid to be less flexible then iOS. He believes that the platform tries to fit too many devices and purposes, while phone manufacturers further customize the operating system. This makes it hard to find the golden rules when describing the platform Application behavior. As a result, designers are sometimes left with going for the lowest Android denominator. His hope is that the new Google OS will solve this issue.

(e) Would you see a moment where the two design patterns will totally overlap? Even though he would like it, Nicolas believes there is a need for deﬁning an individual OS identity. Google and Apple will use these patterns to differentiate themselves on the market. However, he hopes for the good of the users, that the two platforms will move closer to each other. This will allow users to switch easier from one platform to another. Now, users have to get used with a lot of different OS behavior differences (ex: How screens are Appendix B. Interview - Nicolas Linde 112

laid out, how applications are exposed to the user, how widgets are displayed and accessed, how navigation works between screens). Furthermore, there are some platform speciﬁc elements, like the Android Floating Action Button, which have not been adopted by many applications on the other platform. There are a lot of platform design aspects that you need to take in considerations.

[Design differences between Mobile Web and Mobile Native applications] 4. What differs when you design for mobile web instead of native applications? When it comes to the capabilities of mobile web, Nicolas finds it rather primitive. As mobile applications need to be responsive, it makes it difficult to create a unique experience on mobile devices. Due to variations in device resolution, the frameworks have to automatically optimize the experience. Even though this works well for the user, it means you need to design for the lowest common denominator. In Nicolas’s view, this is a crude and limited way to do product design. Further on, Nicolas talks about how each channel is good at different things. He differentiates the use cases for web applications and native applications. From his perspective, the web approach is great at displaying basic information. On the other hand, native applications excel at difficult / complex tasks (ex: ensuring that users stay logged in your service, get push notifications, allow to user to create and move objects around). Moreover, they allow you to use device and OS capacities (GPS, accelerometer, processor, memory, different touch capacities). Capacities that are often hard to hook into from a mobile website. On top of that, you need to universalize the experience to allow a broad range of devices to access the service. Therefore, designing for web implies optimizing for users who don’t have the latest device and features. All in all, you always need to evaluate the final purpose, sometimes an application can be an overkill.

[UI importance for future applications] 5. There is a trend of moving towards devices that interact with you without the need of an UI (“Zero UI”) - ex: Amazon Alexa, Siri. Do you think mobile applications will move towards that direction on the long run? Nicolas believes that in general people will spend less time looking at screens. Applications will change signiﬁcantly (ex: the way in which we book a ﬁtness class or a movie ticket) and together with them designer’s and engineer’s job will change as well. He mentions that content search should follow this trend, as users should spend less time with the device. However, Nicolas believes there will always be a case for direct interaction for screens, as this is the way in which content is consumed on mobile. He experienced design changes in the past, for example the paradigm shift from Symbian style applications to iPhone style ones. Yet, this time he thinks the evolution will happen a lot quicker. 113

Appendix C

Interview - Philip Bruce

[Deﬁning the application domain] 1. What do you think a high-quality application is, from a business perspective?

[Understanding high-quality applications] From Philip’s perspective, a high-quality application is one that is valuable in money terms for the business. This is also why Shape focuses on building high quality applications, as they help businesses earn money. He mentions that other members of the industry may develop applications with different purposes (ex: marketing driven type of applications). He believes that building applications that generate revenue is the place where businesses can get the most return on their investment, especially that the application market has matured.

However, the purpose is not enough to define the nature of quality. He finds it hard to have a complete definition of quality as it may vary based on personal experience, perspective and interests. Therefore, in his and Shape’s perspective, there are two aspects that influence quality of the application: the nature of user interface (actual design) and the user experience (how the application is used by people). He believes that they are especially important in mobile context, as the usage setting is constrained by time and attention span. Consequently, mobile applications must be optimized to allow users to achieve their goal quickly. For this reason, adapting to the context of use is what drives a quality application. Therefore, it is important to focus on user interface and experience. He claims that if this is done right, it will also be beneficial for the business.

In order to allow users to achieve their goal quickly, applications need to enable users to access the feature they search as fast as possible. For this reason, the application needs to focus on a core task. For this reason, a high-quality application is one that is excels at deﬁning its core features and provides fast user access to them.

One further concern for this application category is ﬁtting to the platform patterns. iOS and Android work differently. Respecting the platform rules increases the quality. This is because the application feels and behaves like the rest of the system, so it feels integrated in the general Operating System use. If the application delivers a universal behavior on both platforms, the experience will feel a bit off. He admits that there are similarities between platforms and most of the things can be done in the same way on both platforms. But there are cases when you need to particularize the visual components and behavior. This impacts the user learning curve. Taking advantage of concepts already proven in other applications in that O.S. ecosystem means your user will already know how to user your application and will feel home in your app. This aspect Appendix C. Interview - Philip Bruce 114

directly inﬂuences the user perceived quality of the application.

(a) Does that mean you are limited in the number of things you can do in mobile applications?

According to Philip, there is no limitation. If the application starts to lose its focus or to become inefﬁcient in its user experience due to having too many features, there are solutions to solve it. One way would be to split the application in separate applications, each of them optimized for a different core task. A good example in that sense is Facebook, that has separate applications for engaging in social media, messaging and business development.

[Understanding performance in mobile applications]

2. What do you look at when evaluating performance on mobile applications? Once again, there are many possible perspectives one can have when analyzing application performance. One natural tendency would be to look at the raw technical application performance. However, he believes this is less important if you evaluate it from a user or business perspective. In this context, performance evaluation should focus on what user perceives. In his view, this is influenced by two set of decisions: (1) Design decisions (ex: the user flow), and (2) Technical decisions (ex: how fast you load the API data in the application). However, he strongly believes that in the case of high-quality application, there is also a subjective niceness or feel of applications “How nice does it feel to perform this action”. Therefore, performance is as important as it impacts the user perception. Furthermore, he believes that visual cues, specifically the quality of animations, are critical in how user will perceive the application. This is something that a high-quality application should be concerned with.

[Impact of device fragmentation] 3. How do you handle device fragmentation in your projects? According to Philip, device fragmentation is real and needs s to be considered on both platforms. Even though iOS has fewer devices, there are still relevant differences in screen sizes, resolutions and OS versions. Indeed, iOS is easier to handle because all iPhones are updatable, and Apple has a good history of supporting them. On the other hand, in the Android ecosystem, it is up to device manufacturers to update or not the device OS. Oftentimes, popular devices get stuck at a specific OS version and you can’t ignore them due to high number of users. His solution to this issue is testing the application. Even so, it is not economically feasible to test on every Device, considering the number of Android handsets. At Shape, the testing phase involves thorough testing on a selection of screen sizes, device models and OS versions based on usage statistics. All things considered, in his experience, device specific bugs are fairly rare. The types of problems he sometimes sees is that the UI is not scaling or that different devices manufacturers handle in different ways OS features, like storing files. (a) Why do you think device specific bugs are few? Philip identifies to reasons: (1) Develop- ers are aware about this issue when they build the application and that (2) it feels like SDKs have become better at scaling on all devices.

[Role of open source libraries in native development] Appendix C. Interview - Philip Bruce 115

4. What is Shape’s policy on using open source libraries? There is no specific policy. Open source libraries are used in development. It is up to developers to decide when and if it is worth doing it. However, Philip is cautious on this topic and tries to minimize their number, especially if he doesn’t see a large benefit in using them. He sees a couple of problems that they can bring in a project. Firstly, you don’t know what could be injected inside the code if you don’t develop it yourself. Secondly, you don’t know for how long it will be supported. This is can be highly problematic when SDK or OS changes break a library. On several occasions, they had to deal with libraries used in production that were deprecated or that had suffered fundamental changes from one version to another. These events may force a lot of changes in the application code, in order to adapt to the new context. His philosophy on the topic comes down to “Does the usage of the library justify the savings and the risks that come with it?”. This can definitely speed the development process. However, if you want a long-lasting codebase, you have to evaluate whether this will be a benefit, or it will actually become a hinderance after a while.

[Rewriting applications – causes] 5. What justifies rewriting an application? In his experience so far, there are a couple of valid scenarios. • The development team boxed themselves in a corner from where it is hard to exit without doing it. In a project with a long lifetime, this usually happens because the initial product assumptions and constraints no longer hold. These assumptions can change either because (1) the core focus of the application changed, or (2) there was not enough budget to successfully build a scalable quality application, (3) the feature set exploded in time. This specific scenario usually calls for a full design change, as the initial design model may no longer support the new functionalities. • The development team learns a lot about the product and technology over time. At some point, it may be worth rewriting it in order to take advantage of this know-how and maybe also choose a more appropriate architectural option. • Application redesign • Maintainability reasons. One should always ask how much it will cost to add a feature or fix a bug if we continue building on top of the existing code instead of rewriting.

(a) Is it a natural step for every application to go through a rewriting process at some point? Philip believes this depends on the source of the issue, but no, you could theoretically avoid it. If the product is complex from the beginning, but you have a roadmap and a growth direction established. If this is strategy is properly executed, applications can go through a continuous change process that keeps the updated while you add new features. According to Philip, a key aspect in app development is keeping the product in a state where it is easy to maintain and simple to expand. Otherwise, you are prone of introducing bugs. This becomes problematic if you aim for a high-quality product, as they tend to have no or very few bugs. To make it clear, he does not believe in bugless software, however they should be few and should not appear very often.

[Understanding distribution methods to mobile devices] (b) How would you compare the different ways of app distribution on mobile devices (Web, app stores and software download from a website)? From his point of view, the real discussion is between accessing the application directly on the Web or installing it from an App store. There is no competition between stores and the Appendix C. Interview - Philip Bruce 116

old way of website downloads.

One of the main issues with stores is bringing people to the point where they download your application. Both Android and iOS stores offer an easy and good experience, when compared to downloading software from a website. However, web is considerably easier: you go in a browser, you search for the product or service and that is it, you can access it.

Even though there are beneﬁts for businesses to have their users in native applications, some of them fear that it will be too hard to bring users in there. As a consequence, some of them opt for a hybrid approach: they have both a web presence and a native presence. For big businesses like Danske Spil, this approach makes sense. Each channel is a unique source of revenue which otherwise would be lost. The Oddset application offers a better user experience then the web, but it is not necessarily one that is dependent on context of use and sensors on the phone. On the other hand, for cases like the OK app, which depend on GPS location, speed or other OS/device embedded features, it makes sense that they shouldn’t promote a web solution. They need to ﬁnd ways to drive people to use the mobile application.

Moreover, Philip would like to see more solutions trying to tackle this transition issue. One solution he sees is blurring or even removing the line between Web and native mobile applications. One approach would be allowing users to jump in the application directly from web, instead of going through the app stores for installation. The experience could also be enhanced if you could bring more context from the web experience in the application. For example, a user reading about a movie and installs a movie ticketing app (ex: Nordisk Film) is sent directly to the page of the movie he was looking at. There are some 3rd party solutions, but they are mostly work arounds, as there is no native functionality. Dropping the installing concept could be explored as well. Now, there is a hard distinction between something that is on the Web and an application you have downloaded from a store. This comes from an old world when you downloaded software. Keep the store, but don’t make it explicit. The native application world could improve its integration with the Web context.

The industry has done some steps towards solving this issue: instant apps and progressive module downloading. In the case of the former, Philips is not sure the approach took off.

(c) What about PWA? This is exactly what they are doing! Philip believes the experience is better in a native application. He believes that if it would be good enough on the web, then people wouldn’t need to switch from Web apps to applications. However, this is the behavior because they have a better experience when using the native applications. Consequently, what you want to do is to dive people as fast as possible in your native application context.

[Other comments] 6. Brief explanation of the research topic. After listening the research topic and direction, Philip added a couple more points.

Firstly, not all technologies make sense for everything. A lot of useless apps were built for things that should have never been an application. Therefore, he believes an important factor in the Appendix C. Interview - Philip Bruce 117

making the technology decision is ﬁguring out what is the product you are building.

Secondly, he believes that the choice for native is linked to how important is the application for the company. If it is close to the core of the company and drives the revenue, the native path should be chosen. If it is an information website or a marketing campaign, you should consider other channels (Web or even email could be a better format). Applications are something that you see evolving over years and they are tools used by your users on a regular basis. They carry your app in your pocket and makes them better or happier.

Thirdly, when choosing, one has to remember that the application format is costly to build and resource intensive to maintain. Therefore, you need a good business reason to do that (ex: driving revenue). According to Philip, most businesses can ﬁnd a relevant use case in the mobile context. People generally do more and more on their mobile and they also expect more from it. He believes that in the near future, people will expect be able to entirely replace the PC with the mobile device. At the end of the day, it is a matter of being able to fulﬁll all the tasks on mobile that you used to do on your computer (pay bills, inform yourself, etc.). 118

Appendix D

Interview - Christian Risom

General opinions on Mobile Web vs Hybrid vs Native approaches in Mobile Application development. Hybrid technology offers a series advantages quality-wise, but if chosen as a pillar for the company, it will have some limitations, that native does not. According to a cost and complexity graphic they use, when talking about hybrid and web solutions, as the complexity increases, the cost increases much more rapidly, than the cost of native. The starting cost of native is a bit higher than the other two, so if we are to talk about start-ups (or something in the ﬁrst quadrant), it makes sense to use react and fountain map, as you can always start over. Native is less expensive and more qualitative in the long term. It will have better support for new features and be more competitive. In the last 10 years things have change and you are competing with 3A+ products, therefore you cannot grab people’s attention with a low quality product, especially because they are so many options for them. Conclusion: you might get started quicker with the web based or react native, but if you have a long time horizon (5+ years) Major barriers are code management and the cost of maintaining everything. Deploying on 2 platforms means different teams confronting completely different problems to get to the same goal. It is not easier to do native just because there is one platform to concentrate on. It is faster with react native to get something out there as a trial, but it won’t have the same staying power. React native includes million dependencies on third party that manages speciﬁc components. For companies it’s not worth it to do products with less complexity and it is far more expensive to be down for a week than to run the product for a year. There are no issues with integration regarding the business side. Between hybrid and native is a cost and quality trade off and a maintenance over time a trade off. It’s not a lot from a business perspective, apart from maybe something with adoption of new features and adoption of new technologies from Apple and Google. The business side requires a good product and they do not really care how you make it. For example: Nemade launched a less qualitative product and got one star reviews and this is not good for the overall reputation.

What is the link between the technology constrains and the specificity of the industry? For example, should e-commerce treat the technological choice different than Oddset (gambling) and the gaming industry? Everything is different between smartphone and laptop. Especially the use that the customers have for each of them. The classic way of e-commerce for laptops is people opening a browser, typing something on Google and getting a catalog of stuff, for smartphone you’ve got to rethink the whole process. In order to create a full experience, you don’t have to adapt the process from the laptop to the smartphone but regard it as a completely different product. A download is more expensive Appendix D. Interview - Christian Risom 119 than a click on Google and it need to have a justification why the user should have an app on his smartphone rather than just on the laptop. The app for the smartphone needs to be able to reactive itself. It is not like searching cab on Google and getting a list, but going on your phone directly to the cab of your choice app. Product and process design is more important than how develop you mobile. If you want to sell one thing, it doesn’t make sense to build an app. B2B customer experience is optional, though it shouldn’t be. You have more room in B2B than B2C. At B2C you have to be at your absolute best, otherwise is not going to work. Quality of product is the most important thing in B2C businesses. Everything I told you here is just an assumption, no data, just experience. But it is hard to test, as it is very unlikely to have a react native and a native app running in parallel with exact same features. Shape always proposes a native solution to the clients and in favor of this they show the long time benefits. If you want the best, native is the only way to go. For the analysis, it is important that the client has access to the costs that will occur during the process. The balance of the industry is inclining towards native rather than hybrid or web. In the past it was equally divided. Progressive web apps are launched by Google. Google sends the signal that it doesn’t know where they see the future. It is the Flutter team, the progressive web app team, the core android team and they all are going in different directions. If Flutter reaches in the outsource community will it survive? If true cross platform will ever be achieved it will be either Google, Apple, or both of them. There will never be an incentive for Apple or Google to give up native and migrate to the other two. That’s when the developing dies. All the innovation comes out of software. So there is no strategic reason why you wouldn’t want to control your own platform. There are some other players as well like Huawei, but there are still too small and will not be able to build their own platform. Samsung and Apple are partners. People tend to look at them as competitors. The stream of money between them is giant. This way they are controlling the entire smartphone industry. At least something goes terribly wrong with Apple’s or Samsung’s management, they are in a very hard to beat position. For the next player, you need to look post-smartphone. If will ever get true, you will see more of Google and Apple meeting in the middle. The eco-system around native development is locked. For the next 5 years, just the two platforms. Google and Ap- ple are the most motivated to invest in the platforms, because they are already getting funds from the platforms. It is worth it investing in their eco-systems. It is a consumer problem that they are 2 platforms? They have two differentiate the products. 120

Appendix E

Interviews conducted at Google I/O 2019

E.1 I/O - Interview 1

Topic: Accessibility and the next billion users Topic description: Regardless of the size of the company, great accessibility standards can be achieved using some rules and practices when developing applications. Interview type: Informal interview Expert area of expertise: Enabling application and business developers to make the app more accessible for everyone and everywhere.

Discussion summary: 1. Why should a business care about accessibility when developing a mobile application? There are more then 1 billion people in the world that have accessibility related issues (different types of disabilities). This is a huge opportunity to extend your user base. Consequently, there is a strong revenue potential. Furthermore, it is important to understand the types of accessibility issues: (a) Situational disability – the context in which the application is used generates a temporary disability of the user to engage in normal conditions with the application. This can happen due to a medical intervention (ex: eye surgery), due to weather conditions (ex: sunlight), due to environmental noise or other similar situations. In these cases, the quality of use is affected for the user. (b) Permanent disability – for example visually impaired, death, immobile, with speaking issues. People with accessibility issues have a different navigation and engagement patterns than the default users. Moreover, oftentimes if you tackle the issues faced by one user category you partially solve the problems encountered by other categories as well. This is because the issues overlap. 2. What can be done in mobile applications in order to improve accessibility? There are many ways in which designers and developers can tackle these issues: • Implement talk-back feature – the application responds to user actions using verbal queues. • Implement accessibility labels which respect the usability rules. • Localize the application messages and provide descriptions for these messages. • Design and implement the visual layer (ex: images) in a way that allows people with visual impediments to use the application. Otherwise it is like it is not present in the application for this category of users. This can be solved using labels and captions for images that could be verbalized. • Allow for other interaction means (ex: eye tracking) Appendix E. Interviews conducted at Google I/O 2019 121

• Collect data about the context of use, understand it and adapt to it. The context of use is related both to the device related issues (ex: model, UI, user navigation patterns) but also the environment. • Respect accessibility guidelines when deﬁning the text size. • There are many OS build in systems that help you address accessibility issues. 3. Which environment is more suitable for delivering an accessibility friendly service, Web or mobile applications? In their opinion, there is no default superior environment. It all depends on the context of use, the user type and the issues that affect the interaction. By analyzing these aspects, the more appropriate channel can be identiﬁed and used.

E.2 I/O - Interview 2

Topic: Material Design Components (Web / iOS / Cross-platform - Flutter) Topic description: The topic addresses the design of reliable workﬂows and principles around mobile design. Interview type: Informal Expert area of expertise: Cross-platform experts on Material Design and Material Design Compo- nents.

Discussion summary: 1. How does Flutter answer to the differences of OS platforms (Android and iOS)? Flutter is a unique framework due to its UI rendering process. The way in which Flutter paints its visual components directly on the device canvas, makes it more flexible then other technologies. Flutter allows developers to describe the UI behavior and visual only once, and the underlying framework is in charge of translating it to platform specific navigation patterns and UI components. However, some of the platform specific components are not yet supported (ex: Slider UI component). This happens mainly because these components behave differently on the two platforms (Android and iOS). The Flutter development team is now working to incorporate these in the default components package as well. In order to allow the implementation of iOS specific designs, they enable developers to use native UI components using the Cupertino library. This way, when developers implement the UI, they can fork the UI design based on the underlying platform (Android or iOS). This should ideally happen in isolated cases, where the material design components are not sufficient enough. However, in extreme cases (especially when you develop for both native platforms and for Web, aiming to cover various device layouts) the code can have forks. For now, Cupertino library does not follow the material design guidelines. The interviewees also pointed out that material design is a different concept and approach than platform design. Material design is not Android design. They said that material design wants to be a set of well researched guidelines which are grounded in universal user experience and behavior on mobile devices. This is why, they believe these rules should apply to any mobile platform. Another consequence of this, is that material design guidelines try to allow a large degree of customizability when they are applied. 2. How different do they see the two platform designs are going? In the past the two platforms where considerably more different. They started borrowing from each other useful patterns (ex: the “Pull to refresh” behavior). However, platform differences still exist, but the technology used to develop applications (native iOS, native Android, React, Flutter) is not so important. It Appendix E. Interviews conducted at Google I/O 2019 122

is more about a design philosophy and how does the designer decide to design the application. You can use a technology that does not respect native UX/UI patterns and still have success (ex: Facebook application). Therefore, the design process a core factor in the success of the application.

E.3 Google I/O - Interview 3

Topic: Web technology capabilities Topic description: How does web work on mobile and how can these capabilities be accessed. In- terview type: Informal discussion Expert area of expertise (Pete LePage): Developer advocate on the Web team at Google. In charge with deﬁning, creating and pushing for Web standards.

Discussion summary: 1. Can PWAs (Progressive Web Applications) be delivered on mobile in a mobile application container? Yes, using trusted activities and the “Electron” open source framework that allows to wrap the web application in a native application. As electron is open source and is owned by the community, the development is not keeping up with the latest native developments. 2. The Unlocking New Capabilities for the Web session talked about the latest mobile features which have been developed / are in development on Chrome. What about the other mobile browsers, how good are they at adopting them? Most of them are rather good. However, the browser fragmentation is indeed a problem. Espe- cially with differences that appear between Safari and Chrome. (a) What is the browser feature development process? It is rather an individual process, where each browser starts supporting a new feature and if the community asks for it, others will develop it as well. Moreover, sometimes implementation may differ on different browsers. This results in compatibility issues between browses which forces application developers to make browser speciﬁc implementations. 3. App stores provide some valuable analytics information to application owners. What can be done on the web in that sense? Analytics works on the Web as well. You can record user behavior, user background and identify user context. This requires however developer implementation. You can also track app performance like how fast it loads or how big the application is.

E.4 Google I/O - Interview 4

Topic: Flutter discussion Topic description: Understanding how ﬂutter applications are built. Interview type: Informal discussion Expert area of expertise (Andre Brogdon): senior engineer on the developer relations team for Flut- ter.

Discussion summary: Appendix E. Interviews conducted at Google I/O 2019 123

1. What is the use case for Flutter over Web and Native? In order to answer this question, it is important to know how Flutter was created. Most of the team working on the framework is made of former web developers. They felt that building efﬁ- cient user interfaces was rather costly on web due to the amount of markup language required. They also felt web was not enough in terms of the user experience capabilities it can deliver. However, native development is rather long and complex. This is where they wanted to make a difference with Flutter. Take the high interactive nature of the native platform and the porta- bility of the web technology and reunite them under a single technology. One advantage of the Framework is that it develops hand in hand with the Dart language. This means that Flutter team can make requests to the Dart team to provide supporting features in the language. This alignment makes the development of the Framework more agile and responsive. 2. Who does he see as competitors of Flutter? When they design Flutter, they took a lot of inspiration from React Native. Furthermore, he points out that all platform constantly borrow architectures, UX or implementation approaches from each other. 3. What are the Flutter ecosystem pain points at the moments? The community is still young, and people are ﬁnding it hard to get motivated to learn yet again a new language and platform. Generally, once they do it, they are happy with it. But switching to something new is hard. 4. What is the future of Flutter? How does Google distribute it’s resources between mobile development frameworks? Will the three paradigms (native, cross-platform, web) continue in parallel? Google projects, including Flutter development is driven by community needs. The future is tied to how well the ecosystem will develop. The more Flutter applications and developers are, the more leverage the Flutter project will have when negotiating management support. Google understands that different developers have different needs and resources. So, it wants to offer suitable tools to resolve match them. At the end of the day, he could not predict how the three frameworks will evolve. It all depends what will be the community needs. 124

Appendix F

Summary of relevant presentations part of Google I/O 2019

F.1 Conference Session 1: “Beyond Mobile: Material Design, Adaptable UIs and Flutter”

• Topic description: How to use the Material design library together with the Cupertino library in Flutter, while adapting the application to various screens, interaction models and viewing distances. • Data collection type: Presentation • Presentation owners: Will Larche (Lead Flutter engineer on Material Design Team) and Anthony Robledo (Flutter engineer with experience in Google infrastructure, cloud and search) Presentation summary:

F.2 Conference Session 2: “Building Successful Websites: Case Studies for Mature and Emerging Markets“

• Topic description: A set of 3 presentations from Twitter, Hulu and Times Internet on how they employed Web technology to achieve a broader reach, meaningful engagement and business impact. • Data collection type: Presentation • Presentation owners: Charlie Croom (Twitter Web Tech Lead), Matt Doyle (Hulu Product Manager on streaming service), Rudra Kasturi (Head of organic revenue growth) Presentation summary:

F.3 Conference Session 3: “Building for iOS with Flutter”

: • Topic description: How to use Flutter’s Cupertino library to build iOS interfaces. How to keep the code on Flutter under control. How to access iOS platform APIs from Flutter app. • Data collection type: Presentation • Presentation owners: Andrew Brogdon (Senior Engineer on the developer relations team for Flutter) and Brett Morgan (In charge of creating developer support for Flutter) Presentation summary:

F.4 Conference Session 4: “App Growth Best Practices and Decision-Making with the Google Play Console”

• Topic description: Understanding how mobile app competition works and what are the tools Google Play Console gives application owners to gain a competitive edge. • Data collection type: Presentation • Presentation owners: Adam Carpenter (Lead of Developer Business Growth Team), Corina Grigoras (Software engineer on Play Console), Tom Grinsted (Product manager on the Google Appendix F. Summary of relevant presentations part of Google I/O 2019 125

Play Console), Fergus Hurley (Google Product manager on Tools that allow developers to improve user experience) Presentation summary:

F.5 Conference Session 5: “Unlocking new capabilities for the Web”

• Topic description: A review of the latest web mobile capabilities on the Chrome browser. • Data collection type: Presentation • Presentation owners: Pete LePage (Developer advocate on the Google Web team) and Thomas Steiner (Developer advocate at Google Hamburg) Presentation summary:

F.6 Conference Session 6: “Build Fast and Smooth Web Apps from Fea- ture Phone to Desktop”

• Topic description: Understanding Feature Phone unique challenges and requirements for Web Technology • Data collection type: Presentation • Presentation owner: Mariko Kosaka (Handles relationship between Chrome and Web Developer Ecosystem) Presentation summary:

F.7 Conference Session 7: “Build Apps for the Next Billion Users”

• Topic description: Understanding the unique challenges of the emerging Android markets (ex: Africa and Asia) and what can be done in order to tackle them. • Data collection type: Presentation • Presentation owners: Rajeev Humar, Yacine Rezgui (Developer) and Amrit Sanjeev (Developer advocate for Indian developer community) Presentation summary: 126 Appendix G. Android Software Stack 127

Appendix G

Android Software Stack

FIGURE G.1: Android Software Stack (Source: Android Developers Ofﬁcial Documen- tation [117]) 128

Bibliography

[1] M A. Fishbein and Icek Ajzen. Belief, attitude, intention and behaviour: An introduction to theory and research. Vol. 27. May 1975. [2] Ruadhan O’Donoghue Michel Shuqair Marco Tabor Alex Repty Julian Harty Vikram Kri- planey Cornelius Kwietniak Alex Jonsson Oscar Clark Dean Churchill Neil Cook Daniel Böhrs Sally Cain Davoc Bradley Ian Thain Marc van’t Veer Robert Virkus Mladenka Vrdoljak Aaron Ardiri Andrej Balaz. “Don’t Panic: Mobile Developer’s Guide to the Galaxy”. In: Open-Xchange, Oct. 2017. [3] Ashraf Abdulmunim. “Mobile Web Browsers in Android Deriving Reference Architecture”. In: International Journal of Computer Applications 180 (Jan. 2018), pp. 17–22. DOI: 10 . 5120 / ijca2018916284. [4] Gediminas Adomavicius et al. “Technology roles and paths of inﬂuence in an ecosystem model of technology evolution”. In: Information Technology and Management 8 (June 2007), pp. 185–202. DOI: 10.1007/s10799-007-0012-z. [5] Gediminas Adomavicius et al. “Understanding Evolution in Technology Ecosystems”. In: Commun. ACM 51 (Oct. 2008), pp. 117–122. DOI: 10.1145/1400181.1400207. [6] Ville Ahti, Sami Hyrynsalmi, and Olli Nevalainen. “An Evaluation Framework for Cross- Platform Mobile App Development Tools: A case analysis of Adobe PhoneGap framework”. In: June 2016. DOI: 10.1145/2983468.2983484. [7] Icek Ajzen. “The theory of planned behavior”. In: Organizational Behavior and Human Decision Processes 50.2 (1991). Theories of Cognitive Self-Regulation, pp. 179 –211. ISSN: 0749-5978. DOI: https://doi.org/10.1016/0749-5978(91)90020-T. URL: http://www.sciencedirect.com/ science/article/pii/074959789190020T. [8] J. D. Lasica Thomas Power Andrzej Targosz Alex Barrera Rob Barton. HOW NOT TO DE- SIGN APPS! YOUR GUIDE TO A SUCCESSFUL BUSINESS IN 2016. 2010. URL: http : / / coders-mill.com/book2-download/Coders_Mill_Trends_in_mobile_apps.pdf (visited on 05/30/2019). [9] Mohamed Ali and Ali Mesbah. “Mining and Characterizing Hybrid Apps”. In: Proceedings of the International Workshop on App Market Analytics. WAMA 2016. Seattle, WA, USA: ACM, 2016, pp. 50–56. ISBN: 978-1-4503-4398-5. DOI: 10.1145/2993259.2993263. URL: http://doi. acm.org/10.1145/2993259.2993263. [10] Fazal e Amin. “Characterization of web browser usage on smartphones”. In: Computers in Human Behavior 51 (2015). Computing for Human Learning, Behaviour and Collaboration in the Social and Mobile Networks Era, pp. 896 –902. ISSN: 0747-5632. DOI: https://doi.org/ 10.1016/j.chb.2014.10.054. URL: http://www.sciencedirect.com/science/article/pii/ S0747563214005846. [11] AppAnnie. State of Mobile 2019 Report. Jan. 2019. URL: https://www.appannie.com/en/about/ press/releases/app-annie-releases-annual-state-of-mobile-2019-report/ (visited on 05/02/2019). BIBLIOGRAPHY 129

[12] T. Ater. Building Progressive Web Apps: Bringing the Power of Native to the Browser. O’Reilly Media, 2017. ISBN: 9781491961650. URL: https://books.google.dk/books?id=z4PxvQAACAAJ. [13] Nuri Basoglu, Tugrul Daim, and Ebru Polat. “Exploring Adaptivity in Service Development: The Case of Mobile Platforms”. In: Journal of Product Innovation Management 31.3 (), pp. 501– 515. DOI: 10.1111/jpim.12110. eprint: https://onlinelibrary.wiley.com/doi/pdf/10. 1111/jpim.12110. URL: https://onlinelibrary.wiley.com/doi/abs/10.1111/jpim.12110. [14] Rahul Basole and Jürgen Karla. “Value Transformation in the Mobile Service Ecosystem: A Study of App Store Emergence and Growth”. In: Service Science 4 (Mar. 2012), pp. 24–41. DOI: 10.1287/serv.1120.0004. [15] Rahul C Basole. “Visualization of interfirm relations in a converging mobile ecosystem”. In: Journal of Information Technology 24.2 (June 2009), 144–159. ISSN: 1466-4437. DOI: {10.1057/ jit.2008.34}. URL: {https://doi.org/10.1057/jit.2008.34}. [16] A. Becker et al. “Evolving Taxonomy of Business Models for Mobile Service Delivery Plat- form”. In: Procedia Computer Science 10 (2012). ANT 2012 and MobiWIS 2012, pp. 650 –657. ISSN: 1877-0509. DOI: https : / / doi . org / 10 . 1016 / j . procs . 2012 . 06 . 083. URL: http : //www.sciencedirect.com/science/article/pii/S1877050912004401. [17] Abdelkrim Benamar, Lamia Gaouar, and Fethi Tarik Bendimerad. “Requirements of cross platform mobile development tools”. In: Oct. 2014. [18] Guus Berkhout and Patrick van der Duin. “Mobile Data Innovation: Lucio and the Cyclic Innovation Model”. In: Proceedings of the 6th International Conference on Electronic Commerce. ICEC ’04. Delft, The Netherlands: ACM, 2004, pp. 603–608. ISBN: 1-58113-930-6. DOI: 10.1145/ 1052220.1052297. URL: http://doi.acm.org/10.1145/1052220.1052297. [19] Katie Bessière et al. “A model for computer frustration: the role of instrumental and dispo- sitional factors on incident, session, and post-session frustration and mood”. In: Computers in Human Behavior 22.6 (2006), pp. 941 –961. ISSN: 0747-5632. DOI: https://doi.org/10. 1016/j.chb.2004.03.015. URL: http://www.sciencedirect.com/science/article/pii/ S0747563204000615. [20] Anol Bhattacherjee. “Understanding Information Systems Continuance: An Expectation-Confirmation Model”. In: MIS Quarterly 25 (Sept. 2001), pp. 351–370. DOI: 10.2307/3250921. [21] Andreas Biørn-Hansen, Tim A. Majchrzak, and Tor-Morten Grønli. “Progressive Web Apps for the Unified Development of Mobile Applications”. In: Web Information Systems and Tech- nologies. Ed. by Tim A. Majchrzak et al. Cham: Springer International Publishing, 2018, pp. 64– 86. ISBN: 978-3-319-93527-0. [22] Andreas Biørn-Hansen and Gheorghita Ghinea. “Bridging the Gap: Investigating Device- Feature Exposure in Cross-Platform Development”. In: Jan. 2018. DOI: 10.24251/HICSS.2018. 716. [23] Andreas Biørn-Hansen, Tor-Morten Grønli, and Gheorghita Ghinea. “A Survey and Taxon- omy of Core Concepts and Research Challenges in Cross-Platform Mobile Development”. In: ACM Computing Surveys 51 (Nov. 2018), pp. 1–34. DOI: 10.1145/3241739. [24] Andreas Biørn-Hansen et al. “An Empirical Study of Cross-Platform Mobile Development in Industry”. In: Wireless Communications and Mobile Computing 2019 (Jan. 2019), pp. 1–12. DOI: 10.1155/2019/5743892. [25] Alexander Brem and Kai-Ingo Voigt. “Innovation Management in Emerging Technology Ven- tures - The Concept of an Integrated Idea Management”. In: International Journal of Technology, Policy and Management 7 (Nov. 2007). DOI: 10.1504/IJTPM.2007.015113. BIBLIOGRAPHY 130

[26] Grazia Cecere, Nicoletta Corrocher, and Riccardo David Battaglia. “Innovation and competition in the smartphone industry: Is there a dominant design?” In: Telecommunications Policy 39.3 (2015). New empirical approaches to telecommunications economics: Opportunities and challenges Mobile phone data and geographic modelling, pp. 162 –175. ISSN: 0308-5961. DOI: https://doi.org/10.1016/j.telpol.2014.07.002. URL: http://www.sciencedirect.com/ science/article/pii/S0308596114001189. [27] Andre Charland and Brian LeRoux. “Mobile Application Development: Web vs. Native”. In: Queue 9.4 (Apr. 2011), 20:20–20:28. ISSN: 1542-7730. DOI: 10.1145/1966989. 1968203. URL: http://doi.acm.org/10.1145/1966989.1968203. [28] Shin-Horng Chen and Pei-Chang Wen. “The Evolution of China’s Mobile Phone Industry and Good-Enough Innovation”. In: Feb. 2016, pp. 261–282. ISBN: 978–0–19–875356–8. DOI: 10. 1093/acprof:oso/9780198753568.003.0010. [29] Chu Yan and Huang Lihua. “Mobile business applications adoption model based on the concepts of task/technology fit”. In: Proceedings of ICSSSM ’05. 2005 International Conference on Services Systems and Services Management, 2005. Vol. 2. 2005, 1346–1350 Vol. 2. DOI: 10.1109/ ICSSSM.2005.1500217. [30] Matteo Ciman and Ombretta Gaggi. “An empirical analysis of energy consumption of cross- platform frameworks for mobile development”. In: Pervasive and Mobile Computing 39 (Oct. 2016). DOI: 10.1016/j.pmcj.2016.10.004. [31] Simon FORGE Colin BLACKMAN. 5G Deployment - State of Play in Europe, USA and Asia. Tech. rep. European Parliament, Policy Department for Economic, Scientific and Quality of Life Policies, Apr. 2019. [32] Jeffery D. Wilfong. “Computer anxiety and anger: The impact of computer use, computer experience, and self-efficacy beliefs”. In: Computers in Human Behavior 22 (Nov. 2006), pp. 1001– 1011. DOI: 10.1016/j.chb.2004.03.020. [33] Fred Davis. “A Technology Acceptance Model for Empirically Testing New End-User Infor- mation Systems”. In: (Jan. 1985). [34] Fred D. Davis. “Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Infor- mation Technology”. In: MIS Quarterly 13.3 (1989), pp. 319–340. ISSN: 02767783. URL: http: //www.jstor.org/stable/249008. [35] Fred D. Davis and Viswanath Venkatesh. “A critical assessment of potential measurement biases in the technology acceptance model: three experiments”. In: International Journal of Human-Computer Studies 45.1 (1996), pp. 19 –45. ISSN: 1071-5819. DOI: https : / / doi . org / 10.1006/ijhc.1996.0040. URL: http://www.sciencedirect.com/science/article/pii/ S1071581996900403. [36] DeviceAtlas Mobile Web Intelligence Report. Tech. rep. DEviceAtlas, Feb. 2019. [37] Dynatrace. A 2018 Global CIO Report. Tech. rep. 2018. [38] Ben Eaton et al. “Distributed Tuning of Boundary Resources: The Case of Apple’s iOS Service System”. In: MIS Q. 39.1 (Mar. 2015), pp. 217–244. ISSN: 0276-7783. DOI: 10.25300/MISQ/2015/ 39.1.10. URL: https://doi.org/10.25300/MISQ/2015/39.1.10. [39] Michel Ehrenhard et al. “Unlocking how start-ups create business value with mobile applications: Development of an App-enabled Business Innovation Cycle”. In: Technological Forecast- ing and Social Change 115 (2017), pp. 26 –36. ISSN: 0040-1625. DOI: https://doi.org/10.1016/ j.techfore.2016.09.011. URL: http://www.sciencedirect.com/science/article/pii/ S004016251630292X. BIBLIOGRAPHY 131

[40] Wafaa S. El-Kassas et al. “Taxonomy of Cross-Platform Mobile Applications Development Approaches”. In: Ain Shams Engineering Journal 8.2 (2017), pp. 163 –190. ISSN: 2090-4479. DOI: https://doi.org/10.1016/j.asej.2015.08.004. URL: http://www.sciencedirect.com/ science/article/pii/S2090447915001276. [41] Ergonomics of human system interaction - part 210: Human-centred design for interactive systems. Standard. Geneva, CH: International Organization for Standardization, 2010. [42] Ericsson Mobility Report. Tech. rep. Ericsson, June 2018. [43] Dynatrace director for Mobile Solution Marketing Erwan Paccard. Holiday shopping report. 2010. URL: https : / / www . dynatrace . com / news / blog / coming - back - to - the - digital - future/ (visited on 05/30/2019). [44] Claudio Feijóo et al. “Exploring a heterogeneous and fragmented digital ecosystem: Mobile content”. In: Telematics and Informatics 26 (Aug. 2009), pp. 282–292. DOI: 10.1016/j.tele. 2008.11.009. [45] João Fernandes and Andre Ferreira. “Quality Attributes for Mobile Applications”. In: Jan. 2016, pp. 141–154. DOI: 10.4018/978-1-4666-9916-8.ch008. [46] Kim Flaherty. How Channels, Devices, and Touchpoints Impact the Customer Journey. 2016. URL: https://www.nngroup.com/articles/channels-devices-touchpoints/ (visited on 05/14/2019). [47] Brian Fling. Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps - Animal Guide. 1st. O’Reilly Media, Inc., 2009. ISBN: 0596155441, 9780596155445. [48] Harleen Flora and Swati Chande. “A Review and Analysis on Mobile Application Develop- ment Processes using Agile Methodologies”. In: International Journal of Research in Computer Science 3 (July 2013), p. 8. DOI: 10.7815/ijorcs.34.2013.068. [49] Francesco Nachira. Towards a Network of Digital Business Ecosystems Fostering the Local Develop- ment. http://www.digital-ecosystems.org/. Online; accessed 15 May 2018. 2002. [50] R. Francese et al. “Mobile App Development and Management: Results from a Qualitative Investigation”. In: 2017 IEEE/ACM 4th International Conference on Mobile Software Engineering and Systems (MOBILESoft). 2017, pp. 133–143. DOI: 10.1109/MOBILESoft.2017.33. [51] Madira N. Gamage. “Adaptation of Near Field Communication (NFC) Technology to En- hance the Operational Efﬁciency and Performance of Pre-departure Operations of Airlinesi”. In: Journal of Electronic Systems 5 (Mar. 2016). [52] Julien Gamba et al. An Analysis of Pre-installed Android Software. 2019. arXiv: 1905 . 02713 [cs.CR]. [53] Lamia Gaouar, Abdelkrim Benamar, and Fethi Tarik Bendimerad. “Desirable Requirements of Cross Platform Mobile Development Tools”. In: 2016. [54] David Garvin. “What Does “Product Quality” Really Mean?” In: MIT Sloan Management Re- view 26 (Oct. 1984), pp. 25–43. [55] Judith Gebauer and Michael J. Shaw. “Success Factors and Impacts of Mobile Business Ap- plications: Results from a Mobile e-Procurement Study”. In: International Journal of Electronic Commerce 8.3 (2004), pp. 19–41. DOI: 10.1080/10864415.2004.11044304. eprint: https:// doi.org/10.1080/10864415.2004.11044304. URL: https://doi.org/10.1080/10864415. 2004.11044304. [56] StatCounter GlobalStats. Mobile Operating System Market Share Worldwide. 2019. URL: http: //gs.statcounter.com/os-market-share/mobile/worldwide/#monthly-201804-201904- bar (visited on 05/18/2019). BIBLIOGRAPHY 132

[57] Andreas Goeldi. The Smartphone Revolution: Why the App Store Was More Important Than the iPhone. 2018. URL: https://innospective.net/the-smartphone-revolution-why-the-appstore-was-more-important-than-the-iphone/ (visited on 05/14/2019). [58] Göran Goldkuhl. “Separation or unity? Behavioral science vs. design science”. In: Dec. 2016. [59] Zahaira González Romo, Ruth Contreras Espinosa, and Irene García Medina. “Branded Apps in Spain as a Means of Communicating Trends in Fashion”. In: International Journal of Interac- tive Mobile Technologies (iJIM) 10 (Apr. 2016), p. 58. DOI: 10.3991/ijim.v10i2.5558. [60] Shirley Gregor. “The Nature of Theory in Information Systems”. In: MIS Quarterly 30.3 (2006), pp. 611–642. ISSN: 02767783. URL: http://www.jstor.org/stable/25148742. [61] Ha Ngoc Anh. Smartphone Industry: The new Era of Competition and strategy. https://www. theseus.fi/bitstream/handle/10024/119385/FinalthesisHNA.pdf?sequence=1&isAllowed= y. Online; accessed 01 May 2018. 2016. [62] Bidyut Hazarika et al. In: (Jan. 2015). [63] Stefan Henningsson and Jonas Hedman. “Technology-based Transformation of Digital Ecosys- tems: The DETT Framework”. In: CONF-IRM 2014 Proceedings, Dec. 2014. URL: https:// aisel.aisnet.org/confirm2014/15. [64] Alan Hevner et al. “Design Science in Information Systems Research”. In: Management Infor- mation Systems Quarterly 28 (Mar. 2004), pp. 75–. [65] JERRY HILDENBRAND. Inside the different Android Versions. 2019. URL: https://www.androidcentral. com/android-versions (visited on 05/18/2019). [66] Ute Hillmer. Technology acceptance in mechatronics: The inﬂuence of identity on technology acceptance. Jan. 2009, pp. 9–26. DOI: 10.1007/978-3-8349-8375-6. [67] Adrian Holzer and Jan Ondrus. “Mobile application market: A developer’s perspective”. In: Telematics and Informatics 28.1 (2011). Mobile Service Architecture and Middleware, pp. 22 – 31. ISSN: 0736-5853. DOI: https://doi.org/10.1016/j.tele.2010.05.006. URL: http: //www.sciencedirect.com/science/article/pii/S0736585310000377. [68] D.A. Hume and A. Osmani. Progressive Web Apps. Manning Publications, 2017. ISBN: 9781617294587. URL: https://books.google.dk/books?id=5TddMQAACAAJ. [69] Marco Iansiti and Roy Levien. The keystone advantage: what the new dynamics of business ecosystems mean for strategy, innovation, and sustainability. Harvard Business Press, 2004. [70] IBM. Native, web or hybrid mobile-app development. Tech. rep. IBM Software, Apr. 2012. [71] Sergio Ilarri et al. “A Review of the Role of Sensors in Mobile Context-Aware Recommenda- tion Systems”. In: International Journal of Distributed Sensor Networks 2015 (Nov. 2015), pp. 1–30. DOI: 10.1155/2015/489264. [72] Darrel Ince. software developer’s kit. Jan. 2013. URL: https://www.oxfordreference.com/view/ 10.1093/acref/9780191744150.001.0001/acref-9780191744150-e-2991. [73] “iProﬁt: The mobile-phone market”. English. In: The Economist (Online) (Feb. 2011). Copyright - (Copyright 2011 The Economist Newspaper Ltd. All rights reserved.; Last updated - 2011- 06-04. URL: https://search.proquest.com/docview/851303709?accountid=8144. [74] Bala Iyer and Thomas Davenport. “Reverse Engineering Google’s Innovation Machine”. In: Harvard business review 86 (Apr. 2008). [75] Sirkka Jarvenpaa and Karl Lang. “Managing the Paradoxes of Mobile Technology”. In: IS Management 22 (Sept. 2005), pp. 7–23. DOI: 10.1201/1078.10580530/45520.22.4.20050901/ 90026.2. BIBLIOGRAPHY 133

[76] Chuck Jones. Apple Continues To Dominate The Smartphone Profit Pool. Mar. 2018. URL: https: //www.forbes.com/sites/chuckjones/2018/03/02/apple-continues-to-dominate-the- smartphone-profit-pool/#d12f1e161bb7 (visited on 05/18/2019). [77] Keyur K Patel et al. “Internet of Things-IOT: Definition, Characteristics, Architecture, En- abling Technologies, Application & Future Challenges”. In: (May 2016). [78] Christian Karasiewicz. SWOT analysis: Hybrid versus native development in IBM Worklight. Apr. 2014. URL: https://www.w3.org/Consortium/activities (visited on 05/25/2019). [79] B. Kitchenham and S. L. Pfleeger. “Software quality: the elusive target [special issues section]”. In: IEEE Software 13.1 (1996), pp. 12–21. ISSN: 0740-7459. DOI: 10.1109/52.476281. [80] Gérard Koenig. “Business Ecosystems Revisited”. In: Journal of Business and Management Sci- ences 15.2 (2012), p. 209. URL: http://pubs.sciepub.com/jbms/3/2/4. [81] Thomas L. Rakestraw, Rangamohan V. Eunni, and Rammohan Kasuganti. “The mobile apps industry: A case study”. In: Journal of Business Cases and Applications The mobile apps industry (Sept. 2013), pp. 74–98. [82] Mohamed Lachgar and ABDALI Abdelmounaïm. “Decision Framework for Mobile Develop- ment Methods”. In: International Journal of Advanced Computer Science and Applications 8 (Feb. 2017). DOI: 10.14569/IJACSA.2017.080215. [83] P C Lai. “THE LITERATURE REVIEW OF TECHNOLOGY ADOPTION MODELS AND THE- ORIES FOR THE NOVELTY TECHNOLOGY”. In: Journal of Information Systems and Technology Management 14 (Apr. 2017), pp. 21–38. DOI: 10.4301/s1807-17752017000100002. [84] Mounaim Latif et al. “Cross platform approach for mobile application development: A survey”. In: Mar. 2016, pp. 1–5. DOI: 10.1109/IT4OD.2016.7479278. [85] S. L. Lim et al. “Investigating Country Differences in Mobile App User Behavior and Chal- lenges for Software Engineering”. In: IEEE Transactions on Software Engineering 41.1 (2015), pp. 40–64. ISSN: 0098-5589. DOI: 10.1109/TSE.2014.2360674. [86] Tim A. Majchrzak and Tor-Morten Grønli. “Comprehensive Analysis of Innovative Cross- Platform App Development Frameworks”. In: HICSS. 2017. [87] Ivano Malavolta et al. “Hybrid Mobile Apps in the Google Play Store: An Exploratory Inves- tigation”. In: Aug. 2015. DOI: 10.1109/MobileSoft.2015.15. [88] Iliyan Malchev. Here comes Treble: A modular base for Android. 2017. URL: https://android- developers . googleblog . com / 2017 / 05 / here - comes - treble - modular - base - for . html (visited on 05/18/2019). [89] Anshul Malik, S. Suresh, and Swati Sharma. “Factors influencing consumers’ attitude towards adoption and continuous use of mobile applications: a conceptual model”. In: Procedia Com- puter Science 122 (2017). 5th International Conference on Information Technology and Quan- titative Management, ITQM 2017, pp. 106 –113. ISSN: 1877-0509. DOI: https://doi.org/10. 1016/j.procs.2017.11.348. URL: http://www.sciencedirect.com/science/article/pii/ S1877050917325772. [90] Andrea Marcano. “Capacity Dimensioning for 5G Mobile Heterogeneous Networks”. In: 2018. [91] Popa Marius. “Considerations Regarding the Cross-Platform Mobile Application Develop- ment Process”. In: ECONOMY INFORMATICS JOURNAL 13 (Sept. 2013), pp. 40 –52. [92] Liisa Marjamaa-Mankinen. “Technology ecosystems and digital business ecosystems for business”. Master’s Thesis. University of Oulu, Faculty of Information Technology and Electrical Engineering, 2016. BIBLIOGRAPHY 134

[93] M. Markova and A. Aula. “Conceptualizing How Usability of Mobile Services Affects Busi- ness Performance”. In: International Conference on the Management of Mobile Business (ICMB 2007). 2007, pp. 36–36. DOI: 10.1109/ICMB.2007.24. [94] Markus Huber Manuel Leithner Edgar Weippl Martin Mulazzani Philipp Reschl. Fast and Efficient Browser Identification with JavaScript Engine Fingerprinting. Tech. rep. SBA Research, Feb. 2013. [95] Pablo Iacopino Mayuran Sivakumaran. The Mobile Economy. Tech. rep. GSMA Intelligence, Feb. 2018. [96] Janet R. McColl-Kennedy et al. “Fresh perspectives on customer experience”. In: Journal of Services Marketing 29.6/7 (2015), pp. 430–435. DOI: 10 . 1108 / JSM - 01 - 2015 - 0054. eprint: https://doi.org/10.1108/JSM-01-2015-0054. URL: https://doi.org/10.1108/JSM-01- 2015-0054. [97] Jeff McWherter and Scott Gowell. Professional Mobile Application Development. 1st. Birming- ham, UK, UK: Wrox Press Ltd., 2012. ISBN: 1118203909, 9781118203903. [98] Sacha Greif Michael Rambeau Raphael Benitte. The State of JavaScript 2018. Oct. 2018. URL: https://2018.stateofjs.com/mobile-and-desktop/overview/ (visited on 05/27/2019). [99] Alexander G. Mirnig et al. “A Formal Analysis of the ISO 9241-210 Definition of User Experi- ence”. In: Proceedings of the 33rd Annual ACM Conference Extended Abstracts on Human Factors in Computing Systems. CHI EA ’15. Seoul, Republic of Korea: ACM, 2015, pp. 437–450. ISBN: 978-1-4503-3146-3. DOI: 10.1145/2702613.2732511. URL: http://doi.acm.org/10.1145/ 2702613.2732511. [100] Shahab Mokarizadeh, M.T. Rahman, and Mihhail Matskin. “Mining and analysis of apps in google play”. In: (Jan. 2013), pp. 527–535. [101] Johnna Montgomerie and Samuel Roscoe. “Owning the consumer–Getting to the core of the Apple business model”. English. In: 37 (2013), pp. 290–299. ISSN: 0155-9982. DOI: 10.1016/j. accfor.2013.06.003. [102] James F Moore. The death of competition: leadership and strategy in the age of business ecosystems. HarperBusiness New York, 1996. [103] Katherine N. Lemon and Peter Verhoef. “Understanding Customer Experience throughout the Customer Journey 1”. In: Journal of Marketing 80 (June 2016). DOI: 10.1509/jm.15.0420. [104] Ngu Phuc Huy and Do van Thanh. “Selecting the right mobile app paradigms”. In: 2012 Fifth IEEE International Conference on Service-Oriented Computing and Applications (SOCA). Dec. 2012, pp. 1–6. DOI: 10.1109/SOCA.2012.6449450. [105] Duyen Nguyen. “Understanding perceived enjoyment and continuance intention in mobile games”. en. G2 Pro gradu, diplomityö. 2015, p. 58. URL: http://urn.fi/URN:NBN:fi:aalto- 201511054897. [106] Alex Nicolaou. “Best Practices on the Move: Building Web Apps for Mobile Devices”. In: Queue 11 (June 2013). DOI: 10.1145/2493944.2507894. [107] E. Noei et al. “A study of the relation of mobile device attributes with the user-perceived quality of Android apps (journal-first abstract)”. In: 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). 2018, pp. 469–469. DOI: 10.1109/ SANER.2018.8330235. BIBLIOGRAPHY 135

[108] Keng-Boon Ooi and Garry Wei-Han Tan. “Mobile technology acceptance model: An investigation using mobile users to explore smartphone credit card”. In: Expert Systems with Applications 59 (2016), pp. 33 –46. ISSN: 0957-4174. DOI: https://doi.org/10.1016/j.eswa.2016.04.015. URL: http://www.sciencedirect.com/science/article/pii/S0957417416301816. [109] Riley Panko. THE STATE OF TECH - Mobile App Usage Statistics 2018. Mar. 2018. URL: https: //themanifest.com/app- development/mobile- app- usage- statistics- 2018 (visited on 05/02/2019). [110] Hugo Pardo Kuklinski, Brandt Joel, and Juan Pablo Puerta. “Mobile Web 2.0. Theoretical- technical framework and developing trends.” In: International Journal of Interactive Mobile Tech- nologies (iJIM) 2 (Oct. 2008). [111] Geoffrey Parker, Marshall Van Alstyne, and Xiaoyue Jiang. “PLATFORM ECOSYSTEMS: HOW DEVELOPERS INVERT THE FIRM.” In: MIS Quarterly 41.1 (2017), 255 –A4. ISSN: 02767783. URL: http://search.ebscohost.com.zorac.aub.aau.dk/login.aspx?direct=true&db= buh&AN=121204231&site=ehost-live. [112] The United States Patent and Trademark Office. Distinction Between Design and Utility Patents. 2015. URL: https : / / www . uspto . gov / web / offices / pac / mpep / s1502 . html (visited on 05/18/2019). [113] Joachim Perchat, Mikael Desertot, and Sylvain Lecomte. “Component based Framework to Create Mobile Cross-platform Applications”. In: Procedia Computer Science 19 (2013). The 4th International Conference on Ambient Systems, Networks and Technologies (ANT 2013), the 3rd International Conference on Sustainable Energy Information Technology (SEIT-2013), pp. 1004 –1011. ISSN: 1877-0509. DOI: https://doi.org/10.1016/j.procs.2013.06.140. URL: http: //www.sciencedirect.com/science/article/pii/S1877050913007485. [114] Gerald R. Salancik Pfeffer Jeffrey. The External Control of Organizations: A Resource Dependence. Méthodes et recherches. Harper and Row, 2003. ISBN: 9780804747899, 9780804767187. [115] Naincie Pindeh, Norbayah Mohd Suki, and Norazah Mohd Suki. “User Acceptance on Mobile Apps as an Effective Medium to Learn Kadazandusun Language”. In: Procedia Economics and Finance 37 (2016). The Fifth International Conference on Marketing and Retailing (5th INCO- MaR) 2015, pp. 372 –378. ISSN: 2212-5671. DOI: https://doi.org/10.1016/S2212-5671(16) 30139-3. URL: http://www.sciencedirect.com/science/article/pii/S2212567116301393. [116] B Pine II and JH Gilmore. “The Experience Economy”. In: Harvard business review 76 (Nov. 1998), pp. 176–+. [117] Platform Architecture. 2019. URL: https://developer.android.com/guide/platform (visited on 05/18/2019). [118] Guy Podjarni. Performance Implications on Mobile Design. 2012. URL: https://www.slideshare. net/guypod/performance-implications-of-mobile-design (visited on 05/02/2019). [119] Anna Pollock and Leon Benjamin. “Shifting Sands: The Tourism Ecosystem in Transforma- tion”. In: (May 2001). [120] Australian Department of the Premier and Office of Digital Government Cabinet. Digital services - definitions and examples. 2018. URL: https://www.wa.gov.au/government/publications/ digital-services-definitions-and-examples (visited on 05/14/2019). [121] Oxford University Press. Oxford Dictionaries. 2019. URL: https://en.oxforddictionaries. com/thesaurus/smart (visited on 05/13/2019). BIBLIOGRAPHY 136

[122] Pradeep Racherla, Christopher Furner, and Jeffry Babb. “Conceptualizing the Implications of Mobile App Usage and Stickiness: A Research Agenda”. In: SSRN Electronic Journal (Dec. 2012). DOI: 10.2139/ssrn.2187056. [123] C. P. Rahul Raj and Seshu Babu Tolety. “A study on approaches to build cross-platform mobile applications and criteria to select appropriate approach”. In: 2012 Annual IEEE India Conference (INDICON). Dec. 2012, pp. 625–629. DOI: 10.1109/INDCON.2012.6420693. [124] Thomas Renner. “Mobile OS-Features , Concepts and Challenges for Enterprise Environments”. In: 2011. [125] Christoph Rieger and Tim A. Majchrzak. “Conquering the Mobile Device Jungle: Towards a Taxonomy for App-enabled Devices”. In: Jan. 2017, pp. 332–339. DOI: 10.5220/0006353003320339. [126] Rachel Sandler. How the iPhone changed the telecommunications industry. 2017. URL: https://eu. usatoday.com/story/tech/news/2017/07/04/how-iphone-changed-telecommunications- industry/103154146/ (visited on 05/14/2019). [127] Muhammad Sarwar and Tariq Soomro. “Impact of Smartphone’s on Society”. In: European Journal of Scientific Research 98 (Feb. 2013). [128] Andre Schwager and Chris Meyer. “Understanding Customer Experience”. In: Harvard Busi- ness Review. (Feb. 2007). [129] Carlos Scolari, Juan Aguado, and Claudio Feijóo. “Mobile Media: Towards a Definition and Taxonomy of Contents and Applications”. In: International Journal of Interactive Mobile Tech- nologies (iJIM) 6 (Apr. 2012). DOI: 10.3991/ijim.v6i2.1880. [130] Prof. Mark Sherriff. Mobile Application Development. Sept. 2018. URL: https://cs4720.cs. virginia.edu/slides/CS4720-MAD-iOSArchitecture.pdf. [131] Hee-Chan Song. “Analysis of the global smartphone market and the strategies of its major players”. In: 2011. [132] Thierry Isckia Yvon Pesqueux Soumaya Ben Letaifa Anne Gratacap. Understanding Business Ecosystems: How Firms Succeed in the New World of Convergence? Méthodes et recherches. De Boeck Superieur, 2013. ISBN: 2804176762, 9782804176761. [133] Alisha Stein and B. Ramaseshan. “Towards the identification of customer experience touch point elements”. In: Journal of Retailing and Consumer Services 30 (2016), pp. 8 –19. ISSN: 0969- 6989. DOI: https://doi.org/10.1016/j.jretconser.2015.12.001. URL: http://www. sciencedirect.com/science/article/pii/S0969698915301855. [134] Dr. Balgopal Singh Suman Jain. “Evolution Pattern of Mobile Phones - A Historical Study”. In: The SIJ Transactions on Industrial, Financial & Business Management (IFBM) 4, No. 5 (July 2016), p. 6. [135] Kyle Taylor and Laura Silver. Smartphone Ownership Is Growing Rapidly Around the World, but Not Always Equally. Tech. rep. Pew Research Center, Feb. 2019. [136] Shirley Taylor and Peter A. Todd. “Todd, P.: Understanding Information Technology Usage: A Test of Competing Models. Information Systems Research 6(2), 144-176”. In: Information Systems Research 6 (June 1995), pp. 144–176. DOI: 10.1287/isre.6.2.144. [137] Fedor Tcymbal. Project Treble. What Makes Android 8 different? Aug. 2018. URL: https : / / events.linuxfoundation.org/wp- content/uploads/2017/11/Project- Treble.- What- Makes-Android-8-Different_-Fedor-Tcymbal-Mera-Software-Services.pdf (visited on 05/18/2019). BIBLIOGRAPHY 137

[138] TechTerms. Smartphone definition. 2010. URL: https://techterms.com/definition/smartphone (visited on 05/13/2019). [139] Anurag Tewari and Paarth Sareen. “Platform Business Models and Mobile Ecosystem”. In: Apr. 2014. DOI: 10.13140/2.1.1371.9367. [140] The App Economy in the United States. Tech. rep. Deloitte - Microeconomics, Aug. 2018. [141] James Y.L. Thong, Se-Joon Hong, and Kar Yan Tam. “The effects of post-adoption beliefs on the expectation-confirmation model for information technology continuance”. In: International Journal of Human-Computer Studies 64.9 (2006), pp. 799 –810. ISSN: 1071-5819. DOI: https:// doi.org/10.1016/j.ijhcs.2006.05.001. URL: http://www.sciencedirect.com/science/ article/pii/S1071581906000772. [142] Wesley Fenlon & Bernadette Johnson Tracy V. Wilson Nathan Chandler. How the iPhone Works. 2007. URL: https://electronics.howstuffworks.com/iphone14.html (visited on 05/14/2019). [143] Thomas Tullis and William Albert. Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics: Second Edition. Jan. 2008. ISBN: 0123735580. [144] Eric Umuhoza and Marco Brambilla. “Model Driven Development Approaches for Mobile Applications: A Survey”. In: Mobile Web and Intelligent Information Systems. Ed. by Muham- mad Younas et al. Cham: Springer International Publishing, 2016, pp. 93–107. ISBN: 978-3-319- 44215-0. [145] Stephen Vargo and Robert Lusch. “Evolving to a New Dominant Logic”. In: Journal of Market- ing 68 (Jan. 2004), pp. 1–17. DOI: 10.1509/jmkg.68.1.1.24036. [146] Viswanath Venkatesh and Hillol Bala. “Technology Acceptance Model 3 and a Research Agenda on Interventions”. In: Decision Sciences - DECISION SCI 39 (May 2008), pp. 273–315. DOI: 10.1111/j.1540-5915.2008.00192.x. [147] Viswanath Venkatesh and Fred Davis. “A Theoretical Extension of the Technology Acceptance Model: Four Longitudinal Field Studies”. In: Management Science 46 (Feb. 2000), pp. 186–204. DOI: 10.1287/mnsc.46.2.186.11926. [148] Viswanath Venkatesh et al. “User Acceptance of Information Technology: Toward a Unified View”. In: MIS Quarterly 27 (Sept. 2003), pp. 425–478. DOI: 10.2307/30036540. [149] Raymond Allan G. Vergara. “Samsung Electronics and Apple, Inc.: A Study in Contrast in Vertical Integration in the 21st Century”. In: American International Journal of Contemporary Research 2 (Sept. 2012). [150] Tedo Vrbanec, Nenad Kirić,and Matija Varga. “The evolution of web browser architecture”. In: Preecedings of the 1st International Virtual Conference on Advanced Scientific Results (SCIECONF- 2013) (Jan. 2013), pp. 472–480. [151] World Wide Web Consortium (W3C). W3C - Working Groups activity. 2019. URL: https://www. w3.org/Consortium/activities (visited on 05/20/2019). [152] Yang Wang. KaiOS - The Birth of the Smart Feature Phone Revolution. 2019. URL: https : / / www . kaiostech . com / the - birth - of - the - smart - feature - phone - revolution/ (visited on 05/18/2019). [153] Joel West and David Wood. “Creating and Evolving an Open Innovation Ecosystem: Lessons from Symbian Ltd.” In: SSRN Electronic Journal (July 2008). DOI: 10.2139/ssrn.1532926. [154] M. Willocx, J. Vossaert, and V. Naessens. “A Quantitative Assessment of Performance in Mo- bile App Development Tools”. In: 2015 IEEE International Conference on Mobile Services. 2015, pp. 454–461. DOI: 10.1109/MobServ.2015.68. BIBLIOGRAPHY 138

[155] Michiel Willocx, Jan Vossaert, and Vincent Naessens. “Comparing performance parameters of mobile app development strategies”. In: May 2016, pp. 38–47. DOI: 10 . 1145 / 2897073 . 2897092. [156] Xiaobo Wu et al. “A Review of Mobile Commerce Consumers' Behaviour Research: Consumer Acceptance, Loyalty and Continuance (2000-2009)” in: Int. J. Mob. Commun. 8.5 (Aug. 2010), pp. 528–560. ISSN: 1470-949X. DOI: 10.1504/IJMC.2010.034936. URL: http://dx.doi.org/10.1504/IJMC.2010.034936. [157] T. Yamakami. “Mobile application platform strategies: business model engineering for the data intensive mobile age”. In: International Conference on Mobile Business (ICMB’05). July 2005, pp. 333–339. DOI: 10.1109/ICMB.2005.62. [158] Toshihiko Yamakami. “A cognitively meaningful digital ecosystem approach: Implications for mobile digital ecosystem”. In: 5th IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2011) (2011), pp. 203–207. [159] Nivadit Acharya Yuvraj Sharma Bharat Kumar Dak. “Emerging trends in mobile apps market and their potential impact on mobile users engagement in the global economy”. In: Annual Research Journal of Symbiosis Centre for Management Studies, Pune Vol. (2017), pp. 61 –81. [160] Jing Zhang and Xiong-Jian Liang. “Business ecosystem strategies of mobile network operators in the 3G era: The case of China Mobile”. In: Telecommunications Policy 35.2 (2011), pp. 156 – 171. ISSN: 0308-5961. DOI: https://doi.org/10.1016/j.telpol.2010.12.009. URL: http: //www.sciencedirect.com/science/article/pii/S0308596110001485. [161] Pei Zheng and Lionel Ni. “Introduction to Smart Phone and Mobile Computing”. In: Smart Phone and Next Generation Mobile Computing (Dec. 2006), pp. 1–21. DOI: 10 . 1016 / B978 - 012088560-2/50003-4. [162] Tao Zhou. “An empirical examination of users’ post-adoption behaviour of mobile services”. In: Behaviour & Information Technology 30.2 (2011), pp. 241–250. DOI: 10.1080/0144929X.2010. 543702. eprint: https://doi.org/10.1080/0144929X.2010.543702. URL: https://doi.org/ 10.1080/0144929X.2010.543702. [163] Hengshu Zhu et al. “Exploiting Enriched Contextual Information for Mobile App Classiﬁca- tion”. In: Proceedings of the 21st ACM International Conference on Information and Knowledge Man- agement. CIKM ’12. Maui, Hawaii, USA: ACM, 2012, pp. 1617–1621. ISBN: 978-1-4503-1156-4. DOI: 10.1145/2396761.2398484. URL: http://doi.acm.org.zorac.aub.aau.dk/10.1145/ 2396761.2398484. [164] Y. Zhu and V. J. Reddi. “WebCore: Architectural support for mobile Web browsing”. In: 2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA). June 2014, pp. 541– 552. DOI: 10.1109/ISCA.2014.6853239.