App Portability with Smart Devices a Case Study from Ios to Tvos

Home , Craig Federighi, IOS 8, IOS 9, Smart device, Software portability

DEGREE PROJECT IN TECHNOLOGY, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2016

App portability with smart devices A case study from iOS to tvOS

LINNEA KYLÉN RÖNNQVIST

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

Abstract

Nowadays, there are many different devices that a software developer needs to consider - a program might be present both on computer, mobile, tablet and wearables. As new smart device platforms are frequently introduced, firms want to leverage new opportunities that arise. Thus, firms can create new apps or port their existing ones. Recently, Apple presented an updated version of their Apple TV, and announced that apps will also be available on that platform. This thesis investigates how a productivity app implemented for Apple’s mobile operating system (iOS) can be ported to and refined for the new Apple TV operating system (tvOS). Further, the thesis investigates the problems of app portability that arise when porting between smart devices. A case study was performed where a specific app was ported from iOS to tvOS, using the new programming language Swift. First, the app was ported with a naive approach, with focus on source portability and minimum porting cost. Thereafter, the app was ported using a refined approach, to make it more appropriate for the targeted platform. Related literature, such as app portability, smart TV and smart device research was investigated to give a more thorough understanding, and to identify additional problems regarding app portability. The thesis presents the porting process, as well as the identified app portability problems when porting between smart devices: choice of programming paradigm, vendor specific APIs, platform limitations, data storage and migration, context of use, navigation and interaction, portability- versus-UX, project and team aspects and quick evolvement in the area. Lastly, it is discussed whether the apps should be ported at all, or rather reimagined to leverage new platforms with new opportunities. Further research is needed to verify the findings on other platforms, and to see whether cross-platform tools (e.g. web technologies) can be used also in the smart device domain (not only mobile-to-mobile).

Keywords Apps, portability, smart devices, smart TV, tvOS, iOS, platforms, software development. Abstract

Det finns numera många olika enheter som en mjukvaruutvecklare be- höver ha i åtanke – ett program kan förekomma både på datorn, i mobilen, på surplattan och i klockan. Eftersom det kontinuerligt introduceras nya smarta enheter, är det troligt att företag kommer vilja nyttja de nya möj- ligheterna som uppstår. Således kan företag skapa nya program eller porta sina befintliga till de nya miljöerna. Apple presenterade nyligen en ny version av sin Apple TV, och med- delade att appar nu även kommer finnas för nedladdning på denna platt- form. Denna uppsats undersöker hur en produktivitetsapp skapad för Ap- ples mobila operativsystem (iOS) kan portas och förfinas för det nya Apple TV-operativsystemet (tvOS). Dessutom undersöks de problem relaterade till app-portabilitet som uppstår vid portning mellan smarta enheter. En fallstudie genomfördes där en viss app portades från iOS till tvOS med det nya programmeringsspråket Swift. Först portades appen med ett naivt angreppssätt, där fokus låg på källkodsportabilitet och minimala portningskostnader. Därefter portades appen med ett förfinat angreppssätt för att göra den lämpligare för den avsedda plattformen. Relaterad litter- atur, såsom forskning kring app-portabilitet, smart TV:s och smarta enheter, undersöktes för att ge en djupare förståelse och för att identifiera ytterligare problem gällande app-portabilitet. Uppsatsen presenterar portningsprocessen, samt de identifierade app- portatbilitetsproblemen vid portning mellan smarta enheter: valet av pro- grammeringsparadigm, leverantörsspecifika API:er, plattformsbegrän- sningar, datalagring och migration av data, användarkontext, naviger- ing och interaktion, portabilitet-kontra-användarupplevelse, projekt- och team-aspekter, samt den snabba utvecklingen inom området. Slutligen diskuteras huruvida apparna borde portas över huvud taget, eller om de hellre borde omskapas från noll för att optimalt kunna utnyttja de nya plattformarnas möjligheter. Ytterligare forskning krävs för att verifiera resultaten på andra platt- formar, och för att se om plattformsoberoende verktyg (exempelvis webb- teknologier) kan var till nytta även när man ser till smarta enheter (till skillnad från bara mobil-till-mobil).

Nyckelord Appar, portabilitet, smarta enheter, smart TV, tvOS, iOS, platt- formar, mjukvaruutveckling. Acknowledgements

Firstly, I would like to thank my advisors at KTH Royal Institute of Technology, Leif Lindbäck and Fadil Galjic. They have provided valuable insights and feedback during the entirety of the thesis work. Secondly, I would like to thank my husband, David Rönnqvist, who has endured yet another education and thesis process of mine. Finally, after 20 years of schooling, it is time to exit school for good.

Contents

1 Introduction 1 1.1 Background ...... 1 1.2 Problem ...... 1 1.3 Purpose ...... 2 1.4 Delimitations ...... 3 1.5 Outline ...... 3

2 Theoretical background 5 2.1 Operating systems - iOS and tvOS ...... 5 2.1.1 iOS ...... 6 2.1.2 tvOS ...... 6 2.1.3 Comparison ...... 7 2.2 Smart devices and the role of the TV ...... 7 2.2.1 The role of the TV ...... 8 2.2.2 Wearables ...... 8 2.2.3 Overview of smart device and smart TV research ..... 9 2.3 Application portability ...... 11 2.3.1 Software portability ...... 11 2.3.2 Overview of application portability research ...... 12 2.3.3 Mobile portability ...... 14 2.3.4 Overview of mobile portability research ...... 15 2.4 Porting and application portability: Definition ...... 17 2.4.1 Measurement ...... 17 2.4.2 Context ...... 18

3 Methodology 19 3.1 Research approach ...... 19 3.1.1 Quantitative and qualitative methods ...... 19 3.1.2 Inductive and deductive methods ...... 19 3.1.3 Case studies ...... 20 3.1.4 Adopted research approach ...... 20 3.2 Outline of research process ...... 20 3.2.1 Literature study ...... 20 3.2.2 Case study: Phase 1 ...... 21 3.2.3 Case study: Phase 2 ...... 21 3.2.4 Generalizations ...... 22 3.3 Data collection methods ...... 22 3.3.1 Literature study and platform research ...... 22

i 3.3.2 Observations from the porting experiments ...... 22 3.4 Portability measures ...... 23 3.4.1 Lines of code ...... 23 3.4.2 Work hours ...... 23 3.5 Software development - tools and methods ...... 24 3.5.1 Software design process: An iterative approach . . . . . 24 3.5.2 Development environment ...... 24 3.5.3 Programming language and paradigm ...... 24

4 The iOS app and conditions for its porting 27 4.1 App functionality and structure ...... 27 4.1.1 Functionality ...... 27 4.1.2 Core Data model, persistent storage and the cloud . . . . 27 4.1.3 Application structure ...... 28 4.2 Demonstration of the iOS app ...... 30 4.3 Conditions for porting ...... 35 4.4 Advantages and drawbacks ...... 35

5 Case study: Porting to tvOS 37 5.1 Phase 1: A naive port to tvOS ...... 37 5.1.1 Creating a target and making the app runnable ...... 37 5.1.2 Setting up the storyboard ...... 38 5.1.3 Adjusting the focus ...... 39 5.1.4 Making a date picker ...... 40 5.1.5 Up and running ...... 43 5.2 Evaluation and research ...... 43 5.2.1 Testing on device ...... 43 5.2.2 Areas for improvement ...... 47 5.3 Phase 2: Refining and redesigning the app ...... 47 5.3.1 Implementing key-value storage and sync with iCloud . . 48 5.3.2 Refining the navigation and storyboard (with tab bar and collection view) ...... 48 5.3.3 Focus ...... 48 5.3.4 Sizes, spacing and colors ...... 48 5.3.5 Text input and play/pause buttons ...... 49

6 Case study: Results 51 6.1 Phase 1: The naive port ...... 51 6.2 Phase 2: The refined port ...... 52 6.3 Portability measures ...... 53 6.3.1 Lines of code ...... 53 6.3.2 Work hours ...... 54 6.4 Demonstration of the app from Phase 1 ...... 55 6.5 Demonstration of the app from Phase 2 ...... 61

7 Case study: Interpretation and generalization 67 7.1 Analysis of portability types and measures ...... 67 7.1.1 Binary portability ...... 67 7.1.2 Source portability, and portability of specification & design 67 7.1.3 Revisiting the portability model ...... 68 ii 7.1.4 Architectural portability ...... 68 7.2 Comparing the case study approaches ...... 69 7.2.1 Why the naive approach is inappropriate ...... 69 7.2.2 Experience portability ...... 70 7.2.3 Summary of concerns ...... 71 7.3 Portability problems with smart devices ...... 71 7.3.1 Programming paradigm and programming language . . 71 7.3.2 Vendor lock-in ...... 71 7.3.3 Platform limitations ...... 72 7.3.4 Data storage and migration ...... 72 7.3.5 Context of use ...... 72 7.3.6 Navigation and interaction model ...... 73 7.3.7 UX, UI and performance ...... 73 7.3.8 Project and team aspects ...... 74 7.3.9 Quick evolvement ...... 74 7.3.10 Redeveloping the app ...... 74

8 Discussion 77 8.1 Methods and their implications for the study ...... 77 8.1.1 Initial portability ...... 77 8.1.2 Vendor specific API:s ...... 77 8.1.3 Validity and Reliability ...... 78 8.2 Revisiting the research questions ...... 79 8.3 Sustainability ...... 80 8.3.1 Portability and sustainability ...... 81 8.3.2 Smart devices and sustainability ...... 81

9 Conclusions 83 9.1 Summary ...... 83 9.2 Implications ...... 83 9.3 Future research ...... 84

Bibliography 85

A Investigated blogs and news articles 91

iii List of abbreviations and concepts

Android Google’s mobile operating system App Short for application. Especially referring to those for smart devices CEO Chief executive officer Core Data A framework used for the model layer and persistent storage DTV Digital TV HIG Human interface guidelines iCloud Apple’s cloud-based services and storage IDE Integrated development environment I/O Input/output iOS Apple’s mobile operating system IoT Internet of things. A research area built on connectivity of devices. iTunes A digital media library and player provided by Apple, associated with the iTunes Store iTunes Store Apple’s online store with music, movies, TV shows, podcasts, books, apps and other digital media LOC Lines of code MVC Model-View-Controller, an architectural software design pattern OS Operating system OS X The operating system for Macintosh computers Performance Execution and loading times are important quality aspects for smart device apps. E.g. when loading the app, a screen or data SDK Software development kit Stack Overflow A community for programming questions TVML Apple’s Television Markup Language tvOS Apple’s operating system for the new Apple TV Ubiquity Expresses that something is “present everywhere” UI User interface UX User experience Xcode Apple’s IDE for OS X, iOS and tvOS applications

iv Chapter 1

Introduction

In recent years, there has been an increased focus on Smart, such as “Smart devices, Smartphones, Smart cars, Smart homes, Smart cities - A smart world.” [52, p. 3] Several research fields, including Internet of things (IoT) and mobile computing - but also computer science and computer engineering in general - try to achieve these smart technologies, and it is suggested that in the future it “will affect every aspect of all our lives”. [52, p. 4] Apple revolutionized the market for smartphones in 2007, by the release of iPhone [32]. iPhone brought a promise of a “real Internet”, and thereby a better web browsing experience on a phone, as well as leveraged Apple’s existing music and video services (iTunes) [59][32]. Thanks to a successful market- ing campaign, hype, and price cut, Apple was able to sell a million iPhones in the first 74 days. [23][59] Since then, Apple has been adding several devices to their product portfolio, including the iPad in 2010 and the Apple Watch in 2015. [60] Similarly, competitors like Google are also expanding their portfolios, providing operating systems (Android) for devices like phones, tablets, wearables, TVs and cars. [2]

1.1 Background

The first Apple TV was released already in 2007 and enabled users to stream/sync their iTunes content from a Mac or PC to their living room TV. The device was later updated (2008) to allow for direct communication with the iTunes Store - without an intermediate computer. [61] In september 2015 Apple introduced a fourth generation of Apple TV – with a new remote, a new operating system (tvOS) and a separate app store for just that platform. [61] CEO Tim Cook then presented the company’s vision: “The future of TV is apps”. [6] With this new device and operating system, developers are provided with API:s and allowed to create their own apps that they can submit to the app store. [61]

1.2 Problem

With each new platform, there are opportunities for new applications. Some of these apps might be entirely new products - whereas many companies already have products on other competing or complimentary platforms. Thus,

1 it is likely that firms would want to port or redevelop their applications to take advantage of a new platform and its user base. [51] With the fragmentation in the mobile applications market and continuous introduction of mobile and smart devices, app portability becomes a significant challenge (and cost) for developers and firms. [26] This thesis focuses on issues of app portability in an era of smart devices. The Apple TV platform provides opportunities for developers to develop and recreate the TV as a concept and to use the new technologies in innovative ways. tvOS is developed from iOS, the operating system for Apple’s mobile devices (iPhone and iPad), and therefore share a significant amount of API:s and technologies - with some adaptions to the new platform. [4] This means that developers can either create new apps or port their existing iOS apps to the TV. Questions arise around which apps should be provided on the new TV platform - is there room for more than traditional entertainment apps like video, music and gaming apps? For example, if a company or independent developer has created a productivity or utility app - would it be sensible to make an app also for the TV and what should it include? Further, when making such a decision - how extensive is the process of porting the program and what steps are involved? This thesis assumes that porting of productivity and utility apps is meaningful, and focus on the problem of porting a specific app from the iOS platform to the tvOS platform. The research questions investigated in this thesis are thus:

RQ1. What problems of app portability arise when porting between smart devices? RQ2. How can a productivity app implemented on iOS be ported and refined for tvOS?

1.3 Purpose

The purpose of the thesis is to present a complete app porting process, and the problems that arise when porting between smart devices. It uses a case study where the process of porting an existing iOS app to a tvOS app is investigated, documented and analyzed to learn more about the problems with app portability. It discusses the considerations and problems encountered throughout the development process. The goal of the thesis is to provide a basis for other developers - as well as in- spiration - to extend their applications and leverage new platforms. When performing such development, problems regarding app portability need to be considered and handled. This thesis addresses these problems, which is achieved by exploring the tvOS platform and documenting the process of porting an existing mobile app to the new platform - in terms of steps to be taken and problems that arises. The outcomes of this project are relevant for smart device developers - to speed up the development process and by thinking through the problems before starting to port an app to a specific platform. The thesis also suggests a broader view of the TV - with different types of apps it can become more than a simple entertainment system. For more advanced developers, this provides

2 the basis to reimagine the role of the TV - and thus provides opportunities for making new and interesting apps or extensions.

1.4 Delimitations

As suggested by Jain and Aula, there can be several interesting topics regarding the design of the TV experience [36]. For example, they suggest research into what apps are meaningful in the living room and how to design for the user experience and interaction with the TV [36]. This thesis discusses some of these aspects - but only in terms of their relevance for the app portability and porting process. There will be no focus on investigating the user experiences, preferences or expectations regarding the tvOS platform per se. Especially - with the limited time frame of the project - no user studies or user tests will be conducted to validate the user interface. Rather, the thesis will rely on smart TV research and Human interface guidelines (HIG) for the platform. Further, Punt et al. investigate and suggest a framework for the concept of TV-centric gaming, using smart phones or tablets as second screens to provide a shared and interactive environment for multiplayer games [47]. Like many authors they focus on the TV as primarily being an entertainment device [36][47]. In this thesis, the view of the TV as only an entertainment device is challenged - and it instead focuses on productivity and utility apps - since such apps are common on mobile platforms. This seems as a reasonable focus given that the new operating system (tvOS) is built on and similar to the mobile operating system (iOS).

1.5 Outline

The thesis is outlined as follows; In section 2 the theoretical background is presented. Thus, the investigated platforms (iOS and tvOS), and the research areas of app portability, smart devices, and smart TVs are covered in depth. Further, application portability and porting are defined, and portability measures as well as the context of smart devices are discussed. In section 3, the research approach and methods used in the thesis are presented. This includes the outline of the research process, the discussion of data collection and software development methods, and explanation of the two formulas that will be used for calculating portability. Section 4 presents the original iOS app, including the functionality and application structure. Further, the conditions for porting the app are specified, and some advantages and drawbacks (for the porting process) are discussed. Section 5 describes the complete process of porting the app, i.e the case study. The case study is performed in two phases with an intermediate stage of evaluation and platform research. Section 6 presents the results of the case study; focusing on the porting process, the portability measures and the resulting apps from each phase. Section 7 interprets the results and generalizes, based on the case study findings and investigation of the app portability, smart device and smart TV literature. Portability measures and the case study phases are analyzed, and portability problems with smart devices are identified.

3 Section 8 discusses the methods, their implications, and the ethical and sustainability aspects, as well as answers the research questions. Finally, section 9 summarizes the main conclusions of the thesis and discuss the implications and directions for future research.

4 Chapter 2

Theoretical background

This chapter covers the theoretical background of the thesis. The theoretical foundation consists of the investigated platforms (iOS and tvOS), smart device and smart TV research, as well as app portability research. The theoretical foundation is illustrated in Figure 2.1.

Figure 2.1: Theoretical foundation based on platforms, smart devices and smart tv, and app portability.

2.1 Operating systems - iOS and tvOS

An operating system (OS) constitutes an intermediate layer between the software applications and the hardware in a computer system. It is a software component that gives access to hardware (Input/Output, memory etc.) and provide resources and services. Applications written for a computer system typically requires an OS to operate, as it provides the basis for program execution, memory management, file system management, networking, security and user interfaces. [63]

5 2.1.1 iOS iOS is the operating system for Apple’s mobile devices - the iPhone, iPad and iPod touch. It was developed from the OS X operating system for Macintosh computers, and therefore share some frameworks and concepts. However, it is adapted to the mobile environment, for example by providing a different user interface toolkit, Cocoa Touch.[62] iOS consist of four architectural layers, the Cocoa Touch layer (UI and app infrastructure), the Media layer (graphics, audio and video), the Core Services (system services and frameworks) and the Core OS (low-level, e.g. hardware access, security). Figure 2.2 shows the layers of iOS. The iOS software development kit (SDK) can be used to create native apps for iOS devices, that can be sold on Apple’s App Store for iOS (included in iTunes). [17] Native apps can be written in Objective-C or Swift.

Figure 2.2: iOS architectural layers.

2.1.2 tvOS tvOS is the operating system for the fourth generation of Apple TV. tvOS is based on iOS but constitutes a distinct OS. [4] tvOS relies on a slimmed down version of Cocoa Touch, to leverage the UIKit and MapKit frameworks. It also provides its own TVMLKit framework. Like iOS, tvOS is divided into the four architectural layers presented in Figure 2.2.[20] tvOS allows for third party apps in a specific App store on the TV. This is new and came with the operating system (tvOS) compared to earlier genera- tions of Apple TV. [61] The tvOS SDK allows for two main ways of developing apps: using Apple’s new Television Markup Language (TVML) to create page-based client-server apps or using the native approach to develop apps in Objective-C or Swift (with iOS-based frameworks). TVML is focused on templates to provide a consistent user experience and enable developers to easily present their content to users. It is supported by Javascript API:s to provide interaction and application logic. [24] Native apps have more possibilities for customization and to leverage all the features available on the TV. With the native approach is it also possible to take advantage of the skills acquired from previous iOS development, while the

6 TVML approach might be suitable for developers skilled in web development for iOS1.[24]

2.1.3 Comparison Table 2.1 shows a comparison of contemporary iPhone and Apple TV technical specifications. One of the main differences between iOS and tvOS is the user interaction model. iOS users can interact directly with a touch screen, while Apple TV users are dependent on a remote for their interaction. Another difference is the more restrictive size limitations regarding the TV apps compared to iOS apps, even though the storage capabilities on the devices are similar. [5] Even if the app stores for iOS and tvOS are separate, the same apps can be sold on both platforms:

“Although iOS and tvOS apps are distinct entities (meaning there isn’t a single binary that runs on both platforms), you can create a universal purchase that bundles these apps. The user purchases an app once, and gets the iOS version for their iOS devices and a tvOS version for Apple TV.” [4]

iPhone 6s Apple TV Processor 64-bit A9 chip 64-bit A8 chip Storage 16 GB, 64 GB or 128 GB 32 GB or 64 GB RAM 2 GB 2 GB Resolution 1334 x 750 1920 x 1080 Interaction 3D Touch display Remote App size limit 4GB 200 MB Persistent storage - 500 KB/app Native apps Objective-C and Swift Objective-C and Swift Web/hybrid apps Browser/Web views TVML and JavaScript App distribution App store (iTunes) App store (on Apple TV)

Table 2.1: Comparison of iPhone 6s and Apple TV (4th generation) technical specifications. [4][19][54][58]

2.2 Smart devices and the role of the TV

This section covers recent developments in the area of smart devices and smart TV research. For the sake of this thesis, smart devices will refer to interactive and connected devices, such as smartphones, tablets, smart TVs and smart watches (wearables), running apps and an operating system. [64] For clarity, desktop computers and laptops are explicitly excluded into its own domain. Similarly, smart TVs will refer to connected and interactive TVs that can run apps and other media (by use of an operating system included in the television or an external device). [65]

1Which is often incorporated using web views (on iOS).

7 2.2.1 The role of the TV Punt et al. present a development framework for distributed social gaming - with connected devices such as smartphones, tablets and digital TVs (DTVs). They argue that the DTVs provide new opportunities - the TV is no longer a passive form of entertainment, it can be used for active and interactive forms of game play and information acquirement. The TV is a natural gathering point for family and friends and can therefore be used for social games as a shared resource - controlled by each persons private screen and control - their mobile device. [47]

2.2.1.1 A “second screen” The notion of a “second screen” in the living room - that is, using a mobile device while the TV is running, is discussed by several researchers [47][66]. Wilson challenges the traditional view of TV audience and the social experience of watching together in a leaned back fashion. Rather, the TV is becoming a more complex experience as more and more screens and devices are present and the user is simultaneously interacting with these devices in a private or social manner - using them to interact with the TV or others inside or outside the room (for example tweeting, reading emails). [66]

2.2.1.2 Context, connection and interaction Miraoui et al. investigate smart spaces (specifically a smart living room), where the user’s context should be taken into account to provide adaptable services [43]. They argue that smart devices should be used together to provide smarter services to the user. They show how machine learning can be used to provide adaptation mechanisms for devices in a living room. Their research aims to improve quality of life by having smart spaces that adjust the devices without human intervention. Jain et al. suggest new research topics regarding the living room experience with smart TV:s. [36] Some of the issues they point out are how to design for a different context, interaction and consumption. They also suggest that the use and interaction patterns might change as TV:s get smarter and more interconnected.

2.2.1.3 User experiences and user interfaces Loi combine field work and user experience (UX) design expertise to inform TV development and suggest new interaction and navigation patterns. [40] She argues that users show higher expectations regarding the user interfaces for digital TV applications compared to other devices, which meant that they needed to look for more sophisticated solutions during the UI design work.

2.2.2 Wearables Another category of smart devices which is currently discussed is different types of wearables. Rawassizadeh et al. discuss the feasibility of smartwatches. Because smartwatches are kept on the wrist, it imposes restrictions on their size. This in turn leads to limited computing and input/output capabilities.

8 Especially, the restrictions on user interaction, such as entering text, and media display are mentioned. While voice input can remedy some of the problems, it is not suitable in all situations. It is also under discussion whether smartwatches will be stand-alone computing devices or just act as convenient user interfaces for smartphones. The main advantage for smartwatches is the constant connection with the owner, which can provide additional health and location data compared to other smart devices. [48]

2.2.3 Overview of smart device and smart TV research Table 2.2 summarizes the articles regarding smart device and smart TV research, for the interested reader.

9 Article Research area Theories Methods Relevant findings Punt et al. Distributed social Second screeen, Development of a distributed New interactive and active opportu- 2014 gaming, “TV- human-computer game development framework nites with connected DTVs. The TV centric gaming” interaction, cloud for Android devices, and five can be used a shared resource and con- computing games to evaluate the frame- trolled by other devices, such as smart- work. phones. Wilson 2016 TV audiences and Second screen, Explorative study. Interviews Leaned-forward versus leaned-back the living room ex- companion apps, with families regarding the liv- view of TV users. Multiple screens perience TV audiences ing room experiences. increase the complexity of the interaction and experience. Social and private aspects. Miraoui et Smart living Smart spaces, Two machine learning methods Smart devices should be seen as inter- al. 2014 rooms, context- ubiquitous com- applied to create a smart adap- connected and be used together to sup- aware adaptation puting, machine tation mechanism for devices in ply more intelligent services. learning the living room, to react to the user context and improve quality of life. Jain et al. Living room expe- User experiences, Special interest group regarding Suggestions for research topics regard- 2012 riences with smart design, interaction smart TVs and user experiences. ing smart TVs, such as the different TVs context, the interaction and what apps are meaningful. Loi 2011 Changing the TV User-centred Field study resulting in the de- Users show high expectations regard- and living room design, user expe- velopment of a media widget ing smart TV user interfaces. New experiences riences and a conference presentation interaction and navigation models are regarding the future of the TV needed for improved content discovery experience. on smart TV platforms. Rawassizadeh The feasibility of Wearables, smart Investigation of market demand, Limitations on size, text input, media et al. 2015 smart watches devices opportunities, constraints and output, computing. Advantages such advantages. as constant connection with owner. 10 Table 2.2: Main articles regarding smart device and smart TV research. 2.3 Application portability

This section covers the general concept of application portability. Also, since smart device portability research is limited, the subarea of mobile portability is discussed.

2.3.1 Software portability Mooney discusses the concept of software portability. [44] He sees two major aspects of portability: transportation and adaptation. The first aspect relates to the actual physical movement of the program to the new environment, while the second aspect covers any adaptation that is needed for the program to work in the new environment.

2.3.1.1 Binary, source and experience portability Based on this he discusses binary portability, where the executable of the program can be transported directly in its binary form, and argues that such portability would be perfect. However, this would require almost identical platforms for the application to run. To achieve a broader basis, source portability often needs to be considered. Source portability is the extent to which source files can be transported to and used on the new platform, with no or limited modifications. Even if adaptation is needed, it is argued that such modifications are easier than rewriting the entire application. [44] Mooney also considers a third type of portability: experience portability. This is the ability for users and developers to reuse their experiences from the original platform on the new platform - and is considered to be achieved by consistency. [44]

2.3.1.2 Portability process, costs and benefits In another article [45], Mooney proposes a framework for software portability, with focus on the software process. Here he also mentions the costs of portability, which can include increased development costs and reduced quality. Es- pecially, the performance of the application might suffer and user interfaces might not be appropriately adapted to each system. However, Mooney argues that the benefits - in terms of lower production and maintenance costs for future implementations - are greatest if portability is considered throughout the whole process; from specification and design to implementation and verification. The main advice from the article is to summarized in three key principles: (1) “Control the interfaces”, (2) “Isolate de- pendencies” and (3) “Think portable” [45, p. 3], which should be applied in each stage of the software development process.

2.3.1.3 Achieving portability According to Silakov et. al, there are strong arguments to ensure portability. [51] Portability can enable the developers to quickly leverage new platforms, and to easier manage the problem of software turning obsolete.

11 They discuss several techniques to achieve portability. However, disadvantages exist, such as performance penalties (code interpretation, emulators, virtualization), lack of standards (source code porting), error proneness or in- completeness (emulators), different UI results in different browsers or software complexity (web technologies), and end user costs (virtualization). [51] While they state that portability should be considered early for the best cost-effectiveness, and that it is seen as a long-term success factor, they are unable to give more specific advice for its acheivement:

“Unfortunately, [there] hardly exists a universal rule of selection of means to increase portability; such selection strongly depends on particular requirements imposed on the application.” [51, p. 46]

2.3.1.4 Portability problems in cloud applications Gonidis et al. investigate portability problems in cloud applications. [34] Some of the things that they highlight are the problems of being tied to a specific vendor and using specific programming languages. They also mention how specific services provided by the APIs of one platform can make it hard to later switch to another platform. Data migration and different query languages are other problems that make the portability harder. Related work suggest that standardization or intermediation is needed to achieve cloud application portability. Here, intermediation means to introduce an intermediate layer of APIs so that developers can make their applications without considering the specific platform.

2.3.1.5 Smart device portability Only one relevant article was found when searching for “smart devices application portability” (and similar). Zhang et. al demonstrate the process of porting an MP3 player application from the computer (simulator) to an embedded development board, and thereafter a smartphone (Samsung I908E). [67] How- ever, the study focuses on the implementation details for Windows Embedded CE 6.0 and the .NET Compact Framework 2.0, rather than considering the portability problems in general.

2.3.2 Overview of application portability research Table 2.3 summarizes the articles regarding application portability research, for the interested reader.

12 Article Research Theories Methods Relevant findings area Mooney Achieving System design and Overview and discussion of Defines binary, source and experience porta- 1990 application application design strategies to support application bility. OS should support portability. In portability portability. Focus on OS issues. application: use standard programming language and portable functions. Isolate the non-portable parts. Mooney Portability Software develop- Presents a thorough framework Definition of portability, guidelines for 1997 process ment for achieving portability in the achieving and measuring portability. Costs software development process. such as reduced performance and inappropriate user interfaces. Silakov et al. Achieving Software develop- Historic examples why portabil- Lack of portability can lead to obsolescence. 2011 application ment ity is important. Discuss ap- Approaches: binary portabilty, reuse of portability proaches for acheiveing software source code, through mediators, through in- portability. terpretable code, through emulators and virtualization, by using web technologies. Each is associated with different disadvantages. Gonidis et al. Portability Cloud computing Overview of related work. Ex- The heterogenity of platforms results in ven- 2013 of cloud amine four cloud application dor lock-in. Portability issues include the applications platforms. programming languages, provided services (APIs), configuration files and data storage options. Theory suggest standardization and intermediation to overcome portability. Tanaka 1992 Portability Distributed ap- Experiments porting a lan- Problems: language (Fortran inconsisten- problems plications, client- guage/business transaction cies), machine architecture (word length, server model processing system, written in memory adresses), portability of client-server Fortran and C, to new OSs (Unix communication, OS (I/O, authentication), and OS/2). Conversion of For- compiler inconsistencies. Use master source tran modules to C and repeating file in network to achieve portability. 13 the porting experiements.

Table 2.3: Main articles regarding application portability research. 2.3.3 Mobile portability Several articles discuss the portability of mobile apps, especially in terms of cross-platform development.

2.3.3.1 Fragmentation and unique challenges Agarwal et. al discuss the fragmentation of mobile applications and how this affects the portability of mobile applications. [1] They argue that the strategies used for portability in desktop applications might not be applicable, since the mobile setting has its unique challenges and characteristics. Especially, in the mobile world they see three unique issues: (1) quick evolvement and frequent introduction of new platforms, (2) the development and deployment is tightly coupled to the platform middleware, and (3) vendors are eager to differentiate themselves and thus provide different API:s and capabilities on each platform. [1, p. 2]

2.3.3.2 Cross-platform development tools For mobile platforms, cross-platform development tools (rather than native code) has been suggested to achieve portability. The approaches are investigated by Marinho et. al, with web apps (HTML, CSS and JavaScript), hybrid apps (combining native and web) and special apps (using specific languages and tools, e.g. Adobe Flash) as the broader categories. [41] Tools also use different techniques, such as code interpretation (no compilation, sometimes using a virtual machine), cross-compilation (with Inter- mediate Representation) and wrapping (in native container). However, each technique come with its own advantages and drawbacks. Generally, the advantages consist of an aspect of increased portability, while drawbacks are the performance, UI inconsistencies, and lack of device-specific features compared to native development. [41] Similarly, Dhillon et al. suggests a framework for evaluating mobile cross- platform development tools. [26] They find that current cross-platform tools often have weaknesses compared to native counterparts, such as lacking functionality or poor performance. They also suggest that the applications need to be adapted to the interface guidelines for each platform, to consider the user experience and make an appealing UI.

2.3.3.3 Portability techniques In their master thesis, Johansson et. al investigate the topic of mobile portability. [37] They develop an audio player for Windows Mobile 6, with the goal of making it as portable as possible. They then port the developed application to J2ME. After performing the port, they make eight suggestions on how to achieve portability (in the mobile context). These suggestions are [37, pp. 45-46]:

(1) to use a layered approach (architectural design), (2) to analyze the quality attributes and trade-offs (architectural analysis), (3) to consider the initial portability costs (cost-effectiveness),

14 (4) to avoid shortcuts (in terms of environment-specific API:s), (5) to implement the program in the most general environmen- t/programming language first, (6) to consider portability (to get better chances in a diverse market), (7) to consider performance (and its importance compared to portability), and (8) to separate interfaces and functionality (into general and specific parts).

Johansson et. al identify two key challenges when porting mobile applications: portability-versus-performance, and the diversity (lack of standards) in the mobile context. [37]

2.3.4 Overview of mobile portability research Table 2.4 summarizes the articles regarding mobile portability research, for the interested reader.

15 Article Research area Theories Methods Relevant findings Agarwal et Mobile platform Fragmentation, Investigate fragmentation of Identification of unique challenges in al. 2009 fragmentation platform inter- platform interfaces, develop a the mobile domain, such as rapid faces, abstraction mobile app “de-fragmentation” evolvement, vendor differentiation and layers layer (with plugins), imple- dependency on platform middleware. mented on three platforms. Marinho et Native vs multiple Cross-platform Overview of advantages and Complexity and high quality demands al. 2015 targeted develop- mobile develop- drawbacks for native and cross- for mobile apps. Cross-platform tools ment ment platform development. have weaknesses such as lacking UI consistency, device-specific features and performance. Should also consider developer skills and project specifics. Dhillon et al. Tools for cross- Cross-platform Suggest and experiment with an Evaluation of tools. Results suggest 2015 platform mobile mobile develop- evaluation framework for cross- that there is often weaknesses com- apps ment platform tools. pared to native tools; such as weeker perfomance, missing features or lacking support for native user interfaces. Consider specific needs before chosing a tool. Johansson Achieving applica- Mobile app porta- Literature study, market analy- Give eight guidelines for achieving et al. 2009 tion portability bility sis. Development of app with the portability: separation, starting with goal of making it portable. Port- the most general environment, avoid ing the app to another mobile specific APIs, layered approach, trade- platform. off analysis, initial costs, performance- vs-portability, platform diversity.

Table 2.4: Main articles regarding mobile portability research. 16 2.4 Porting and application portability: Definition

Mooney’s article [44] constitutes the most thorough framework regrading application portability. Figure 2.3 shows how Mooneys portability aspects can be modelled in terms of platform similarity and adaptation. The illustration has been created to emphasize that portability according to Mooney is “a matter of degree”. [44, p. 60] Further, Mooney’s [45][44] definitions of porting and application portability is used throughout the thesis:

Figure 2.3: Modelling Mooney’s [44] application portability aspects.

“Porting is the act of producing an executable version of a software unit or system in a new environment, based on an existing version.” [45, p. 2] and

“An application is portable across a class of environments to the degree that the effort required to transport and adapt it to a new environment in the class is less than the effort of redevelopment” [44, p. 59]

Mooney [45], suggests that the the term environment may be synonymous with “platform”, which is the term that is used in this thesis. Also, Mooney emphasize that a class of platforms should be considered, since it is not reasonable to know all possible target platforms.

2.4.1 Measurement Several authors measure portability by comparing the costs (or workloads) to port and rewrite an application. [45][53] The following formula reappears in the literature:

17 cost (or time) to port portability measure =1 − cost (or time) to rewrite

Mooney [45] argues that the cost estimates require analysis of the interfaces (such as those to users, I/O, OS, processor, runtime libraries), and how well they correspond between the existing software and the target platform. This information will help the developers to decide whether to port or rewrite the application. Tanaka [53] instead estimates the workload by counting the number of total and modified lines of code (LOC). He also argues that the workload for a modified LOC is different from the workload for a newly developed LOC. The factor that he uses implies that modifying is three times more time consuming than writing a new line of code. However, that assumption was based on the experiences from one big software company in Japan (in or before 1992), and might not be applicable to this study. According to Tanaka’s [53] model, a measure of less than 60 % means that the software is effectively non-portable (as too many of the lines have been modified). Mooney’s [45] approach instead implies that porting should be considered when getting a positive figure.

2.4.2 Context Mooney’s articles were written in an era of desktop computers, and predates the popularization of smart devices. Portability studies in the field of mobile development suggest that further considerations can be important in the area of smart devices. While web development and other cross-platform tools are popular, they still show weaknesses compared to native development. [26] The quick evolvement in the area, with new devices and platforms, as well as a high degree of fragmentation and vendor lock-in, impose additional restrictions on portability. [1][34] Smart device and digital TV research [36][40][47][48] suggest that different types of user interaction, input/output capabilities as well as usage patterns and social environments can be important factors that affect the portability of applications between platforms. Further, the role of the TV as leaned back experience is challenged, which provides for new interactive opportunities on the platform. [47][66] While games are mentioned foremost, Apple recognizes the opportunities for productivity apps, as seen in the App Programming Guide for tvOS:

“With Apple TV on tvOS, users can now play games, use productivity and social apps, watch movies, and enjoy shared experiences.” [4]

and similarly, the Apple TV Human Interface Guidelines:

“tvOS provides development frameworks for building riveting games, utilities, and other apps that run natively on Apple TV.” [9]

18 Chapter 3

Methodology

This chapter presents the research approach, outlines the research process, and describes the data collection methods used to answer the research questions. Further, two formulas for portability measures are presented, based on lines of code (LOC) and work hours. Lastly, the software development tools and methods used in the thesis are discussed, such as the iterative approach, the development environment and the programming paradigm. Especial effort is devoted to explaining the Model-View-Controller (MVC) and communication patterns used in iOS development.

3.1 Research approach

This section explains quantitative and qualitative methods, inductive and deductive approaches, as well as case studies. Thereafter, the research approach adopted in the thesis is described.

3.1.1 Quantitative and qualitative methods When conducting scientific research, an appropriate method should be applied. Methods are often split into qualitative and quantitive approaches. [25] In general, quantitative methods are associated with numbers, distance, statistical methods, questionnaires, experiments, hard and reliable data, generalizations and deduction. On the other hand, qualitative methods are associated with words, closeness, interviews, observations, soft and rich data, contextual understanding and induction. [25, p. 56]

3.1.2 Inductive and deductive methods Induction implies that empirical studies are performed, where specific observations are collected. Thereafter the data is analyzed with help from theory, to provide interpretation, generalizations and a deeper understanding - using a bottom-up approach. [25][55] After analyzing the collected data, different theories than the ones that were originally considered might turn out to be supported. [25, p. 46] The research is thus conducted with an open-ended and exploratory approach. [55] Deduction, on the other hand, takes a top-down approach. Here, the literature and theoretical frameworks are used to identify ideas and theories of

19 interest. From these, specific hypotheses are developed and tested - to confirm or falsify them. [25][55]

3.1.3 Case studies A quantitive case study can be conducted with a questionnaire - trying to measure and reflect the entire population - while the focus of qualitative case studies is on deep understanding rather than measurability. Case studies focus on one or several specific cases to learn more about a phenomenon, by generating a rich and deep data on the specific case. The phenomenon is considered as complex and multifaceted. [25] No statistical generalizability is possible when looking on a few or a specific case. However, analytical generalizability do apply if the case study is well conducted. This means that comparison and extrapolation can be used and the relevance for other similar cases can be analyzed. [25, p. 61-62]

3.1.4 Adopted research approach In this thesis, qualitative methods were used to explore a new platform, focusing on descriptions rather than numbers.1 Thus, an inductive approach was appropriate as it started by specific observations from the development process and thereafter was discussed and interpreted using theories of app portability and recent research regarding smart devices. The approach was considered as a case study, where the development process for the specific port was the case being studied to learn more about app portability in general. As argued by Blomkvist and Hallin:

“A case study is appropriate as a research method when you are open to the discovery of new dimensions - that is when the purpose is explorative, explanatory or describing.” [25, p. 61 (tr.)]

Thus, given the research questions presented in section 1.2 and the purpose of the thesis, a case study seemed like a well-suited research approach.

3.2 Outline of research process

This section summarizes the research process used to answer the research questions. The process is illustrated in Figure 3.1.

3.2.1 Literature study First, a literature study was conducted regarding application portability, smart devices and smart TV, and the iOS and tvOS platforms. Literature was found mainly by searching with the KTH Library search tools. The found literature was then reviewed to see if it was relevant for the thesis. This was an iterative process, performed repeatedly until sufficient theoretical background was established.

1With some exceptions, such as the portability measures.

20 Figure 3.1: Outline of the research process to answer the research questions. Double arrows indicate that the process is iterative, so that previous steps might be revisited.

3.2.2 Case study: Phase 1 Next, the case study was performed. As described in section 3.3, the iOS app was ported in two phases: the naive port (phase 1) and the refined port (phase 2). Phase 1 started by identifying the porting conditions, based on the previously developed iOS app. This was followed by an implementation phase, where the porting process was documented. Thereafter, the developed TV app was evaluated, based on the experiences from running the app on device, and thorough research regarding the tvOS platform - including tech talks, programming guide, human interface guidelines, books, news articles and blogs, smart device and smart TV research, and testing some other apps on the device.

3.2.3 Case study: Phase 2 The platform research was the start of the second phase of the case study. It enabled identification of improvements, so that the app could be refined for the specific platform. Based on the identified improvements, an implementation phase was conducted, and the porting process was documented. This was an

21 iterative process, where additional platform research was conducted, and additional improvements identified during the porting process itself. When the app was considered to have achieved an appropriate level of adoption and so- phistication, the results were summarized and portability measures were calculated.

3.2.4 Generalizations Lastly, the results were interpreted, generalized and discussed, which made it possible draw conclusions regarding the porting process (RQ2) and app portability problems (RQ1).

3.3 Data collection methods

This section describes the methods used to collect data to answer the research questions.

3.3.1 Literature study and platform research During the start of the project, a literature study was conducted to learn more about the theoretical background of the field. This included scientific research articles, books and documentation regarding application portability, smart TV:s and smart devices, as well as the investigated platforms (iOS and tvOS). The theoretical background was covered in chapter 2. Further knowledge regarding tvOS development was sought with help from documentation, books, videos and articles in the area, as described in section 5.2. This enabled the development of a refined application.

3.3.2 Observations from the porting experiments To address research question 2, the iOS app was ported in two steps. In phase 1, a naive approach was used, with the goal to reuse as much of the specifications, design and implementation as possible. The purpose with this was to investigate the porting process, the source portability and minimal porting costs. In phase 2, the app was refined, based on the experiences from the initial port, and a thorough investigation regarding the platform. The purpose with this was to make the app better adopted to the tvOS platform - based on the platforms unique possibilities and limitations - as well as to consider the area of experience portability. As found by Loi [40], smart TV users have high expectations regarding the user interfaces and user experiences, compared to other platforms.

3.3.2.1 Logs and notes Throughout the project, data was gathered (using logs and notes) regarding the development process, such as the issues encountered and the time spent on different activities. To simplify logging and note-taking, the version control system Git was used. This was also complemented by notes, by hand and

22 in a spreadsheet. The observations regarding the porting experiments were assembled to answer research question 2, regarding porting to tvOS. When necessary, literature and documentation were revisited to better understand the observed phenomena. This guided the development work and enabled deeper analysis, so as to answer the bigger question regarding app portability problems for smart devices, research question 1.

3.4 Portability measures

Two portability measures were calculated based on the discussion in section 2.4.1. The portability measures were used to consider the feasibility of porting the app, compared to rewriting it from scratch.

3.4.1 Lines of code First, the portability was calculated based on the lines of code (LOC). The cost to rewrite was approximated by the lines of code (for .swift-files) in the original iOS app. This number was found with the ;Bi /B77 @@bii I+QKKBi=I+QKKBi= command, where I+QKKBi= refers to the commit hash. The original iOS app was compared to the empty object. The cost to port was calculated by the number of added LOC, found with the ;Bi /B77 @@MmKbii I+QKKBi=I+QKKBi= command. Here, each tvOS app version was compared to the original iOS app. The command also gives the number of removed lines, however, these were disregarded to not double count modifications (counted both as added and removed by git-diff). The formula was then:

added (or modified) LOC portability measure =1 − LOC in iOS app

Note that the factor - three times more time consuming to modify a LOC - from Tanaka’s article [53] isn’t used, since the experiences from the porting experiments does not agree with that view. I.e. it is assumed in this thesis that it is equally time consuming to add a new LOC (if rewriting) as it is to modify an existing LOC (if porting).

3.4.2 Work hours Second, the portability was calculated based on the work hours spent on the development process. The cost to rewrite was then approximated by the work hours spent on the original iOS app, in terms of specification and design, and implementation. Similarly, the work hours for porting the app (in each phase) was summarized (from the notes taken during the development process). The formula was then:

work hours to port portability measure =1 − work hours iOS app

23 3.5 Software development - tools and methods

This section describes the software development tools and methods used in the porting process.

3.5.1 Software design process: An iterative approach Modern software development approaches try to work closely with the end users and reevaluate the project continuously during the development. This can be achieved by using prototypes, simulations and visualizations to review and discuss the project results during the process itself. [30] Iterative and agile methods divide the project into short work phases, with frequent review, assessment and adaptation to changing demands. [46] In this project, an iterative approach was used, where the steps of definition, planning, implementation and evaluation were repeated so as to allow for respecification and new directions. This is appropriate since a new platform is investigated in an explorative manner, so any specific plans specified at the start might not be relevant in the end, or might not even be possible to fulfill. Because of the limited time frame, user tests were not conducted - the thesis instead relied on smart TV research and Human interface guidelines (HIG) for the tvOS platform. As described in section 3.2, both the literature study and case study had iterative elements, were previous steps were revisited. The iterative steps were illustrated in Figure 3.1. Further, the app was developed in two phases/ver- sions, which in itself can be considered as an iterative process. The division into two distinct phases enabled additional insights regarding the porting process and porting problems for smart devices.

3.5.2 Development environment In this project, Xcode was used for application development. Xcode is an integrated development environment (IDE) developed by Apple and is intended for developing OS X, iOS and tvOS applications. Xcode includes a graphical user interface tool, Interface Builder, as well as simulator, debugging and other development and analysis tools. It supports several programming languages, including the main languages for OS X, iOS and tvOS development: Objective- C and Swift. The iOS app was developed and ran on iOS 9 and the tvOS app was developed and ran on tvOS 9.

3.5.3 Programming language and paradigm For the code in the project, Swift was used, since the iOS app was written in Swift. Swift is a new programming language with a multi-paradigm approach. It supports both object-oriented and functional programming styles. It is also designed to be interoperable with the older OS X/iOS/tvOS language Objective-C, to allow for easy transition and use of Objective-C frameworks.

3.5.3.1 Object-oriented paradigm and MVC The code in the project focus on the object-oriented programming paradigm, since the iOS app uses this approach. Mooney [45, p. 5] argues that object-

24 oriented design is suitable for achieving portability since it helps with encap- sulation of resources. A layered architecture, with the Model-View-Controller (MVC) architectural pattern was applied. In the world of iOS programming, this is achieved by the use of views and related view controllers (lAoB2r*QMi`QHH2` subclasses), backed by model objects. Figure 3.2 shows some typical communication patterns in iOS development, as described by Hegarty [35].

Figure 3.2: Model-View-Controller and communication patterns for iOS development.

3.5.3.2 Description of MVC in iOS development The view controller is allowed to communicate with the both the model and the view. However, view and model does not communicate with each other. The view controller uses outlets to attach to view objects. If the view needs to communicate back to the view controller, the communication should be structured and unspecific (i.e. the view does not need to know anything about the responding view controller). Target-Action communication implies that the view controller puts a target on itself and hands out an action to the view. A typical scenario would be that the view wants to communicate a user event (for example a button press). Delegation uses protocols and can be used for syn- chronization and for retrieving data when needed (for example to display in a table). [35] The model does not directly communicate with the view controller, but can broadcast notifications when something has changed. It is up to interested view controllers to set up their listening for relevant notifications. More complicated programs consist of groups of MVCs that work together in a structured way. Especially, the view controllers can communicate and coordinate the flow of the program. [35] When switching between the view controllers, segues (lAaiQ`v#Q`/a2;m2) can be used to make the transition, and also call a method suitable for passing data to the next view controller. [18]

Chapter 4

The iOS app and conditions for its porting

In this chapter, the original iOS app is presented. This includes the app’s functionality, structure, storyboard and images from the app. Further, the conditions for considering the app as ported are specified, as well as some circumstances that could have made the porting process easier or harder (advantages and drawbacks).

4.1 App functionality and structure

This section explains the functionality of the iOS app as well as the application structure.

4.1.1 Functionality The iOS app to be ported (Parallel Progress) is a productivity app, or more specifically a todo-app. It is centered around dates, so that for each date it keeps a list of the activities that the user would like to accomplish. Further, it focuses on splitting the activities into time intervals, so that the user can plan for how long to work on each activity in a certain day. For example, the user might want to spend two times 30 minutes on writing in a particular day. The user can then start a timer to keep track of the time, which will give a sound when the interval is done. It is also possible to pause the time interval. When a time interval is done it is marked in the app. Similarly, the user can mark an activity as done. Activities can also have different priorities, which affect the sorting of activities. Parallel Progress supports the creation of activities as well as editing and deleting them. Figures 4.4 - 4.6 (in the end of this chapter) show how to add, work on and delete activities in the app.

4.1.2 Core Data model, persistent storage and the cloud The +iBpBiv objects as well as the related time intervals are then managed and stored as entities with help from the Core Data framework. Core Data is a model layer framework, that provides both the object graph (the relation-

27 ship model) and the persistent storage. Figure 4.1 shows the entities and their relationships in the Core Data model of the app. The objects in Core Data reside in an object context (LaJM;2/P#D2+i@ *QMi2ti) that represent the application state. The persistent store coordina- tor communicates changes in the model to the persistent store, which in turn saves them in an SQLite database. The Core Data Stack is the Core Data components used together (i.e. this is where the process is set up and managed in the program). [28]

Figure 4.1: Entities and relationships in the Core Data model.

The data is also synced via the cloud to other iOS devices. This is performed by using iCloud, which is Apple’s cloud-based services and storage. When Core Data is updated, the changes are written to the persistent store (on device), and change logs are written to the iCloud ubiquity container1. These change logs are then uploaded to the cloud, and synced to other devices (with the same iCloud login) so that the local SQLite databases can be updated. [16] Figure 4.2 shows a simplified application structure to demonstrate the Core Data relationships.

4.1.3 Application structure Parallel Progress consists of several view controllers, views and model objects. The main views are setup using the graphical user interface tool, Interface Builder. There, a storyboard file is used to set up each screen in the app, as well as outlets, segues, layout constraints and other relationships. Figure 4.3 shows an overview of the application structure. The view controllers responsible for screens in the storyboard are marked with a darker orange color, while the other view controllers are responsible for smaller segments (subviews) inside each screen. The app uses both outlets, Target-Action, delegation, notifications and segues for communication between different types of objects, as described in section 3.5.3. Table views (lists), collection views (grids), labels and custom views are used to present data to the user. Text fields, date pickers, buttons and custom controls are used for entering data as well as user interaction, such as starting a timer.

1Ubiquity means “present everywhere” - such as in the cloud or on all the devices for a person.

28 Figure 4.2: Overview of Core Data as model layer and persistent storage, and syncing with iCloud.

A split view controller helps provide a reasonable user interface on larger devices (such as the iPad). The screen is then split into two sections, where one smaller part to the left is used for the main navigation (in form of lists), while the other part shows the view for interacting with a selected item. Nav- igation controllers are used to provide hierarchical navigation behavior using the navigation stack. For that purpose, they provide navigation bars at the top with navigation items (such as back/save/cancel buttons). A view controller can then be embedded in a navigation controller, which is used frequently in the app. Figure 4.7 (in section 4.2) shows the storyboard of the app.

29 Figure 4.3: Overview of Parallel Progress application structure.

4.2 Demonstration of the iOS app

This section presents the iOS app that should be ported. Figures 4.4 - 4.6 demonstrate a typical workflow in the app, indicated by the purple circles. The user can add, work on, edit and delete activities in the app. The data is then persisted locally (SQLite) and in the cloud (via iCloud). Note how the data is structured in table views (lists), separated by thin gray lines. Figure 4.7 shows the storyboard of the app. The images have been chosen so as to facilitate comparison with the tvOS app in section 6.4 (the naive port) and section 6.5 (the refined port).

30 Figure 4.4: Adding a new item to the project using the plus button. The middle image represents the form before data has been entered. Purple circles indicate where the user presses.

31 Figure 4.5: Working on an activity. Purple circles indicate where the user presses. First an activity is selected, thereafter a time interval. The timer is then started, and after 10 minutes it finishes. The user goes back and marks the activity as done.

32 Figure 4.6: Deleting an item by swiping to the left. Purple circles indicate where the user presses.

33 Figure 4.7: The storyboard for the mobile app, with split view controller, navigation controllers, table views, container views, collection view and regular view controllers laid out. Segues (the arrows) are used to control the flow of the program. Note the frequent use of table views. 34 4.3 Conditions for porting

For the app to be considered as ported to tvOS, the following requirements were specified:

It should be possible to: • Add, remove and edit activities. • Get an overview of dates and activities. • Select an activity and see its information (title, time intervals, notes, priority, date). • Select a time interval for an activity (and see how much time has been spent/should be spent). • Start/pause a timer for a time interval. • Trigger an alarm (sound) when the timer is done. • Mark activities as done. Otherwise, the idea was to start out and port the app with a naive approach, i.e. keeping as much as possible of the interface design and the code base - and thus keeping the porting costs as low as possible. The goal was then to get the above-mentioned functionality up and running on the new platform (phase 1). Thereafter, the code developed with this approach was evaluated and further refined (phase 2).

4.4 Advantages and drawbacks

According to The Verge, Craig Federighi (Apple’s senior vice president of Soft- ware Engineering), said that “tvOS is 95 percent the same as iOS” [57]. tvOS shares the core frameworks with both iOS, OS X and watchOS (the operating system for Apple Watch). The main differences from iOS are in the interface layer, which is adjusted to a different interaction model (with a remote). [57] Further, the new platform was researched by checking API differences between iOS and tvOS. Then it was found that both UIKit, Foundation, CoreData and AVFoundation existed on tvOS [4], which are the main frameworks used in Parallel Progress. Thus, with this information it was expected that the process of porting would be rather smooth, with few adjustments to the source code. The main adjustments were expected to relate to the different screen size and interaction. However, a problem that was identified quite early, was the lack of information, documentation, best practices and forums for the new platform. When searching for the answer to an iOS development related question, both Apple documentation, related blog articles and Stack Overflow answers usually show up. When searching for similar documentation on tvOS, one is often referred to the iOS frameworks/articles - which doesn’t always solve the tvOS-specific problem. Although the documentation is expected to be enhanced over time, it can still pose a problem to early adopters, such as in the case study of the thesis.

Chapter 5

Case study: Porting to tvOS

Starting from the Xcode-project of the original iOS app, this chapter describes the complete process of porting the app to tvOS. First, the naive port was conducted. Thereafter, the app was evaluated based on thorough research, and areas of improvement were identified. Thereafter, the refined phase was conducted, which resulted in a second app version.

5.1 Phase 1: A naive port to tvOS

Since the goal of this phase was to port the app with minimal porting costs, there was no effort spent on redesigning or respecifying the app. The conditions for considering the app as ported were established in section 4.3. The new app is referred to as Parallel Progress-TV.

5.1.1 Creating a target and making the app runnable

As a first step, a tvOS target was added for the Xcode-project of Parallel Progress. Next, the Provisioning profile, iCloud containers and iCloud entitlements in the Apple Developer Member Center were updated, as well as the project settings in Xcode. Then, all of the source files and assets (images and audio) were added to the new target, so that they were available for both targets. This resulted in several errors, as can be seen in Figure 5.1. Several errors included the text “… is unavailable”: the date picker, refresh control, back button, local notifications and notification settings are unavailable. The “use of unresolved identifier” error (`2;`/BM; LaS2`bBbi2MiaiQ`2@ l#B[mBiQmb*QMi2MiLK2E2v) also indicates that something is missing on the platform. The “’AppDelegate’ has no member ’coreData Stack’” error was caused by the fact that the AppDelegate for the tvOS target had not been implemented yet - it was only consisting of the boilerplate code created when adding the target. To resolve the errors, a first step was to just exclude the problematic lines of code from the tvOS target. This was achieved by using OB7 QbUBPaV and O2M/B7 to define the target as iOS for specific rows. Listing 5.1 shows an example, to demonstrate a line of code removed from the tvOS target (the refresh control).

37 Figure 5.1: Errors when adding the source files to the tvOS target.

ff2M#H2 `27`2b? U`272i+?2b i?2 /i2bV OB7 QbUBPaV `27`2b?*QMi`QH\X//h`;2iUb2H7- +iBQM, ]`27`2b?]- 7Q`*QMi`QH1p2Mib, lA*QMi`QH1p2MibXoHm2*?M;2/V O2M/B7 Listing 5.1: Excluding a line with OB7 QbUBPaV and O2M/B7.

5.1.2 Setting up the storyboard

After resolving the errors like this, the app was now runnable in the tvOS simulator. However, when running the app, there was only a blank screen presented. This was caused by the fact that the storyboard for the tvOS target only consisted of an empty view controller, i.e. all of the screens in the app needed to be set up specifically for tvOS. This meant to drag out elements such as the screens (split view controllers, navigation controllers, table view controllers, etc), the UI elements (buttons, labels, textfields, etc), and the connections (such as segues), and wiring every- thing up with appropriate classes and outlets in the existing code.1 By building a very similar user interface to the iOS app, it was possible to let the same code and outlets be connected to the tvOS storyboard elements. However, after adding most of the elements without problems and errors, the app was run to find that it was only partly navigable.

1The resulting storyboard can be seen in section 6.4.

38 5.1.3 Adjusting the focus Because of the remote control, tvOS relies on an entirely different interaction model than iOS. Rather than touching and tapping the UI directly, the Apple TV user needs to indirectly steer the TV with the remote. This is achieved by indicating to the user what element is currently in focus (often by giving it a white background and scaling it up). See Figure 5.2 for an example of a focused button.

Figure 5.2: A set of buttons for illustrative purposes. Bottom left button is in Focus.

Focus can move up, down, left, right as well as in diagonal directions. [5] Figure 5.3 shows right movement, while Figure 5.4 shows an example of diagonal movement (towards the top right corner).2 While elements such as table view controllers, tab bars, buttons and textfields are provided with focus behavior by default, more complicated and custom views need to be reworked in order to direct the user in a consistent and appropriate manner. For example, the priority setter in the //+iBpBivh#H2@ oB2r*QMi`QHH2` did not receive focus because the focus engine decided to skip the buttons in favor of the collection view (probably because the collection views focus element take up more of the considered width). See Figure 5.5 that illustrates the problem.

2The images are generated by putting a breakpoint in the /B/lT/i26Q+mbAM*QMi2tiUV method, and then clicking the Quick Look icon with the +QMi2ti selected.

Figure 5.3: Focus going right, from the button in the top left to the top right. Purple elements are focusable and therefore considered. The red ring (around the purple button) indicates the object selected by the focus engine.

39 Figure 5.4: Focus going diagonally (towards top right corner).

Figure 5.5: The focus is on the red area, and the user moves down. The figure shows how the priority buttons are focusable (purple) but skipped by the Focus Engine in favor of the collection view cell. The red line around the collection view cell indicates the chosen cell.

Debugging each Focus Engine problem to find appropriate solutions was rather frustrating and time consuming, with a lot of trial and error. However, after some research, adding focus guides (lA6Q+mb:mB/2) and setting their layout constraints and T`272``2/6Q+mb2/oB2r solved most of the problems, and thus made the app navigable. Also, some images needed to be added so as to represent the focused state of the image. Figure 5.6 demonstrates the use of a focus guide.

5.1.4 Making a date picker Next, the lack of a date picker was considered. After some online research, it didn’t seem to exist a standard solution. To provide a date picker with correct

40 Figure 5.6: The lightblue area indicates a lA6Q+mb:mB/2, which redirects the focus to its T`272``2/6Q+mb2/oB2r, in this case the first of the priority buttons (hidden under the focus guide in this image).

Figure 5.7: Date picker based on 4 buttons and swipe gestures (up/down) to select the dates. representation of months and days, the La*H2M/` class with methods such as `M;2P7lMBiUV, /i2"v//BM;lMBiUV, /i26`QK*QKTQM2MibUV was used. The La.i2*QKTQM2Mib class was used to assemble date components (year, month and day) and validate dates (with BboHB/.i2AM*H2M/`UV). With this information at hand, two different designs were considered. The first was based on the blog article “How to develop for tvOS: First face-to-face experience” [27], and resembles the date picker on iOS, where you swipe up or down to select year, month and day. See Figure 5.7 for the first design.

41 Figure 5.8: Text input/keyboard on tvOS. The word ”textfield” has been input by the user.

Figure 5.9: Date picker designed to resemble the text input on the platform. When changing the month, the available days change appropriately.

For the second design, segmented controls were set up in the storyboard, designed to resemble the keyboard on tvOS. See Figure 5.8 for an image of the keyboard and Figure 5.9 for the second design of the date picker. After considering both approaches, the second design was chosen, as it felt more consistent with the platform. After implementing the date picker, it was segued from the view in the app where the user adds a new activity.

42 5.1.5 Up and running After some additional fixes (such as adding an app icon, making sure that the UI updates at desired times and making it possible to exit certain views that previously relied on a back button) the app was up and running and ported according to the requirements in section 4.3. However, some caveats remain, as will be discussed in section 5.2. Section 6.1 shows the resulting tvOS app from the naive port of the app.

5.2 Evaluation and research

After developing the TV app, thorough research was conducted on the platform, to learn about the constraints, recommendations and praxis. This included:

• Apple TV Tech Talks Videos3 [13]

• App Programming Guide for tvOS [3]

• Apple TV Human Interface Guidelines (HIG) [7]

• tvOS Apprentice: Beginning tvOS Development with Swift 2 [24] - The sections about Architecture, Traditional Apps, Advanced Frameworks and Design.

• Blogs and news articles regarding tvOS and development experiences with the platform (see Table A.1 in the appendix).

• Smart devices and smart TV research [36][40][43][47][48][66]

• Navigating some apps on the device, to see how they look and feel.

Based on this research, combined with the experiences from testing Paral- lel Progress-TV on device, the app was evaluated and opportunities for refinement were identified.

5.2.1 Testing on device The app was tested on a device, to see if it felt appropriate with the remote control at a distance. To run the app on device, a USB-A to USB-C sync cable was needed to connect the computer with Xcode to the Apple TV device.

5.2.1.1 No persistent storage nor sync When running on the device, the LaAMJ2KQ`vaiQ`2hvT2 was required for the app to run (instead of the LaaZGBi2aiQ`2hvT2). When checking the differences between the iOS and tvOS API:s more carefully, it was found that while Core Data and iCloud are supported, persistent storage with Core Data is not. This means that Core Data can be used as an in memory cache, but not to persist the data. [22]

3Excluding session 6 (Media Playback) and 7 (Introduction to TVMLKit) that are less relevant for native productivity apps.

43 Further, the iOS app relies on iCloud ubiquity containers for persistent storage in the cloud, so that data can be synced between devices (such as the iPad and the iPhone). Since Core Data doesn’t support persistent storage on the tvOS platform, the iCloud ubiquity containers aren’t supported by the Core Data framework on tvOS. [21] This means that another approach would need to be taken to be able to backup the data in the cloud and sync it between devices. Figure 5.10 demonstrates the problem.

Figure 5.10: Core Data without persistent storage on tvOS. Only the In- memory persistent store type is allowed.

In the Apple TV tech talk [15] on On-Demand Resources and Data Storage, they discuss that the Apple TV is expected to always be connected. Therefore, the storage on the device is limited and the data (and application state) is to be fetched over the network. Thus, they discuss three approaches to persisting data on tvOS: iCloud Key-Value Store, CloudKit or hosting the data on a server. iCloud Key-Value Store offers simple, key-based, and limited storage while CloudKit offers a more structured approach with public and private database, asset storage services etc. Both services are free to start with, but CloudKit has limits where the developer needs to start paying for the services if they are exceeded. Further, in the same the Apple TV tech talk session [15] they argue that “along with this platform is this expectation that it synchronizes with all your other devices.” This is especially true if the user has bought the app through Universal purchase, so that it is available both on the iOS and tvOS platform. As suggested by smart TV research [36][43][47][66], the TV should be considered as a connected device, interacting with other smart devices inside or outside the room.

5.2.1.2 Text input is cumbersome When testing to add activities on the device, it was noted that text input isn’t optimal in a focus model, where each letter first need to be focused and then

44 pressed (see Figure 5.8 for an image of the text input view). In fact, it becomes tiresome so quickly that I found myself reconsider the thing that I was trying to input before I was done (to write something shorter). In the Apple TV tech talk [14] on Best Practices for Designing tvOS Apps, they say: “In some cases, you might need to collect a lot of information, which isn’t really that practical via the onscreen keyboard”. They argue that sometimes it might be better to “make a companion app or use your current iOS app” to input the information. In line with this, they say that you should “keep people immersed in your content instead of being distracted by forms”. So, in general, it is recommended to keep the input to a minimum on the tvOS platform.

5.2.1.3 Navigation is complicated When navigating the app with the split view controller and table views, it was sometimes hard to know what would happen (when pressing for example the back-button). It also felt a bit slow and unintuitive to navigate through date, to activity, to time interval, to play-button in order to start an activity. Further, it was noted that the plus buttons for adding activities, as well as other navigation items, cluttered the user interface and made the navigation paths with the focus model less clear. The main difference that was noted when using a focus-based interaction model, compared to touch (or a mouse), is that it is not enough to click the item you want, but first you need to navigate there, sometimes through very strange paths in the UI depending on which other elements are focusable in between. As pointed out by Klein [39]: “we now have to change our thought-process to a more linear navigation, one where users can only move from element to element in a strict fashion” and “You will be surprised to see how hard it is to use the simulated remote to navigate your app”. Figures 5.11 and 5.12 demonstrate the problem. In the HIG they argue that: “Collections of content tend to work well in grid format on Apple TV. They showcase content well, are easy to browse at a distance, and are quick to navigate with the remote.” [12] Further, they argue that collections of content should be presented on single screens, and that fewer screens and fewer taps and swipes are preferable to more. [11] In the section on Interface elements they state: “In many Apple TV apps, a tab bar across the top of the screen is the primary means of navigation… A tab bar is great for flattening your information hierarchy and providing quick access to several peer information categories or modes at once.” [8] Further, as argued in the Apple TV tech talk [13] on Best Practices for De- signing tvOS Apps, it is important to “make focus obvious” by providing control states or animations. Since the user interacts with the TV indirectly, it is important to feel connected and know where you are in the user interface. The tvOS Apprentice book [24, p. 265] explains how to implement custom focus behavior, for example by providing animations in the /B/lT/i26Q+mbAM*QMi2tiUV method.

45 Figure 5.11: Navigation with the focus engine. The user is at the Mark as done- button but wants to press the Plus-button, which is achieved by navigating there in four steps.

Figure 5.12: The user wants to navigate back down to the Mark as done-button. However, the path back is different (and five steps).

5.2.1.4 Sizes and spacing While the design looked fine when running it in the simulator, there was quite a different feeling when seeing it on the TV from across the room. Especially,

46 many elements were sized awkwardly, including borders, spacing and font sizes. The HIG [12] gives suggestions for content width and space when using grid-based layouts, proper spacing around the edges and advice regarding typography and colors.

5.2.1.5 The remote The remote provides three buttons that can be used by an app, i.e. the touch surface, the Menu-button, and the Play/Pause-button. In the HIG [10] they state that you should “Implement expected button behavior”. The touch surface is used for navigation, the Menu-button is expected to work as a back button and, the Play/Pause-button is used to pause and resume. In the naive version of the app, the Play/Pause-button was unused. However, it would be de- sirable to be able to use it to start and stop the time intervals (as a complement to the Play and Pause buttons in the UI).

5.2.2 Areas for improvement The following areas for refinement were thus identified:

• Implement persistent storage in the cloud (use Core Data only for application logic and caching). • Implement the ability to sync between devices. • Make use of the large screen to focus on content, with grid-based layout (collection view). • Flatten the navigation hierarchy (tab bars and collection view instead of complicated navigation stacks). Limit the number of navigation items that clutter the screen. • Avoid unnecessary movements, such as going all the way back up to confirm a form. • Place buttons for editing and removing at sensible places. • ”Make focus obvious” through animations and images with appropriate states. • Adjust spacing and sizes (including fonts) to be suitable for the platform (interaction at a distance). • Adjust the colors to be appropriate for the platform. • Make text input (the form) a secondary objective. Users can also add activities from their phone or tablet. • Implement the Play/Pause-button to start and stop the timer.

5.3 Phase 2: Refining and redesigning the app

Based on the above evaluation, the refined app was implemented to account for the areas of improvement.

47 5.3.1 Implementing key-value storage and sync with iCloud To solve the problem of lacking sync and persistent storage, iCloud key-value storage was implemented and connected to the Core Data model. Core Data is only considered as a cache, so that whenever a new activity is created or changed, both the cache and the iCloud key-value entry is updated. To receive updates from other devices, the app listens for the Lal#B[mBiQmbE2voHm2@ aiQ`2.B/*?M;21ti2`MHHvLQiB7B+iBQM and handles such notifications to update the model in the app, which in turn will trigger an update of the user interface. It should be noted that the iOS app also needed to be updated to enable sync between the tvOS and iOS devices. Even though both approaches use iCloud, the original iOS app synced the change logs for the SQLite store. These change logs aren’t interoperable with the key-value changes in the tvOS app. Luckily, since key-value storage is supported on both platforms, and the same Xcode-project is used for both devices, the changes for the tvOS app could easily be used on the other target. However, any existing users of the original iOS app would lose their data when switching (since migration has not been implemented).

5.3.2 Refining the navigation and storyboard (with tab bar and collection view) As mentioned before, a more easily navigable app was desired, and therefore the app was redesigned. A tab bar controller was used to split the app into two tabs, one for the main content of the app (the activities) and one for adding new activities. The main content was restructured by using a grid-based layout (rather than the tables for dates and activities). Here, the data was structured by sorting it into sections based on date. To manage this task, a transient at- tribute (b2+iBQMLK2) was added to the Core Data +iBpBiv object, to provide a sortable section identifier as a string value. New classes, such as the +iBpBiv*QHH2+iBQMoB2r*QMi`QHH2` and 62i+?2/_2bmHib*QMi`QHH2`*QHH@ 2+iBQMoB2r.iaQm`+2 where created to enable the new UI. The resulting storyboard and UI can be seen in section 6.5. Further, several navigations items were removed or moved to suitable places. For example, the Plus-buttons used to add activities were removed since the tab bar is used for navigating to the Add activity screen.

5.3.3 Focus Animations and image states (Focused, Highlighted, Selected) were added to make the focus changes clearer. The +QQ`/BMiQ`X//*QQ`/BMi2/MBKiBQMbUV method was used in /B/lT/i26Q+mbAM*QMi2tiUV to provide focus behavior in response to focus changes, such as scaling, shadows or color changes - where those are not provided by the default implementations.

5.3.4 Sizes, spacing and colors The font sizes in the app, as well as border sizes and general sizing of UI elements, where reconsidered and tested on the device, to make it more appro-

48 priate and more readable at a distance. Also, some of the colors were changed to consider the different color experience on a TV, compared to an iOS device.

5.3.5 Text input and play/pause buttons The input form for new activities was moved to a separate tab. Since sync is enabled, users can choose to input activities using their phone (or tablet) instead. To adhere to the platform conventions, the Play/Pause-button was implemented to start and stop the timer.

Chapter 6

Case study: Results

This chapter presents the results of the case study - such as the porting steps, the portability measures and the resulting apps.

6.1 Phase 1: The naive port

The first phase considered the minimal porting costs with the goal to reuse the iOS app as far as possible. As can be seen in Figures 6.1 - 6.10 (in section 6.4), the user interface and storyboard are similar to the ones in the iOS app, emphasizing split view controllers and table views. Table 6.1 summarizes the steps performed when porting the app. It should be noted that except for the initial specification of the porting conditions (which were based on the requirements for the iOS app) no additional specification was performed when porting the app. Regarding the UI, mainly the date picker had to be redesigned, due to the lack of the lA.i2SB+F2` class (removed on tvOS). The storyboard needed to be rebuilt, but was based on similar components as in the iOS app. The source code development was focused on finding missing functionality and create workarounds, as well as to support the different navigation model (focus).

51 Steps Comment Make the app runnable Create tvOS target, update settings, remove unsupported operations. Rebuild the UI Create and connect the storyboard and its elements. Make the app navigable Provide/debug focus behavior, especially for custom controls. Consider the view hierarchy. Add missing assets Provide app icons, images etc. Implement and test any Designed and implemented date picker. Enabled missing functionality editing/removing activities and updating UI. Run the app on device Debugging code for focus, color changes, storage etc. Clean up Document and clean up the code.

Table 6.1: Main steps performed when porting the app with a naive approach.

6.2 Phase 2: The refined port

The second phase considered refinements to account for the platform and experiences. Figures 6.11 - 6.18 (in section 6.5) demonstrate the refined version of Parallel Progress-TV. As can be seen in these figures and the storyboard (Figure 6.19), the app has a different UI based on tab bars and grid-based layout of content. When rebuilding the storyboard, some screens were kept (such as the form) but incorporated differently - in a container view (for spacing) or using the full canvas (for better visibility and navigation). In this phase, the limitations of the platform were considered, and iCloud key-value storage was used to persist and sync the data. There was also a heav- ier focus1 on the interaction model, so as to provide the appropriate behavior. Table 6.2 summarizes the steps performed when refining the port. Note that the port was performed after considerable platform research to identify the relevant improvements.

1Pun intended.

52 Steps Comment Add persistent storage Platform limitations considered. iOS app updated and sync for compatibility. Rebuild the UI (grid- Consider screen size and interaction model. based & tab bar) Input form in a separate tab. Make the app navigable Focus behavior (images/animations) considered. Buttons reconsidered. Focus guides added. Consider distance Borders, color, spacing and sizes. Implement Play/Pause- Acknowledge conventional button behavior button (remote). Run the app on device Verify expected behavior. Clean up Document and clean up the code.

Table 6.2: Main steps performed when refining the port.

6.3 Portability measures

This section presents the resulting portability measures using the lines of code (git-diff) and work hours as estimates of the portability cost.

6.3.1 Lines of code Table 6.3 shows the total lines of code for the iOS app and tvOS app after each phase, as well as the number of added and removed lines of code for the two tvOS implementations compared to the iOS app.

total LOC added removed iOS app 1879 - - Naive approach 2371 519 27 Refined 3523 1725 81

Table 6.3: The total LOC after each implementation phase, as well as the added/removed LOC compared to the iOS app.

Based on the formula in section 3.4.1, Table 6.4 shows the calculated portability measures for each phase.

portability Naive approach 0.72 Refined 0.08

Table 6.4: Portability based on LOC.

53 6.3.2 Work hours Table 6.5 shows the number of hours spent on specification, design and implementation in each phase, starting from the code in previous phase. The iOS app required a lot of specification and design, since it was created from scratch. Phase 1 of the tvOS implementation depended heavily on the specification and design of the iOS project. Phase 2 on the other hand, required some rework of the app specification and design.

specification & design implementation total iOS app 80 140 220 Naive approach 5 65 70 Refined 40 70 110

Table 6.5: Approximate number of work hours spent on the activities in each phase.

Based on the formula in section 3.4.2, Table 6.6 shows the calculated portability measures for each phase. When calculating the metrics, it was assumed that all of the (limited) specification and design work for phase 1 benefited phase 2, while only 70% of the implementation work benefited phase 2. These approximations were based on observations from the case study.

specification & design implementation total Naive approach 0.94 0.54 0.68 Refined 0.44 0.18 0.27

Table 6.6: Portability for each activity based on work hours.

54 6.4 Demonstration of the app from Phase 1

This section presents the tvOS app that was the result of porting the iOS app with a naive approach. The images below (Figures 6.1 - 6.9) demonstrate a typical workflow in the app, as indicated by the purple circles (where the user presses). The user can add, work on, edit and delete activities in the app. How- ever, the app with a naive approach doesn’t support persistent storage (only in memory), so the user will need to start over if the system decides that the memory is needed for something else (for example when running another app that needs the memory). The images have been chosen so as to facilitate comparison with the iOS app in section 4.2. Figure 6.10 shows the storyboard of the app.

Figure 6.1: Adding a new activity to the project by clicking the Plus-button. Purple circles indicates where the user presses.

55 Figure 6.2: Saving a new activity to the project by clicking the Save-button.

Figure 6.3: Selecting an activity to see its details.

56 Figure 6.4: Selecting a time interval to work on an activity.

Figure 6.5: The timer for the time interval (10 min) is running.

57 Figure 6.6: The time interval is done. The user clicks the Done-button to go back.

Figure 6.7: Marking the activity as done by pressing the Mark as done-button.

58 Figure 6.8: The activity is marked as done. The user presses the Edit-button to be able to remove activities.

Figure 6.9: Deleting an activity by pressing the Trash can-button.

59 Figure 6.10: The storyboard of the tvOS app, similar to the iOS app with split view controller, navigation controllers, table views, container views, collection view and regular view controllers. 60 6.5 Demonstration of the app from Phase 2

This section presents the tvOS app that was the result of refining the app created with a naive approach. The refinements were based on research and experiences from the app. The images below (Figures 6.11 - 6.18) demonstrate a typical workflow in the app, indicated by the purple circles. The user can add, work on, edit and delete activities in the app. With this refined app, data is stored persistently in the cloud and can be synced to other iCloud-enabled devices. The app uses a grid-based design as this is considered appropriate for browsing content on the TV. [12] A tab bar is used to separate the input form from the other functionality in the app. Note how the app makes use of the full screen size to enhance the content (compared to the naive version), instead of being cluttered with table views and navigation items. Figure 6.19 shows the storyboard of the app. The images have been chosen so as to facilitate comparison with the iOS app in section 4.2 and the naive port in section 6.4.

Figure 6.11: Adding a new activity by moving the focus (right) to the Add activity tab, indicated by the Purple circle. Note the grid layout for the activity cells and the tab bar in the top.

61 Figure 6.12: Saving a new activity to the project by clicking the Save-button.

Figure 6.13: Selecting an activity to see its details.

62 Figure 6.14: Selecting a time interval to work on an activity.

Figure 6.15: The timer for the time interval (10 min) is running. The user can click the Play/Pause-button (on the remote control) to pause/resume the timer.

63 Figure 6.16: The time interval is done. The user clicks the Menu-button (on the remote control) to go back.

Figure 6.17: Marking the activity as done by pressing the Mark as done-button.

64 Figure 6.18: The activity is marked as done. Deleting an activity by pressing the Remove-button.

65 Figure 6.19: The storyboard of the refined tvOS app, with tab bar controller and grid-layout (collection view) for the activities. 66 Chapter 7

Case study: Interpretation and generalization

In this chapter, the results from the case study are analyzed and interpreted with help from app portability, smart TV and smart device research. First, the portability types and measures are analyzed. Next, the two porting approaches are compared, and lastly, app portability problems with smart devices are identified and discussed.

7.1 Analysis of portability types and measures

This section revisits two of Mooney’s [44] portability types - binary and source portability1 - and the developed portability model. Source portability is discussed by comparison of the two portability measures. Architectural portability is suggested as an additional portability type, to account for the portability of the application architecture.

7.1.1 Binary portability As mentioned in section 2.1.3, the same binaries won’t run on the iOS and tvOS platforms. Thus, binary portability (“perfect” portability) is infeasible. How- ever, since the platforms are similar - especially in terms of architectural layers, programming languages and API:s – a high degree of source portability was expected.

7.1.2 Source portability, and portability of specification & design The portability measures were calculated based on LOC and work hours, to enable comparison.

7.1.2.1 Portability based on LOC As was seen in Table 6.4, the portability measure using LOC and a naive approach was 0.72. Thus, for the naive approach, focused on minimum porting costs, there was indeed a high degree of source portability, as the number

1Experience portability is discussed in the following section.

67 is rather close to 1.0. Even Tanaka [53] (using a cut-off at 0.60) would consider this as effectively portable. As mentioned, Mooney [45] consider the app portable as long as the number is positive. For the refined app, the approach resulted in a figure of 0.08. While still portable according to Mooney [45], the figure is closer to zero which means that rewriting could be considered as a viable option to this porting approach.

7.1.2.2 Portability based on work hours As was seen in Table 6.5, portability based on work hours was separated into the specification & design activities, and the implementation activity. Thus, for the naive port, three measures were obtained: specification & design: 0.94, implementation: 0.54, and total 0.68. Here we see clearly, that the specification & design of the app was more portable than the source code itself. The implementation measure (0.54) should be compared with the LOC measure of 0.72. The difference could indicate that the modification of a LOC is indeed more costly (i.e. time consuming) than a newly written LOC, as argued by Tanaka [53]. In such case, the source portability would be somewhat overestimated by the LOC measure. However, for the refined port, the measures where: specification & design: 0.44, implementation: 0.18, and total 0.27. Here, there is a lower portability of specification & design compared to the naive version, i.e. the app needed to be respecified. As for the naive version, the implementation portability is lower than the portability of specification & design. Though, for the refined port, the implementation measure (0.18) is higher than the one obtained using LOC (0.08). This contradicts the theory that the LOC measures are overstated due to modifications being more time consuming.

7.1.3 Revisiting the portability model In general, the measures emphasize that portability depends on porting approach, i.e., if it is the minimum cost approach focused to get the app up and running, portability is higher. However, if the app should also be refined for and usable on the target platform, the additional adaptation decreases portability. Figure 7.1 illustrates the problem. Note that a shorter (blue) arrow indicate a higher degree of portability. While the platform similarity is the same with both approaches (green line), the adaptation needed and portability degree depend on the considered porting approach.

7.1.4 Architectural portability Related to specification & design, is the portability of app infrastructure – i.e. the architecture of the app. Thanks to the object-oriented philosophy (with loose coupling and high cohesion) and layered approach (with MVC), the infrastructure of the application was fairly stable (in both phases). For example, changes in the UI could be done without changing any model classes. Sim- ilarly, the persistent storage could be updated to account for iCloud, without affecting the UI. Thus, the clear structure, responsibilities and communication patterns (as discussed in section 3.5.3) in the app, supported the portability of the app. This is in line with Mooney’s statement that ”some design methods

68 Figure 7.1: Revisiting Mooney’s [44] application portability aspects, for the two porting approaches.

may be more favorable to portable design” (mentioning the example of object- oriented design) [45, p. 5].

7.2 Comparing the case study approaches

With the naive approach, the source code could be reused to a large extent, and little adaptation was needed. Thus, from a portability standpoint, this might appear as the optimal approach. However, the app developed with the naive approach had several caveats.

7.2.1 Why the naive approach is inappropriate

Here, some of the drawbacks of the app developed with a naive approach are presented.

7.2.1.1 The lack of persistent storage and sync

When specifying the conditions for porting the app, platform limitations weren’t considered. Thus, the naive version of Parallel-Progress-TV ended up lacking both persistent storage and the possibility of syncing with other devices. If sync and persistent storage would have been included in the specification, the port would have required further research of the platform and additional implementation (to account for the fact that local storage is unavailable on tvOS). Such research and improvements were performed for the refined version. It should be noted that smart devices are first and foremost seen as interactive and connected devices, so the interaction with other devices is definitely a key aspect. [64][66]

69 7.2.1.2 Interaction and navigation While the requirements demanded that the app should support some functionality (such as adding, removing, editing and working on activities), there was no emphasis on the usability of the app. The user interface was designed based on the iOS app, and although it was possible to navigate it with the remote, it was neither a clear nor convenient experience. Especially, the focus engine needed to be investigated in a deeper sense to understand how focus and the interaction model (with a remote) affects the usability of the app. Further, when evaluating the app, it was found that text input is rather inconvenient with the Apple TV keyboard (i.e. on the screen). [14] Thus, the input of data in a form-type manner, should be considered as an inconvenience and be avoided were possible. In the refined app, this was considered by making the form a secondary activity, separate from the main flow of the app. While it is possible to add a new activity (with all its details) on the TV, the sync of activities via iCloud enables users to instead use the iOS app for input.

7.2.1.3 Context of use A smartphone is a rather small device, with a small screen, held close by the user. On the contrary, smart TVs have large screens and are seen at a distance. When interacting at a distance, the screen size could not be used as effectively as first attempted. Having a dense user interface (with table views and navigation items) made the screen cluttered and navigation complicated. Further, text sizes and spacing needed to be adjusted for use at a distance, and the colors needed to be changed to consider the different color experience (on a TV). When using a remote, users expect that buttons are accounted for cor- rectly. [10] In the case of the naive version of the app, the Play/Pause-button was not implemented - which alienates the tvOS user (it basically feels like something is broken).

7.2.2 Experience portability As mentioned before, experience portability is the ability for users and developers to reuse their experiences from the original platform on the new platform. [44] While the possibility to reuse the developer experiences was rather good (with caveats such as the lack of date picker, the need to learn iCloud key-value storage to enable sync, the focus engine etc.), the portability of user experiences can be questioned. There are similar user interface components available on both platforms, which enabled a quicker construction of the naive port. However, when the elements were used similarly on both platforms, the navigation and usability of the tvOS app was rather inappropriate, which indicates a low extent of experience portability. Still, when the app had been refined to account for the new platform, the users were enabled to use the app for similar activities (in analogous ways) as the iOS app. This could be considered as some extent of experience portability - even though the navigation and interaction model were not portable.

70 7.2.3 Summary of concerns In general, the naive app (with high portability) is inappropriate because it fails to consider the platform limitations, the interaction model, the user interface guidelines and the user experiences on the platform. These are key competitive aspects on smart device platforms, where the users generally have high expectations. [26][40] In comparison, the refined app (with its lower portability) considers all of the above-mentioned aspects - since it was appropriately adjusted with the specific platform in mind.

7.3 Portability problems with smart devices

Based on the case study observations, app portability and smart device research, this section identifies portability problems in the domain of smart devices.

7.3.1 Programming paradigm and programming language Mooney [44][45] favors object-oriented design as a means for achieving portability. The goal is to partition the program into sensible pieces that can interact through interfaces, and to isolate non-portable parts. Similarly, separation and abstraction is highlighted by Johansson et al. [37], with the layered approach suggested as an appropriate architectural pattern. Thus, the selected programming paradigm can hinder or support portability, and should be thought through at early stages of an app development project. [45][37] Further, regarding programming languages, Johansson et al. [37] suggests to start with the most general programming language (e.g. Java) if the app is to be ported to other programming languages. This is in line with Tanaka’s [53] findings where the degree of portability rose after conversion from Fortran to the C language, and thus applies to both smart device and desktop domains.

7.3.2 Vendor lock-in In the desktop domain, standardization efforts such as the C language and POSIX (Portable Operating System Interface) have contributed to the portability of applications. [1][44][45][51] However, in the mobile domain, standardization attempts have been less successful. This is enforced by the fact that vendors in the domain differentiate themselves by providing different API:s, middleware and IDEs, for the competitive creation of rich applications and experiences. [1][41] As mobile vendors (e.g. Apple and Android) have added more smart devices to their smart portfolios (with the same strategy), the logic applies also for smart devices. Thus, the use of vendor-specific programming APIs can indicate a poorer extent of portability. [34] In the case of the iOS app, several vendor-specific APIs were used, such as the CoreData and iCloud frameworks. In fact, even the programming language (Swift) has been created by the vendor to support its applications.2 [56]

2Though, it should be noted that the programming language has now been made open source and is available on Linux.

71 7.3.2.1 In-vendor and between-vendors portability In-vendor portability and between-vendors portability impose different challenges. For in-vendor porting, using specific APIs and frameworks is less problematic: it speeds up the initial development process, provides consistent UIs and better performance. [41][26] However, it should be noted that by vendor choice or due to platform limitations, some specific API:s might still be unavailable (such as the lA.i2SB+F2` or the Core Data support for persistent storage on tvOS). Also, dependance on a specific vendor (vendor lock-in) can be problematic if the targeted vendor suddenly leaves the market, making all of its platforms obsolete. [51] For between-vendors porting, programming languages and specific APIs can become serious impediments to the porting process. These impediments are preserved in the smart device domain by the competitive need of vendors to differentiate themselves. [1][41]

7.3.3 Platform limitations As seen in the case study, it is important to investigate and consider the target platform’s specifics and limitations. Such limitations can include the lack of local persistent storage [4], the inconvenience of text input [48][14], the lack of screen space [48][41], unstable network access (in lack of a stable cable connection) [41], the CPU [41], the distance to the screen [36], the interaction model [40] etc. For example, text input is problematic both on smart watches (with a small screen) and smart TVs (with a remote). [48][13]

7.3.4 Data storage and migration Both platforms in the case study supported both the Core Data and iCloud frameworks. However, differences in the platforms and APIs meant that these could not be leveraged in the same way when considering the tvOS platform. Further, the change logs that were synced to iCloud in the iOS app aren’t interoperable with the key-value changes in the tvOS app. Thus, in line with Godo- nis et al. [34], incompatible data structures (such as SQLite and key-value storage) create portability issues. Further, there are related issues such as the data migration. [34] In the case of the Parallel Progress app, data migration from the original iOS app is not supported, but the iOS app have been updated to use the same storage model as the tvOS app. This means that any previous users of the iOS app will lose their data in the transitioning process, which is not preferable.

7.3.5 Context of use Context is important for smart device platforms. As argued by Fling regarding the mobile domain: “Context is what makes mobile such a powerful and ex- citing medium”. [32, p. 56] Context relates to the circumstances under which the app will be used, such as the place, time, privacy, interactions, motivations and state of mind. [32] While mobile devices, tablets and smart watches are battery-driven, wireless and can be carried and used for example on the bus, smart TVs are considered stationary and provided with a reliable connection

72 (often by wire, but can also be WiFi). This affects the services that can be provided to the user, as well as the privacy of interaction and the state of mind of the users. For example, smart watches are in near and prolonged contact with the user, and therefore can provide additional health data compared to other smart devices. [48]

7.3.5.1 Shared versus private devices In contrast to smart phones and smart watches which are often considered as private devices, research indicates that smart TVs should be considered as shared devices. [47][66][36][9]. A caveat of Parallel Progress-TV is the inconvenience of authentication when having several users. The user must then log out from the iCloud account, and log in to another account. Given the problematic text input, this can be a rather time consuming and awkward task. Even Apple themselves mentions it as an caveat, that only one iCloud account can be signed in at the time. [15] Similarily, Tanaka identifies user authentication as a portability problem, especially when a multi-user application is ported to a single-user OS. [53] While Apple TV is considered a shared device, the inconvenience of going into the system settings and performing the login task, makes tvOS feel more like a single-user OS. I.e., in the end the whole family is likely to use the account of one member.3

7.3.5.2 Interconnected devices Further, smart devices should be considered as interconnected devices, that can be used together to provide richer experiences. [43] The research area of second screens emphasize that the smart TV is not used on its own, but rather in a room full of smart devices. [47][66] Parallel Progress-TV acknowledges this aspect by providing sync with other iCloud enabled devices, as well as by making text input (the form) a secondary activity. The iOS app is thus considered as a companion app [66][14], where the user can more easily input new activities.

7.3.6 Navigation and interaction model For smart devices - with their different interaction models - navigation and interaction need to be considered, since this ensures that the app is navigable. While a touch screen (common on smartphones and tablets) provide flexibility, devices such as smart TVs can have a more limited (linear) model. [39] Con- sider the confusion and frustration for the user if it is not clear how to navigate the app.

7.3.7 UX, UI and performance User interfaces and user experiences should be considered a top priority, since users show high expectations for quality on smart device platforms. [40][1]

3Observed from private experiences with the platform.

73 For competitive reasons, development must emphasize UI consistency (con- forming to interface guidelines for each platform [26]), and usable and pleas- ing experiences. As concluded by Dhillon et al. regarding mobile platforms: “write once, run anywhere is currently not possible.” [26, p. 1348] When using cross-platform tools (such as web technologies) there is often worse performance compared to native development. [41][26] Thus, with smart device platforms, there is a tradeoff between app portability and user experience (in terms of UI consistency and performance). This will be referred to as the portability-versus-UX problem on smart device platforms.

7.3.8 Project and team aspects As pointed out by several authors, the developer skills available for a specific project influences the proper choice of tools and methods. [41][24] Depending on the specifics of the app, cross-platform development tools, (e.g. web technologies or specific tools) can sometimes be appropriate, to make the app more portable. As mentioned, these techniques still show weaknesses compared to native development in terms of performance and UI considerations. [26][41] When choosing such tools, evaluation frameworks such as the one developed by Dhillon et al. [26] can be used to analyze and select appropriate tools for the specific aims with the app. As a further problem, however, it should be noted that the research regarding cross-platform development tools is mainly focused on mobile-to-mobile development, not smart devices in general. Smart devices pose additional problems since cross-platform frameworks (like jQuery Mobile) can consider some devices (e.g. smartphone, tablet and desktop devices), but fail to consider others (e.g. smart watches and smart TVs). [38] Further, the tvOS platform supports neither browsers nor web views, so the app would need to be redeveloped anyhow. [24][31]

7.3.9 Quick evolvement When the iOS app was specified (early autumn 2015), the Apple TV (4th generation) had not been released yet. This is in line with Agarwal et al. [1], stating that quick evolvement and frequent introduction of new platforms is one of the main characteristics that complicate mobile portability compared to the desktop domain. In recent years, large vendors such as Apple and Android have introduced several new smart device platforms; including tablets, smart TVs and wearables. [2][60] Thus, Agarwal et al.’s observation can be considered more generally to apply in the area of smart devices.

7.3.10 Redeveloping the app Given the low portability of the source code when using the refined approach, smart device developers should at least consider rewriting – as it could in some cases be a viable option. Especially, redeveloping the app gives new opportunities to reimagine the app, and thus to better leverage the new platform in a competitive manner. However, some benefits were gained by porting the app rather than rewriting:

74 First, it was easier to leverage developer skills from the iOS platform when porting the app, rather than starting from scratch. That is, most of the code base could be reused, and the UI components could be connected to the existing code - so that only changes (e.g. missing functionality, different interaction model) for the new platform needed to be investigated. Also, because the iOS and tvOS apps coexist in the same project and share large extents of code, maintenance should be easier to perform. With this approach, it was also convenient to update the iOS app to account for the changes in data storage model (to be the same as for the tvOS app, i.e. with iCloud key-value storage). Additionally, even if the source code wasn’t portable, the application architecture was, and could therefore be leveraged throughout the project.

Chapter 8

Discussion

This chapter analyzes the methods used in the thesis, their implications, and answers each of the two research questions. Further, ethical and sustainability aspects related to the thesis work are discussed.

8.1 Methods and their implications for the study

In this section, some implications of the case study methods are discussed, followed by analysis of validity and reliability.

8.1.1 Initial portability The use of an object-oriented programming paradigm, with a layered architecture, indicates some extent of portability for the initial iOS app. [45][37] However, the iOS app was not designed with portability in mind, but rather focused on good programming praxis. The lack of portability concerns when developing the original app, is in line with Mooney’s [45] observation that portability often isn’t explicitly considered in the software development process. Thus, this mindset constitutes an unoptimal (for portability), but realistic, setting for investigating portability problems in software development. For the thesis of Johansson et al [37], the aim was to achieve a high degree portability of a mobile app, and then to port it. In this thesis, the goal is not to achieve portability, but to analyze the portability problems of apps in the domain of smart devices.

8.1.2 Vendor specific API:s The case study focused on a single target platform, but one could also consider broader categories such as the smart devices (e.g. smartphones, tablets, wearables, smart TVs and possibly smart cars) from different vendors.

The reasons for focusing on the tvOS platform and a native approach, with use of vendor-specific APIs, was:

1. The availability of the iOS app – which meant less redundant work with creating an initial application,

77 2. The arrival of tvOS – giving an interesting opportunity to investigate portability to a new platform,

3. The author’s experience in iOS development - which meant less time needed to be spent on learning new languages and APIs from scratch,

4. The identified lack of portability research between smart device platforms, i.e. many studies focus on mobile-to-mobile portability rather than different types of smart devices,

5. The view that performance and UX favor native approaches over cross- platform approaches – as found in literature [41][26],

6. The time constraints of the thesis.

Thus, with the chosen approach (within the platforms of a specific vendor), it was not possible to draw conclusions from the case study regarding the additional porting costs or issues caused by vendor lock-in. That could have been found if translating for example to an Android device. However, the investigation of literature suggests that such a porting process would pose additional problems, such as selection of and translation to another programming language. [37] Thus, the complementary analysis of research provided a basis to identify additional app portability issues in the area of smart devices.

8.1.3 Validity and Reliability Below, the concepts of validity and reliability are discussed, as it relates to the credibility of the conducted research.

8.1.3.1 Validity Validity refers to whether the research methods really measure what they are intended to measure, so that the collected data can be used to answer the research questions. [29][33][25] It should be rather clear how the case study addresses the research question regarding porting and refinement from iOS to tvOS, RQ2. Further, the case study provides input - in terms of the problems observed in a specific porting process - for answering the bigger research question regarding app portability problems with smart devices, RQ1. However, to improve the generalizability of findings, additional data was collected in form of app portability, smart TV and smart device research, so as to give a more nu- anced and complete picture of the studied phenomenon. With this collected data, additional app portability problems could be identified and analyzed, and the case study results could be better interpreted in the light of additional knowledge. The use of several complementary data collection methods is common in qualitative research - referred to as triangulation - with the goal to identify common themes and form theory based on various sources. [33]

78 8.1.3.2 Reliability The term reliability refers to the trustworthiness, correctness and applicability of a measurement and the measurement method. [29][25] This addresses the ”idea of replicability or repeatability of results or observations.” [33, p. 598] However, Golafshani [33] questions the role of replicability for qualitative research, where the focus is on clarification, interpretation and generalization of phenomena observed in a context-specific or real world setting. Further, these settings are subject to change, which means that repeatability of observations can be rather problematic. For the performed case study, some concerns should be noted. First, the cases study (and its observations) is based on the development efforts of the author, and thus relies on the skill and knowledge that she has acquired from previous courses. It is thus possible that a different schooling or skill set could result in a different solution. Second, in line with Golafshani’s [33] concern, there is a quick evolvement in the area of smart devices, which means that the same porting process might need to consider new portability aspects over time, and that new devices are constantly added. For example, Apple recently added the support for pairing the Apple TV with a bluetooth keyboard, which affects the convenience of text input. Over time, such a solution could become a standard way of interacting with the TV, and thus overcome one of the platform limitations that was identified in the case study. A third concern relates to some of the sources used for the platform research, such as blogs and news articles. These provide additional insights into a new platform, where the research is still in its infancy. Thus, they are considered highly relevant. However, the problem in general when using web pages as sources is that it can be problematic for others to check the facts (and their validity and reliability), since the pages might have changed since the data was collected. [25, p. 120]

8.2 Revisiting the research questions

This section addresses the research questions one by one.

RQ1. What problems of app portability arise when porting between smart devices?

Based on the analysis of the case study, and portability and smart device research, the following app portability issues were identified when considering smart devices, as discussed in section 7.3.

App portability problems with smart devices:

1. The choice of programming paradigm and language

2. The use of vendor specific APIs (enforced by fragmentation)

3. Platform limitations (e.g. text input)

4. Data storage and migration

79 5. Context of use (e.g. privacy, interconnectedness)

6. Navigation and interaction

7. Portability-versus-UX

8. Project and team aspects (e.g. developer skills)

9. The quick evolvement in the area

10. Whether the app should be ported at all, or rather reimagined

Problem 1, 2, 4, 7 and 8 can probably benefit from being considered as early as when developing the original app, to think through the portability strategy of the project. Problems 3, 5, 6 and 10 need to be considered in terms of the targeted platform. Due to problem number 9 (quick evolvement) this might not be possible to do in advance, i.e., the platform might not even exist yet.

RQ2. How can a productivity app implemented on iOS be ported and refined for tvOS?

The complete process of porting an existing productivity app from iOS to tvOS has been described in detail. To address the research question, the app was ported in two phases: the naive phase, which focused on source portability and minimum porting costs, and the refined phase which considered adaptation to the target platform. The summarized steps of the porting process were presented in Table 6.1 for the naive phase and Table 6.2 for the refined phase. The case study highlights the fact that it is not enough to just make the app runnable on a new platform (by porting the source code and rebuilding the same UI). Further adaptations are needed to consider the appropriateness for the targeted platform. Such adaptations can be related to data storage, input, screen size, navigation and interaction model, context of use etc. To perform such adaptations, the development activities of specification and design needed to be revisited. Since the portability, given all these adaptations, can be rather low, developers need to make a decision whether it is at all appropriate to port a specific app - or if it should rather be redeveloped and reimagined from scratch. As discussed in section 7.3.10, there can still be some benefits of choosing a porting approach, even if the costs (i.e. LOC or work hours) would be similar if redevelopment was chosen.

8.3 Sustainability

The Swedish Government provides documents regarding sustainable development. Sustainable development “aims to secure good environment and health, economic growth, welfare and social justice for present and future genera- tions” [49, p. 8 (tr.)] Thus, sustainable development should be both environmental, economical and social. Below, sustainability aspects (including ethical aspects) related to the thesis work are highlighted.

80 8.3.1 Portability and sustainability At heart, portability is a research area heavily related to sustainable development, since it focuses on effective resource consumption by reusing an already developed application. Thus, a high degree of portability indicates a cost-effective approach - and should be considered as economically sustainable. However, as described in this thesis, there are several impediments (such as vendor lock-in) that can make a portable strategy less attractive on smart devices, compared to other platforms (such as desktop computers).

8.3.2 Smart devices and sustainability Regarding smart devices, there are both environmental, ethical and social aspects to consider.

8.3.2.1 Environmental burden This thesis encourages developers to leverage a new smart device platform. However, with more and more devices, one should recognize the environmental burden in terms of power and resource consumption, and additional garbage management. It should be considered whether the benefits of the new technology outweigh the negative environmental impact. And if they do, it should also be considered how the negative impact can be minimized.

8.3.2.2 Privacy concerns The main ethical concern that was identified during the thesis work, was the privacy – or rather lack of privacy – when using an app on the tvOS platform. Authentication with iCloud is cumbersome, therefore it is likely that one user stays logged in most of the time, and thereby exposes private data. This could be a possible reason why productivity apps still are limited in numbers on the tvOS platform. The authentication problem should be considered a platform specific caveat, likely to be improved in the future. However, in general developers need to consider how data is handled in environments where apps span over different types of connected devices - where some are of the shared type and where others are more private. Roux et al. argue that the injury caused by privacy concerns regarding smart devices might be underestimated, since the role of these devices as “extensions of users’ cognitive capability” is often not considered. [50, p. 183]

8.3.2.3 Social consequences Further, will there be social injustice when some individuals can afford a mul- titude of smart devices (smartphone, tablet, smart watch, smart car, smart TV, etc) - that might be used as extensions of cognition [50] and need to be bought frequently to keep up with new advancements - while other individuals might not be as fortunate? And given the negative impact on cognitive capabilities, as described by Maurer [42], will there be a sustainable way to increase the dependance on smart technologies, while keeping our creative and independent thinking at reasonable levels?

Chapter 9

Conclusions

This chapter summarizes the conclusions of the thesis and its implications, as well as gives suggestions for future research paths.

9.1 Summary

The objective of this thesis was to present an app porting process, and to investigate app portability problems in the smart device domain. The case study focused on the porting process from iOS to tvOS, divided into two phases. Based on the porting experiments, a complete porting process could be presented and analyzed. The results suggest that source code portability for smart device apps can be rather low, since the apps need to be adjusted properly to account for platform specifics. That is, it is not enough to just make an app runnable on a new platform (by porting the source code and rebuilding the same UI). Further, the case study results were interpreted and analyzed in the light of app portability, smart device and smart TV research. This enabled the identification of several app portability problems in the smart device domain - such as quick evolvement in the area, vendor lock-in, choice of programming paradigm, context of use, platform limitations, portability-versus-UX, interaction model and more.1 Lastly, it was considered whether porting of smart device apps would make sense at all, since the source portability was rather low, and there can be reasons to reimagine an app for a new platform. However, even if the source code isn’t very portable, some advantages of porting were discussed - such as future code maintenance if the targets can be administered in the same project. Further, the infrastructure of the app (the architecture) was considered as portable, which made the process easier compared to starting from scratch.

9.2 Implications

The literature study identified a lack of research regarding app portability for smart devices. Thus, the main contribution of the thesis, was to present a com-

1See section 8.2 for the complete list.

83 plete between-smart devices porting process,2 and to combine smart device and application portability research to present portability problems specifically for the smart device domain. This will aid developers to make informed decisions in a domain where the complexity is high - due to quick evolvement, introduction of new platforms, high user expectations and high fragmentation. The thesis illustrated how a productivity app can be ported to a smart TV platform. Even if entertainment apps are expected to continue to dominate the platform, the author suggests that the role of the TV can be broadened to consider a wider spectrum of apps, including utility and productivity apps. The main caveat is still the privacy concerns, as the TV is a shared device, and login is still inconvenient. This problem is assumed to be addressed in the future by the specific platform vendors, since users will likely request such features. The thesis contributes to the research area of app portability and smart devices, which is still in its infancy, but is likely to grow as more and more devices are added to this interconnected and interactive domain. Research areas such as the Internet of things, mobile computing and machine learning are likely to contribute to the smart devices domain so as to leverage their advantages and improve the quality of life for people. [43]

9.3 Future research

While the thesis gives a thorough introduction to app portability issues for smart devices, additional research needs to be conducted. First, the case study focuses on a single vendor and the porting between two specific platforms. Thus, additional research could follow up by investigating a broader set of vendors and platforms, and thus verify and complete the results. Second, the use of cross-platform tools (web technologies, intermediate representations etc) is heavily investigated regarding the mobile domain, but additional research is needed to verify whether such approaches are feasible and available for targeting a broader set of smart devices. Third, the concept of companion apps used on different types of platforms should be investigated. For example, a specific firm might have a cooking app. On a smartphone, there might be possibilities to browse the recipes, see their details and check off the performed steps. However, in a companion app on the smart watch, only the steps and timers might be available after selecting the recipe on the phone (or TV). On the smart TV, the app might be similar to the smart phone version, but include videos to demonstrate the cooking proce- dures. This way, smart devices can be used together to leverage their specific advantages and give a richer overall experience. Fourth, as the domain grows, the role of the smart device developer becomes more complex. Research could consider how the developer role is affected - does the mobile developer now also develop for smart TVs, smart watches and smart cars, or are there specific developers for each device? How is the value of developer skills (and the developer freedom) affected with the high dependance on vendor-specific APIs (lock-in) and the quick evolvement in the field?

2Rather than to focus on mobile-to-mobile or similar.

84 Bibliography

[1] V. Agarwal, S. Goyal, S. Mittal, and S. Mukherjea. Mobivine: a middleware layer to handle fragmentation of platform interfaces for mobile applications. In Proceedings of the 10th ACM/IFIP/USENIX Interna- tional Conference on Middleware, page 24. Springer-Verlag New York, Inc., 2009. [2] Android Developers. Online: http://developer.android.com/about/vers- ions/lollipop.html (Visited: 2016-02-03). [3] Apple. App Programming Guide for tvOS. Online: https://developer- .apple.com/library/tvos/documentation/General/Conceptual/AppleTV_- PG/ (Visited: 2016-05-13). [4] Apple. App Programming Guide for tvOS: About Apple TV. (Online. Vis- ited: 2016-05-13). [5] Apple. App Programming Guide for tvOS: Building Apple TV apps. (On- line. Visited: 2016-05-13). [6] Apple. Apple special event: September 9, 2015. Online video: http://www.apple.com/apple-events/september-2015/ (Visited: 2015- 11-11). [7] Apple. Apple TV HIG. Online: https://developer.apple.com/tvos/human- interface-guidelines/ (Visited: 2016-04-28). [8] Apple. Apple TV HIG: Interface elements. (Online. Visited: 2016-04-28). [9] Apple. Apple TV HIG: Overview. (Online. Visited: 2016-04-28). [10] Apple. Apple TV HIG: Remote and controllers. (Online. Visited: 2016- 04-28). [11] Apple. Apple TV HIG: User interaction. (Online. Visited: 2016-04-28). [12] Apple. Apple TV HIG: Visual design. (Online. Visited: 2016-04-28). [13] Apple. Apple TV Tech Talks videos. Online video: https://developer- .apple.com/videos/techtalks-apple-tv/ (Visited: 2016-04-25). [14] Apple. Apple TV Tech Talks Videos: Best practices for designing tvOS apps. (Online video. Visited: 2016-04-25). [15] Apple. Apple TV Tech Talks Videos: On-Demand resources and Data storage. (Online video. Visited: 2016-04-25).

85 [16] Apple. iOS Developer Library: iCloud Design Guide: Design- ing for Core Data in iCloud. Online: https://developer.apple- .com/library/ios/documentation/General/Conceptual/iCloudDesign- Guide/Chapters/DesignForCoreDataIniCloud.html (Visited: 2016-05- 19).

[17] Apple. iOS Developer Library, iOS Technology Overview: About the iOS technologies. Online: https://developer.apple.com/library- /ios/documentation/Miscellaneous/Conceptual/iPhoneOSTech- Overview/Introduction/Introduction.html (Visited: 2016-04-06).

[18] Apple. iOS Developer Library: UIKit Framework Reference: UIS- toryboardSegue. Online: https://developer.apple.com/library/ios- /documentation/UIKit/Reference/UIStoryboardSegue_- Class/index.html (Visited: 2016-04-14).

[19] Apple. iPhone 6s, Tech Specs. Online: http://www.apple.com/iphone- 6s/specs/ (Visited: 2016-06-08).

[20] Apple. tvOS Developer Library. Online: https://developer.apple- .com/library/tvos/navigation/ (Visited: 2016-05-23).

[21] Apple. tvOS Developer Library: iOS 9.1 to tvOS 9.0 API Diffs. Online: https://developer.apple.com/library/tvos/releasenotes/General/tvOS- 90APIDiffs/ (Visited: 2016-01-29).

[22] Apple Developer Forums. Discussion on Core Data started 2015-09- 16. Online: https://forums.developer.apple.com/thread/18116 (Visited: 2016-05-13).

[23] Apple Press Info. Apple sells one millionth iPhone. Online: http://www.apple.com/pr/library/2007/09/10Apple-Sells-One- Millionth-iPhone.html (Visited: 2016-01-31).

[24] J. Beers, E. Cerney, S. Davies, E. Dekhayser, J. Greene, M. Katz, K. Lau, J. Martin, and M. Oliver. tvOS Apprentice: Beginning tvOS Develop- ment with Swift 2. raywenderlich.com Tutorial Team, Razeware LLC, 2016.

[25] P. Blomkvist and A. Hallin. Metod För Teknologer : Examensarbete Enligt 4-fasmodellen. Lund: Studentlitteratur, 2014, 1st ed.

[26] S. Dhillon and Q. H. Mahmoud. An evaluation framework for cross- platform mobile application development tools. Software: Practice and Experience, 45(10):1331–1357, 2015.

[27] Dmitriy K., Cleveroad. How to develop for tvos: First face-to-face experience. Online: https://www.cleveroad.com/blog/how-to-develop-for- tvos-first-face-to-face-experience (Visited: 2016-06-09).

[28] D. Eggert. objc.io: Issue 4: Core Data, September 2013: Core Data Overview. Online: https://www.objc.io/issues/4-core-data/core-data- overview (Visited: 2016-04-14).

86 [29] R. Ejvegård. Vetenskaplig metod. Lund: Studentlitteratur, 2009, 4th ed.

[30] S. Eklund. Arbeta i projekt : individen, gruppen, ledaren. Lund : Stu- dentlitteratur, 2011, 4:2 ed.

[31] A. Fish. 200MB max, no storage, no web views: Is tvOS the future of apps? Online: https://realm.io/news/is-tvos-the-future-of-apps/ (Vis- ited: 2016-06-17).

[32] B. Fling. Mobile design and development: Practical techniques for creating mobile sites and web apps. Sebastopol, CA: O’Reilly, 2009, 1st ed.

[33] N. Golafshani. Understanding reliability and validity in qualitative research. The Qualitative Report, 8(4):597–606, 2003.

[34] F. Gonidis, A. J. H. Simons, I. Paraskakis, and D. Kourtesis. Cloud application portability: An initial view. In Proceedings of the 6th Balkan Conference in Informatics, BCI ’13, pages 275–282, New York, NY, USA, 2013. ACM.

[35] P. Hegarty. Stanford CS193p, Developing iOS 8 apps with Swift: Lecture 2. Stanford’s School of Engineerging. Video available through iTunes U. (Accessed: 2016-04-07), 2015.

[36] J. Jain and A. Aula. Invited sig: Designing for the living room tv experience. In CHI ’12 Extended Abstracts on Human Factors in Computing Systems, CHI EA ’12, pages 1169–1172, New York, NY, USA, 2012. ACM.

[37] A. Johansson and J. Svensson. Techniques for software portability in mobile development. Blekinge Institute of Technology, School of Engi- neering, Department of Systems and Software Engineering, 2009.

[38] jQuery. A touch-optimized web framework. Online: https://jquerymob- ile.com (Visited: 2016-05-31).

[39] T. Klein. What’s so different about tvOS? an iOS Developer’s thoughts. Online: blog.prolificinteractive.com/2015/10/13/whats- so-different-about-tvos-an-ios-developers-thoughts/ (Visited: 2016-05- 20).

[40] D. Loi. Tv reinvented: Designing pleasurable interfaces for the living room. In Proceedings of the 2011 Conference on Designing Pleasurable Products and Interfaces, DPPI ’11, pages 18:1–18:4, New York, NY, USA, 2011. ACM.

[41] E. H. Marinho and R. F. Resende. Native and multiple targeted mobile applications. In Proceedings of the 15th international conference on Com- putational Science and Its Applications, Part IV, pages 544–558, Cham, 2015. Springer International Publishing.

[42] H. Maurer. Does the internet make us stupid? Commun. ACM, 58(1):48– 51, Dec. 2014.

87 [43] M. Miraoui, N. Rtimi, R. Cherif, and C. Tadj. Context-aware services adaptation for a smart living room. In Computer Applications Research (WSCAR), 2014 World Symposium on, pages 1–5, Jan 2014.

[44] J. D. Mooney. Strategies for supporting application portability. Com- puter, 23(11):59–70, Nov 1990.

[45] J. D. Mooney. Bringing portability to the software process. Dept. of Statistics and Comp. Sci., West Virginia Univ., Morgantown WV, 1997.

[46] Oxford dictionary. Agile - definition in english. Online: http://www.oxforddictionaries.com/definition/english/agile (Visited: 2016-02-22).

[47] M. Punt, M. Z. Bjelica, V. Zdravkovic, and N. Teslic. An integrated environment and development framework for social gaming using mobile devices, digital tv and internet. Multimedia Tools and Applications, 74(18):8137–8169, 2014.

[48] R. Rawassizadeh, B. A. Price, and M. Petre. Wearables: Has the age of smartwatches finally arrived? Commun. ACM, 58(1):45–47, 2015.

[49] Regeringens skrivelse 2003/04:129. En svensk strategi för hållbar utveckling. Miljö- och energidepartementet, 2004.

[50] B. Roux and M. Falgoust. Information ethics in the context of smart devices. Ethics and Information Technology, 15(3):183–194, 2013.

[51] D. V. Silakov and A. V. Khoroshilov. Ensuring portability of software. Programming and Computer Software, 37(1):41–47, 2011.

[52] J. Stankovic. Research directions for the internet of things. Internet of Things Journal, IEEE, 1(1):3–9, Feb 2014.

[53] M. Tanaka. A study of portability problems and evaluation. In Soft- ware Maintenance, 1992. Proceerdings., Conference on, pages 90–95, Nov 1992.

[54] TechCrunch. iOS apps can now be twice as big. Online: http://techcrunch.com/2015/02/12/ios-app-size-limit/ (Visited: 2016- 06-08).

[55] W. M. Trochim. The Research Methods Knowledge Base. 2nd ed, online: http://www.socialresearchmethods.net/kb/dedind.php (Last re- vised: 2006-10-20).

[56] Verge. Apple’s new programming language Swift is now open source. On- line: http://www.theverge.com/2015/12/3/9842854/apple-swift-open- source-released (Visited: 2016-05-25).

[57] Verge. Hands-on with the new Apple TV. Online: http://www.theverge.com/2015/9/9/9297131/new-apple-tv-update- remote-2015-hands-on-video-photos (Visited: 2016-05-10).

88 [58] Verge. iPhone 6S has twice as much RAM as iPhone 6, teardown con- firms. Online: http://www.theverge.com/2015/9/26/9401563/iphone- 6s-teardown-ram-confirmed-2gb (Visited: 2016-06-08).

[59] J. West and M. Mace. Browsing as the killer app: Explaining the rapid success of Apple’s iPhone. Telecommunications Policy, 34(5–6):270 – 286, 2010. [60] Wikipedia. Apple Inc. Online: https://en.wikipedia.org/wiki/Apple_- Inc. (Visited: 2016-01-29). [61] Wikipedia. Apple TV. Online: https://en.wikipedia.org/wiki/Apple_TV (Visited: 2016-01-31). [62] Wikipedia. iOS. Online: https://en.wikipedia.org/wiki/IOS (Visited: 2016-04-06). [63] Wikipedia. Operating system. Online: https://en.wikipedia.org- /wiki/Operating_system (Visited: 2016-04-05). [64] Wikipedia. Smart device. Online: https://en.wikipedia.org- /wiki/Smart_device (Visited: 2016-05-25).

[65] Wikipedia. Smart TV. Online: https://en.wikipedia.org/wiki/Smart_TV (Visited: 2016-05-25).

[66] S. Wilson. In the living room: Second screens and tv audiences. Televi- sion & New Media, 17(2):174–191, 2016.

[67] J. Zhang and X. Li. Cross-platform transplant of embedded smart devices. Journal of Software, 5(10):1084–1090, 10 2010.

Appendix A

Investigated blogs and news articles

91 Article Type Covers 200MB Max, No Storage, No Web Views: Is tvOS the Future of Apps? Company blog Developer experiences Adam Fish, 2015-10-23 and platform analysis realm.io/news/is-tvos-the-future-of-apps/ Apple’s tvOS for developers (Infographic) Company blog Overview of tvOS Natalya K., 2015-09-18 development cleveroad.com/blog/apples-tvos-for-developers-infographic How to develop for tvOS: First face-to-face experience Company blog Developer experiences Dmitriy K., 2015-12-01 cleveroad.com/blog/how-to-develop-for-tvos-first-face-to-face-experience What’s so different about tvOS? An iOS Developer’s Thoughts Company blog Overview of tvOS Thibault Klein, 2015-10-13 development blog.prolificinteractive.com/2015/10/13/whats-so-different-about- tvos-an-ios-developers-thoughts/ Mastering the tvOS Focus Engine Company blog Overview of Focus Michael Bachand & Adam Michela, 2015-09-11 Engine nerds.airbnb.com/tvos-focus-engine/ Developing tvOS Apps Personal blog Developer experiences Maz, 2015-12-10 mazyod.com/blog/2015/12/10/developing-tvos-apps/ Hands-on with the new Apple TV News article Experiences when using Nilay Patel, 2015-09-09 Apple TV theverge.com/2015/9/9/9297131/new-apple-tv-update-remote-2015- hands-on-video-photos tvOS, The Focus Engine, and Swift Presentation Developer experiences Evan Maloney, 2015-10-13 at iOSoho slideshare.net/EvanMaloney/tvos-the-focus-engine-and-swift 92 Table A.1: Investigated blogs and news articles regarding tvOS/developing for tvOS (Online. Visited 2016-05-20).

TRITA TRITA-ICT-EX-2016.47