The iOS 7 Core Bluetooth Framework (CB) is finally at a level where it can be used in projects to create valuable iOS applications. Due to its maximum broadcast radius of 30ft it lends itself to nearby communication. This thesis explores the Bluetooth space generally before delving into location-based data transfer using Bluetooth. The CB provided by Apple is powerful, but somewhat cumbersome. It forces the developer to deal with details related to device discovery and connections which can be tangential to the goal of the developer: sending data between devices. I built the Lightweight Bluetooth Framework (LBF) which makes the features of the CB more accessible by abstracting away from the implementation details of CB. LBF supports any number of data types being transferred as well as any number of total pieces of data regardless of data type. The system accomplishes this by assigning specific Characteristics to a particular data type and having pieces of data be uniquely identified with an ID when they are broadcasted. This unique ID is then used to associated the proper object with the received data. This will enable developers to focus on the implementation of their App without getting hung up on the details of the CB. Additionally, benchmark tests are done on the Lightweight Bluetooth Framework to determine what data transfer speed the framework supports. These tests reveal that transfer speed depends on hardware, but independent of hardware are too slow to transfer images, video, or sound.

Kriminalvården är den myndighet i Sverige som ansvarar för fängelser, häkten och frivård. Myndigheten har länge känt ett behov att inom flera verksamheter kunna få tillgång till delmängder av deras klientsystem i ett mobilt och uppkopplat format. Det största hindret i deras fall med mobilitet och applikationsteknik var säkerheten. Därför genomfördes en riskanalys med hänsyn till frivården och mobilapplikationsteknik. För att välja en lämplig och passande riskanalysmetod jämförde vi ett antal metoder. Det visade sig att metoden CORAS passade bäst. När vi väl genomfört riskanalysen med CORAS försökte vi sedan matcha åtgärderna mot de olika mobilplattformarnas egenskaper för att se hur de kan fullfölja åtgärderna. Mobilplattformarna vi undersökte var Android, Windows Phone 8 och iOS. Resultatet av riskanalysen och jämförelsen av plattformar kan ligga som grund till beslut hos Kriminalvården. / Kriminalvården is the government agency in Sweden which is responsible for prisons, jails and probation. The agency has realized a need of access to a several features of their inmate register systems from mobiles and handsets within different areas in their organization. The safety with the mobility and application technology is a comprehensive issue in this case. Therefore, a risk analysis about mobile application technology was initiated. We took the probation services into account as a concrete scenario where mobile application technology could be used. In order to select an appropriate and adequate risk analysis method, we compared a number of methods. It turned out that the method CORAS was the most suitable method. When we completed the risk analysis with CORAS, we tried to match the treatments against different mobile platforms properties to see how they can pursue the treatments. Mobile platforms we examined were Android, Windows Phone 8 and iOS. The result of the risk analysis and the comparison of mobile platforms can the agency use as a basis for further decisions.

The purpose with this thesis is to investigate whether Sprite Kit is a good tool to simplify the development process for game developers when making 2D games for mobile devices. To answer this question a simple turn based strategy game has been developed with Sprite Kit. Sprite Kit is a game engine for making 2D games released by Apple. Based on the experience I got during the development I will go through and discuss some of the most important tools provided by the game engine and how they helped us to complete our game. The conclusions I reached after making a game with Sprite Kit is that the frame- work provides all the tools necessary for creating a simple 2D mobile game for iOS. Sprite Kit hides much of the lower level details and gives the game de- veloper comprehensive development support. This helps the game developer to save a lot of time and focus more on the gameplay when creating a game.

Den här studien undersöker för- och nackdelar med att migrera existerande mobilaapplikationer till Xamarins crossplatform ramverk Xamarin Forms. Metoden somanvänts för att samla in data är inom ramen för forskningsparadigmet Design Science.En prototyp har utvecklats med syftet att undersöka vad som är möjligt att migrera tillXamarin Forms. Prototyputvecklingen har dokumenterats i loggböcker som sedananalyserats som kvalitativ data. Två intervjuer har även genomförts med andraxamarinutvecklare med syftet att nå en djupare förståelse för ämnet. Studien harproducerat ett flödesschema för när ett beslut om att migrera en existerande applikationtill Xamarin Forms bör tas. Vid beslut om migration har vi även formulerat ett antalriktlinjer som bör efterföljas för att uppnå bra resultat. Flödesschemat och riktlinjerna ärbaserade på resultaten från analysen av loggböckerna och intervjuerna. / This study investigates the pros and cons of migraiting existing mobile applications toXamarins crossplatform framework Xamarin Forms. The method that is being used tocollect data is within the scope of the research paradigm Design Science. A prototype ofan existing mobile application has been developed in order to research the possibilitiesof migraiting existing applications to Xamarin Forms. The development process of theprototype has been documented in journals which later were to be analyzed asqualitative data. Two interviews have been done with other Xamarin developers in orderto get a deeper understanding of the subject. This study produced a flowchart that is tobe used when deciding about a migration of an existing mobile application aswell asguidelines for the migration itself. The flowchart and guidelines are based on analyzingthe data from our journals aswell as our interviews with other developers.

Developing apps for both Android and iOS has previously necessitated two different code bases in the platforms’ native languages. Creating an app would be a quicker and easier process if they could be written once and run on both platforms, and such solutions have been appearing over the last few years. One of them is React Native, which we will investigate in this paper. To investigate React Native’s capabilities, we are going to look into the feasibility of porting the Android and iOS versions of an already existing fitness app, developed by a software consulting company. The original app uses Bluetoothfunctionality to record users’ heart-rate during exercise. They want to know if they can switch to React Native and a single code-base for future installments, lessening the workload and making it more maintainable. In order to find out if it is advisable to recreate the app with React Native we attempt a port of the app, looking at performance, functionality, and the codebase. The code-base investigation focuses on what parts can become completely platform independent and where we need to fill in the gaps with code targeted to a certain platform, and how large our port is in relation to the equivalent code in the original app. We end up finding that performance is severely worse on iOS, with much higher CPU utilization when the Bluetooth functionality is in use. On Android the difference is noticeable but not quite as big. For functionality we could get everything working with a single code-base except for handling Bluetooth while the app is in the background on Android. The code-base is mostly platform independent, and where it is not this is due to differing Bluetooth implementations for the platforms. It is also larger than either of the original apps, but smaller than the two put together. Lastly, we conclude that React Native has a largely platform-independent codebase, and for simpler apps where less complex functionality is needed we suspect the code-base can be completely platform-independent. The cause and remedies to iOS performance ought to be further investigated, but React Native is capable for this particular use-case.

The traditional or the native way to develop mobile applications is to use Java for Android and Objective-c or Swift for iOS. The native way is favored by many since the code and the functionality is optimized for the platform. An- other way to develop mobile applications is to do it the non-native way, with a programming language or technique not made for the platform. This approach has for long been frowned upon due the limited hardware access and perfor- mance loss. React Native and NativeScript offers mobile application develop- ment in a non-native way said full access to the native platforms API using JavaScript all from a single code base. The aim of this thesis has been to de- velop and compare four proof of concept applications of which two are devel- oped natively for Android and iOS and the other are developed using the non- native React Native and NativeScript. The comparison is based on three as- pects: accessing the device’s native hardware and APIs based on what the com- pany Dewire requires from mobile applications, the performance difference on the respective platform and code reusability cross platform. There is no big dif- ference between React Native and NativeScript when comparing native access and everything that was accessible on the native implementation was accessible on the non-native implementation. Based on the performance measurements, React Native falls behind NativeScript. NativeScript handles long lists better than React Native. Lastly a discussion is presented regarding code reusability when developing non-native applications along with some experienced best practices when doing so.

Det ha r examensarbetet a r en uppdatering utav SCA logistics befintliga mobil applikation. Arbetet a r gjort hos IT- fo retaget Easit ab som fo rvaltar SCA' logistics system. Applikationen anva nds fo r att spa ra fo retagets ba tar pa en karta och inneha ller kontaktuppgifter till ansta llda. Arbetet fo r det ha r projektet kommer att beskrivas fra n grunden om hur det a r att med fria ha nder kunna va lja det ramverk som passar ba st. Med dom krav som fo retaget har sta llt pa att applikationen ska inneha lla sa kommer flera ramverk att underso kas. Fo r att komma fram till vilket ramverk som ska anva ndas sa har tva prototyper gjorts som anva ndare provko rt och da refter svarat pa en underso kning. Utvecklingen av applikationen kommer att go ras med det ba st la mpade ramverket. Designen kommer att vara genuin sa att anva ndarna ma rker skillnad mellan dom olika plattformarna. Applikationen kommer kunna byggas pa med mer funktioner och uppdateras utan att man beho ver ladda upp till app store och google play.

Geographical Information Systems and geospatial data are seeing widespread use in various internet and mobile mapping applications. One of the areas where such technologies can be particularly valuable is aeronautical navigation. Pilots use paper charts for navigation, which, in contrast to modern mapping software, have some limitations. This project aims to develop an iOS application for phones and tablets that uses a GeoPackage database containing aeronautical geospatial data, which is rendered on a map to create an offline, feature-based mapping software to be used for navigation. Map features are selected from the database using R-Tree spatial indices. The attributes from each feature within the requested bounds are evaluated to determine the styling for that feature. Each feature, after applying the aforementioned styling, is drawn to an interactive map that supports basic zooming and panning functionalities. The application is written in Swift 3.0 and all features are drawn using iOS Core Graphics

A big problem with mobile application development is that the mobile market is divided amongst several platforms. Because of this, development time gets longer, more development skills are needed and the application gets harder to maintain. A solution to this is cross-platform development, which allows you to develop an application for several platforms at the same time. Since September 2015 the cross-platform framework React Native, created by Facebook, has been available for public use. This thesis evaluates React Native, for both Android and iOS, in regards to performance, platform code sharing as well as look and feel. An application was developed for both platforms, one version using the native language and one version using React Native. The different versions were compared through automated test scenarios to evaluate performance, manual code review for platform code sharing and with a user study to evaluate the look and feel. The results show promise as the user study shows that the React Native versions of the application have similar user experiences as their native counterparts without significantly affecting performance. The results also show that for the specified application about 75% of the React Native code could be used for both platforms, while it was easy to add platform-specific code.

With the increase of iOS applications on the market the demand and use of Backend as a Service (BaaS) providers also increase. In an early phase of the development it is beneficial for a potential application publisher to use a BaaS to quickly reach the market. Over time the provided services may be inadequate which make many BaaS users migrate to a custom developed backend. This paper intends to investigate which BaaS provider gives the least dismissed effort when making a transition to a custom developed backend with the purpose of providing basis for potential application publishers in the selection of a provider, given that a future transition to a custom backend will occur. From a population of ten providers, five were randomly selected – Firebase, Kinvey, CloudMine, Kumulos and Kii. In order to measure required effort for each provider, code that is tightly coupled to each provider’s SDK was implemented, according to provider guidelines and documentation. The implementations were measured with the COCOMO II model which gives a result in terms of required person months (PM). The measured PM of each implementation was compared. The hypothesis of the study could be rejected if the resulting PM of two implementations were disjointed. The result and analysis show difference in PM which lead to a rejection of the hypothesis. Whether the assumptions of the organization, product and project affected the results were analysed and the hypothesis was rejected regardless of these assumptions. If the organization of a potential application publisher resembles the one in the research Firebase is the recommended choice of BaaS provider.