Creating a mobile application often requires the developers to create one for Android och one for iOS, the two leading operating systems for mobile devices. The two applications may have the same layout and logic but several components of the user interface (UI) will differ and the applications themselves need to be developed in two different languages. This process is gruesome since it is time consuming to create two applications and it requires two different sets of knowledge. There have been attempts to create techniques, services or frameworks in order to solve this problem but these hybrids have not been able to provide a native feeling of the resulting applications. This thesis has evaluated the newly released framework React Native that can create both iOS and Android applications by compiling the code written in React. The resulting applications can share code and consists of the UI components which are unique for each platform. The thesis focused on Android and tried to replicate an existing Android application in order to measure user experience and performance. The result was surprisingly positive for React Native as some user could not tell the two applications apart and nearly all users did not mind using a React Native application. The performance evaluation measured GPU frequency, CPU load, memory usage and power consumption. Nearly all measurements displayed a performance advantage for the Android application but the differences were not protruding. The overall experience is that React Native a very interesting framework that can simplify the development process for mobile applications to a high degree. As long as the application itself is not too complex, the development is uncomplicated and one is able to create an application in very short time and be compiled to both Android and iOS.

Denna rapport är skapad av tio studenter vid Linköpings universitet vårterminen år2023. Rapporten är en del av kursen TDDD96 — Kandidatprojekt i programvaruutveckling. Rapporten tar upp och behandlar metod och resultat av projektet som utfördes. Den tarockså upp erfarenheter som gruppmedlemmar fått genom projektets gång. Syftet med projektet var att utveckla en applikation till företaget Arboair, vilket är ett företag som står föratt skapa en friskare skog. Resultatet blev en applikation, som är en början till ett verktyg för skogsägare att analysera träd med hjälp av bilder från en drönare. Den viktigasteerfarenheten som gruppen tog med sig var att arbeta i ett mjukvaruprojekt där arbetsplaneringen stod i högt fokus.

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.

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.

This master thesis focuses on proces of UI/UX designing and implementation of mobile application for operation systems Android and iOS. Application is developed using multiplatform mobile framework React Native and programming language JavaScript. Automatization of testing and publishing in App Store and Google Play is also subject of this thesis. Application serves as guide for visitors of theathre festival Encounter/Setkání organised by students of Janáček Academy of Music and Performing Arts.

The development of apps in a cross-platform framework is something that has been appearing more over the latest years. But the knowledge of knowing which of the two popular frameworks, React Native, and Flutter are most efficient when it comes to resource management and general comparisons are less known. This is what this thesis investigates. To find out the comparisons between React Native and Flutter we created two similar apps and document the process of creating an app with the selected frameworks. To get data on the differences when developing an app with these frameworks, we made a survey to get more experienced developers' input. We then did performance tests of the apps to be able to compare the results of the respective framework. The applications we built had several similar functionalities that we used to measure the performance. We also touched on the subject of comparison between a cross-platform framework and a native framework. To do this we performed a literature review on related work to conclude the approaches. From our result, we could conclude that the performance of the Flutter app had a slight advantage over the React Native app. But the difference was not that remarkable, and the overall development was fairly similar. There were some differences to the approaches of development when it came to less experienced developers compared to more experienced developers which we learn from our survey. More experienced developers tended to use external debugging tools, while less experienced used built-in tools such as console commands. Finally, we want to conclude that both Flutter and React Native has their pros and cons. Both frameworks have a big community which is growing everyday, but we believe that Flutter might overtake the popularity from React Native due to its slight performance superiority.From our literature review we can conclude that both approaches has their advantages and it depends a lot on the concept of the app. When developing a more complex app, the native approach is superior. When developing smaller apps with shorter life periods, cross-platform will faster get the app on the market.

Facebook is today the biggest ads platform in the world. This makes it strategi- cally smart for companies to run their ads on the platform. To follow up the result from these ads is an important part for the companies to know if the target audience is the right one. The purpose with this thesis was to investigate if it’s possible for the company Leeroy to develope their own system that follow up ad conversion for Facebook ads. But also investigate how to implement Facebook’s own system and if other systems could be used. From this two purposes a number of goals have been set, which all could be answered. A pilot study resulted in the gathering of information if an own solution could be implemented. The result of this pilot study results in the answer no, an own solution could not be implemented at this state. Through the pilot study a recommended solution could be presented where Facebook’s system is the recommended way to go. This result is based on a system comparison between Facebook and Google Firebase. This recommended solution has resulted in a implementation guide that Leeroy can use to implement Facebook SDK in their application portfolio based on React Native. / Facebook är idag världens största annonsplattform vilket gör det strategiskt smart för företag att annonsera sin produkt eller sina tjänster på plattformen. Att följa upp resultatet av dessa annonser är för företagen en viktig parameter för att veta om den annonserade målgruppen är rätt. Syftet med detta arbete var att undersöka om ett eget system för mobilapplikationer hos företaget Leeroy kan utvecklas för uppföljning av annonskonverteringar hos Facebook-annonser och hur Facebooks egna system implementeras och om andra system går att använda. Utifrån detta syfte kunde ett antal mål fastställas som alla kunde besvaras. Utifrån en förstudie kunde information insamlas om hurvida en egen lösning går att tillämpa. Vilket resulterat i svaret nej, det är idag inte möjligt att utveckla en egen lösning. Genom förstudiens resultat kan en rekommenderad lösning presenteras där Facebooks system rekommenderas utifrån en jämförelse mellan Facebook och Google Firebase. Denna rekommenderade lösning har resulterat i en implementationsguide som Leeroy kan använda för att implementera Facebook SDK i sin applikationsportfölj baserat på React Native.

Tillgängligheten och användandet av grupprum vid universitet är viktigt för studenter då majoriteten av studenternas studietid är på egen hand. Grupprum erbjuder en plats för diskussion och studier, vilket är viktigt för att uppnå en god studiemiljö. Vid Mittuniversitetet existerar det en webbaserad bokningstjänst för studenter att boka grupprum. I det aktuella bokningssystemet existerar det heller ingen direktkoppling till bokningstjänsten och det finns inget sätt att verifiera att bokningen faktiskt används. Därför har denna studie syftat till att undersöka och utveckla en mobilapplikation för bokandet av grupprum vid Mittuniversitetet. Det presenteras nya funktionaliteter och användargränssnitt för att lösa nuvarande problem. Studien har blivit utförd med hjälp av relaterande arbeten, diskussioner med Mittuniversitetets IT-arkitekter, enkätundersökningar och user stories för att bilda en kravfångst. Därefter skapades en prototyp baserat på kravfångsten, denna prototyp användes som designplan för utvecklingen av mobilapplikationen. Sju deltagare deltog att testa applikationen, där första användartestet var att testa en uppsättning funktionaliteter. Därefter utvärderades applikationen för vidareutvecklingen. I det andra testet genfördes en tidmätning mellan det befintliga bokningssystemet och nya bokningssystemet, detta för att genomföra ett antal funktionalitetstester. Resultatet var att det mobila gränssnittet var snabbare för att utföra testerna vid jämförelse med det aktuella webbgränssnittet. Deltagarna ville också ha möjligheten att använda en mobilapplikation i framtiden för att boka grupprum. / The availability and usage of study spaces in universities is important for students due to that majority of their study time is on their own. Study spaces provides a place for discussions and studies, which is important to achieve a good study environment. At the Mid Sweden University, a web-based booking service is available for students to reserve study rooms. In the current booking system, there exist no direct link to the booking service and there is no way to verify that a reservation that has been made is being used. Therefore, the objective of this study has been to examine and develop a mobile application for booking study rooms at Mid Sweden University that presents new functionalities and user interfaces to solve these problems. The study has been conducted with the aid of previous works, discussions with the IT architects, student surveys and user stories to capture requirement specifications. Thereafter a prototype was made based of said requirements, this prototype was then used as a blueprint when developing the actual mobile application. For testing the application, seven participants were chosen to test a set of functionalities and thereafter evaluate their experiences for further development. After the first test, a second test was done by comparing the time it took for participants to perform a set of tasks using the mobile interface versus the existing booking interface. The mobile interface was faster to perform tasks on and participants would like to use a mobile application for future reservations.

In the world of mobile applications, there is no lack of frameworks and languages to use for development. One of the most used frameworks is React Native, which builds on React for web browsers. The React Native framework allows the developer to write the application in JavaScript, and run the application on iOS or Android devices. As the market for mobile applications expands, the time it takes to develop an application is under pressure, and a framework allowing for one codebase for two applications can save time and money. Deedster is a company that provides a mobile application where the user can learn about climate change and perform small tasks, deeds, that give a positive impact on the environment. A common request from the users is the automatization of completion of deeds. This thesis creates two implementations of a QR-code scanning application for completion of deeds, one with Swift and one with React Native, and compares the experiences during development and the results of the implementation. The evaluation uses both a quantitative and a qualitative analysis. The produced application fulfilled most of the requirements, including the scanning of a QR-code to open the application, an authentication process and the completion of a deed with confirmation for the user. The execution times for the two implementations did not differ largely, but the measurements of the application launch time proved flawed in design due to the difference in measurement technique between the two implementations. When it came to the development process, the React Native framework provided major difficulties with configuration and dependencies, resulting in difficulties when locating the source of errors. The launching process for the Swift application required some manual configurations that proved difficult such as creating certificates, while the React Native implementation used Expo to convert the project to a launchable file format which created all required files for the developer. While the usage of Expo was smooth once it worked, build errors and lacking bridges appeared which proved hard to solve. In conclusion, while the process for React Native was smooth once all dependencies were figured out, the time it took to get all configurations in place consumed a large chunk of the project’s time budget while the Swift implementation provided steady progress with few unexpected errors. / För applikationsutveckling för mobiler finns det en uppsjö av språk och ramverk för att underlätta utvecklingsprocessen. Ett av de vanligaste ramverken är React Native som bygger på React för webbläsare. React Native-ramverket låter utvecklare skriva koden i JavaScript, men köra applikationen på både iOS- och Android-enheter. I takt med att marknaden för mobilapplikationer växer, sätts det högre press på kortare utvecklingsfaser och snabbare lansering. För att underlätta processen och spara tid och pengar kan React Native vara en bra lösning. Deedster är ett företag som erbjuder en mobilapplikation där användaren kan lära sig om klimatförändringar och utföra små uppdrag, deeds, som ger en positiv påverkan på klimatet. En vanlig förfrågan från användare är ett sätt att automatisera avklarandet av deeds. Den här uppsatsen skapar två implementationer av en applikation som scannar en QR-kod för att markera en deed som avklarad. Den ena byggs med Swift och den andra med React Native och syftar till att jämföra utvecklingsprocessen och den resulterande applikationen. Evalueringen sker med både en kvalitativ och en kvantitativ analys. Den färdiga applikationen uppfyllde de flesta kraven som Deedster ställt, inklusive att appen öppnas genom att scanna en QR-kod, en användare kan autentisera sig, klicka för att markera en deed som klar och få bekräftelse från appen om att det är klart. Exekveringstiderna för de två implementationerna varierade inte märkbart, men mätningarna för starttiden för applikationerna visade sig bristfällig då mättekniken för de två apparna inte blev jämförbar. Gällande utvecklingsprocessen resulterade användandet av React Native i stora problem med konfigurationer och versionskompatibilitet vilket gjorde felsökning svårt. Lanseringsprocessen för Swift-appen krävde en del manuell konfigurering med till exempel certifikat, medan React Native implementationen använde Expo för att konvertera React Native-projektet till ett lanserbart filformat som skapade alla behövda filer åt användaren. Trots att Expo för pakethantering var enkelt och smidigt när det väl fungerade så krävde alla fel vid kompilering och avsaknad av bryggor mycket tid och var svårt att lösa. Slutsatsen blev att React Native var smidigt när alla konfigurationer var på plats, men den tid det tog att konfigurera allt stod för merparten av den tid som lagts på att bygga applikationen. För Swift var processen istället smidig om än inte lika automatiserad, och bjöd på få om ens några oväntade fel.