Citation
Comparing Performance Between Native iOS (Swift) and React-Native

Material Information

Title:
Comparing Performance Between Native iOS (Swift) and React-Native
Creator:
Calderaio, John Anthony
Publication Date:
Language:
English
Physical Description:
Undergraduate Honors Thesis

Subjects

Subjects / Keywords:
Apples ( jstor )
Business ( jstor )
Computer memory ( jstor )
Email ( jstor )
Maps ( jstor )
Marketing ( jstor )
Mobile applications ( jstor )
Musical performance ( jstor )
Social media ( jstor )
Software applications ( jstor )
Genre:
Undergraduate Honors Thesis

Notes

Abstract:
Only 8 years ago, consumers were spending about 1/10 of their daily Internet usage through a mobile device. Today, that number has increased to more than 50%. As a consequence, in order to stay relevant and reach their intended audiences, most businesses need mobile apps to thrive. However, there is the question of what mobile platform to choose - iOS or Android? Each has their benefits. Or, you could have a hybrid app made (an app made in JavaScript/HTML). The benefits of hybrid apps are that most web developers probably already know JavaScript, the apps are cheaper and faster to produce, and one codebase can be deployed to both Android and iOS. However, hybrid apps tend to perform slower. If that problem were fixed, however, hybrid would be preferred in most situations. React-Native is a new hybrid mobile framework by Facebook that promises Native performance while maintaining the other benefits of hybrid mobile apps. My goal is to find out if they can deliver on what they promised. To achieve this, I must test how two similar apps (one in iOS and one in React-Native) perform against each other. First, I programmed the same mobile app in both iOS (using Swift) and React-Native. Then, I used Apple Instruments to test the performance of the two apps in three categories: CPU, GPU, and Memory. Swift won the CPU category, React-Native won the GPU category, and React- Native won the Memory category by a large amount. Overall, React-Native outperformed native iOS (Swift). React-Native is the framework that Native developers have always feared – I believe it will come to largely replace native in the near future.
General Note:
Awarded Bachelor of Science in Computer Science; Graduated December 20, 2016. Major: Computer Science.
General Note:
College of Engineering
General Note:
Advisor: Abdelsalam "Sumi" Helal, Mobile and Pervasive Computing Laboratory

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright John Anthony Calderaio. Permission granted to University of Florida to digitize and display this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

Form online: http://digital.uflib.ufl.edu/procedures/copyright/GrantofPermissions.doc GRANT OF PERMISSIONS In reference to the following title(s): [John A. Calderaio]. [Comparing Performance Between Native iOS (Swift) and React native]. [Gainesville, FL ] : [ University of Florida ] [ 12/11/2016 ] I, ______ John Calderaio _______, as copyright holder or licensee with the authority to grant copyright permissions for the aforementioned title(s), hereby authorize the University of Florida, acting on behalf of the Board of Trustees of the University of Florida, to digitize, distribute, and archive th e title(s) for nonprofit, educational purposes via the Internet or successive technologies. This is a nonexclusive grant of permissions for on line and offline use for an indefinite term. Offline uses shall be consistent either, for educational uses, with the terms of U.S. copyright legislation's "fair use" provisions or, by the University of Florida, with the maintenance and preservation of an archival copy. Digitization allows the University of Florida to generate image and text based versions as appropriate and to provide and enhance access using search software. This grant of permissions prohibits use of the digitized versions for commercial use or profit. ______________________________________ Signature of Copyright Holder __________John Caldera io____ ____________ Printed or Typed Name of Copyright Holder _______________ Date of Signature Attention : Digital Services / Digital Library Center Smathers Libraries University of Florida P.O. Box 11700 3 Gainesville, FL32611 7003 P: 352.273.2900 DLC@uflib.ufl.edu



PAGE 1

Comparing Performance Between Native iOS (Swift) and React Native by John Anthony Calderaio Mentor: Dr. Sumi Helal A Senior Honors Thesis Submitted to the Faculty of The University of Florida In Partial Fulfillment of the Requirements for the Honors Degree in Bachelor of Science In Computer Science Engineering December 2016 Copyright 2016 All Rights Reserved

PAGE 2

ii ABSTRACT Only 8 years ago consumers were spending about 1/10 of their daily Internet usage through a mobile device Today that number has increased to more than 50%. As a consequence in order to stay relevant and reach their intended audiences, most businesses need mobile apps to thrive. However, there is the question of what mobile platform to choose iOS or Android? Each has their be nefit s Or, you could have a hybrid app made (an app made in JavaScript/HTML). The benefits of hybrid apps are that most web developers probably already know JavaScript, the apps are cheaper and faster to produce, and one codebase can be deployed to both A ndroid and iOS However, hybrid apps tend to perform slower I f that problem were fixed, however, hybrid would be preferred in most situations. React Native is a new hybrid mobile framework by Facebook that promises Native performance while maintaining th e other benefits of hybrid mobile apps. My goal is to find out if they can deliver on what they promised. To achieve this, I must test how two similar apps (one in iOS and one in React Native) perform against each other. First, I programmed the same mobile app in both iOS (using Swift) and React Native. Then, I used Apple Instruments to test the performance of the two apps in three categories: CPU, GPU, and Memory. Swift won the CPU category, React Native won the GPU category, and React Native won the Memory category by a large amount. Over all, React Native outperformed n ative iOS (Swift). React Native is the framework that Native developers have always feared I believe i t will come to largely replace n ative in the near future

PAGE 3

iii TABLE OF CONTENTS ABSTRACT ii INTRODUCTION 1 THE MOBILE TREND 2 BUSINESSES NEED MOBILE APPS 4 ANDROID VS APPLE FOR BUSINESS? 5 ENTER HYBRID MOBILE APPS 6 ENTER REACT NATIVE 8 THE APPLICATION 9 THE SWIFT PROCESS 9 THE REACT NATIVE PROCESS 13 THE DATA 16 CPU MEASUREMENTS 16 GPU MEASUREMENTS 18 MEMORY MEASUREMENTS 20 CONCLUSION 22 REFERENCES 2 3 BIBLIOGRAPHY 24

PAGE 4

INTRODUCTION This document will serve as John Calderaio's Honors Thesis at the University of Florida and will reflect upon the process and result of his research project within the Computer Science Engineering program This document will attempt to identify exactly why it is important to dedicate research to this subject, what I did to produce measuremen ts, and to provide an assessment of the success of the projec t. It is a fact that much of the Internet is now accessed from mobile phones. In order for a business to be competitive in this day in age, it must have it's own app for clients to buy pro ducts, get company news, or perform other tasks However, it is not cheap to have an application made. Mobile application developers are some of the most highly paid software engineers there are, making anywhere from $60,000 to $120,000 per year. Then ther e is the decision of whether to code an i OS or an Android app first. I f funds are limited there is the decision of whether to make the app in for only one platform Another option is to have a hybrid mobile application made. A hybrid mobile application is one that has a code base that can be used to run it on either iOS or Android. React Native is the newest and fastest hybrid mobile framework on the scene. In my project, I am going to code a simple mobile application in Swift and an identical one in Rea ct Native. I will describe my experiences learning both native iOS and coding the native app in Swift, then learning React Native and coding the hybrid app in JavaScript. After both apps are finished I will use Apple Instruments to compare the CPU, GPU, a nd Memory usages of the Swift app to the React Native app to see which app performs better.

PAGE 5

2 THE MOBILE TREND In 2008, consumers spent only 12% of their total daily time on the Internet connected through their mobile devices. In 2015, that number sig nific antly climbed to reach 51%. Figure 1. The increase of mobile connectivity The implications of this are clear if you cannot reach your intended market through mobile web or provide them with a sufficiently sophisticated mobile experience, you are going to miss out on a piece of the pie.

PAGE 6

3 Another key figure has to do with the a mount of time a user spend s in apps versus browsers on their phones A statistic from Flurry Analytics shows that app usage completely dominates web usage at a whopping 90% of the time. Figure 2. Amount of time spent in apps versus browsers on mobile ph ones This figure is enlightening to companies as they decide whether to have a mobile app developed or just a mobile responsive website. This figure may seem staggering now but it shows absolutely no signs of stopping. In 2015, the average mobile app usage across 10 categories showed a 58% increase. The only sign of negative growth is in the category of "games" ( "M obile Marketing Statistics 2016 ).

PAGE 7

4 Figure 3. App usage increase across 10 categories (average is 58%). BUSINESSES NEED MOBILE APPS Hav ing an app is no longer reserved for "hip" and "tech savvy" businesses it is vita l to stay afloat in the industry. One reason for this recent shift in paradigm is that mobile apps imbue a strong "call to action" to persuade the user to purchase a product or service from businesses Another reason is that an app can make the difference between closing the sale or losing the client to a competitor by having the ability to showcase data or portfolio pieces, and sometimes eliminating the need for meeting the client altogether.

PAGE 8

5 Mobile sales reached $74 billion in 2015 an increase of 32% from 2014 Millennial s now conduct 30% of all online purchases through a smartphone, a huge opportunity missed for companies that opt out of building an app. Over the next 5 years, non game app downloads are estimated to grow 23% and mobile sales to $182 billion. It is now more imperative than ever to have an app developed for your business ( "2016 Is the Year Small Busi nesses Must Develop Mobile Apps ). ANDROID VS APPLE FOR BUSINESS? Having an app developed can cost anywhere between $50,000 to $1,000,000, depending on how complex the app is and how polished you want it. It really comes down to the specific feature set of the app. If there is not a server or any APIs involved in the apps development, the previously mentioned costs may be cut in half ( Yarmosh, Ken ). Then there is the question of whether to develop for iOS first then Android later, Android first then iOS later, or build both simultaneously. There are m any pros and cons of each platform: Device Fragmentation iOS is closed platform. This gives Apple complete control over their devices, software, and how the software is released. It also makes it so that there are fewer variables to wor ry about when deve loping an app for its platform. Android, on the other hand, comes in many devices in many differen t resolutions and screen sizes, making it sometimes nightmarish to develop for.

PAGE 9

6 App Store Visibility An app released for iOS can only be seen on the Apple App Store. However an app released for Android can be downloaded from a number of different stores such as Google Play, the Amazon App Store, or any number of independent app stores. This can be a good or b ad thing. It i s good because the app can be seen from a number of different stores, but bad because there can be inconsistency between the stores reviews of the app, the number one thing customers look at before downloading. App Revenue If you are looking to make money directly from the app either bec ause it costs money or from in app purchase s, you are much better off choosing iOS. Because iOS devices cost more money, an owner of an iOS device is more likely to spend money on the Apple App Store. However, if your app is free and you are going for bran d presence and marketing, Android may be a better choice since Android devices are owned by about 80% of the global mobile phone market ( Simon, Jonathan ). ENTER HYBRID MOBILE APPS Let's get some terminology out of the way. A native application is a smartphone application developed specifically for a mobile operating system (Objective C or Swift for iOS and Java for Android). A native application just "feels right" and has faster performance since it is developed within a mature ecosystem followi ng the user experience guidelines o f the O perating S ystem What I mean by "feels right" is that the app has a look and feel consistent with the other apps built in to the OS (Weather,

PAGE 10

7 Calendar, M essaging, etc. ). Finally, a native app has the advantage of h aving access to the hardware capabilities of the device, such as the camera, GPS, etc Instead of needing to choose Android over iOS or vice versa, another option is to go hybrid. Hybrid mobile applications are apps that have the advantage of being writte n in one code base and released for multiple platforms. M any hybrid frameworks are bu ilt using HTML and JavaScript so if a company already has a front end Web Developer there is no need to hire a mobile application developer as well More advantages are that hybrid apps are cheaper and faster to produce. Finally, with a hybrid application the user does not need to update the app in the app store. There are ways for developers to push updates directly to users so that they do not have t o worry about downloading updates. In contrast, for native applications the user needs to update the app from the app store. Figure 4. Native vs Hybrid App Quick Wins

PAGE 11

8 However, Hybrid Mobile apps aren't without their downfalls, and they are drast ic Mo st hybrid mobile apps are basically a Web App wrapped in a native container, which loads most of the content on the page as the user navigates throughout the app. Conversely, Native Apps download most of the content on th e phone when they are installed Th is causes most Hybrid Apps to lag and run frustratingly slow ( Abed, Robbie ). I have personally written two apps using the Apache Cordova hybrid platform. It was incredibly easy to use and I could code an app in a few days, which would take weeks in the nat ive environment. Howeve r, the resulting apps lagged and were slow. Ultimately, it caused me to lose interest in coding hybrid mobile apps. Users are extremely picky about their apps nowadays They expect a great experience from the get go and will usually NOT give an app a second chance. User experience is the key to an application's success. How, then, can you provide a user a great experience using hybrid mobile technology if they perform s lowly? ENTER REACT NATIVE React Native is a hybrid mobile framework that lets you build apps using only JavaScript. However, unlike other hybrid mobile technologies you a re not building a "mobile Web App" (Web App wrapped in a native container). In the end, you get the real thing. Your JavaScript codebase is compiled to a mobile app indistinguishable from an iOS app built using Objective C or an Android app using Java. ( "React Native | A Framework for B uilding Native Apps Using React ). This means that R eact Native

PAGE 12

9 provides the benefits from both Native and Hybrid Mobile A pps, without any of the drawbacks. THE APPLICATION I will need to build an app in both Swift and React Native simple enough so that I can learn both languages and complete the apps in time, but complex enough so that it allows me to compare the CPU, GPU, Memory Usage, and Power Usage of each app. The app will have four tabs. The first one will be n amed "Profile" and will prompt the user to login to F acebook in order to retrieve the use r's profile photo, name, and email and display them on the page. The second tab will be called "To Do List" and will be a simple to do list using NSUserDefaults (iPhone internal memory). It will have "add item and "delete item" functions. The third tab wil l be named "Page Viewer" and will consist of a Page View Controller. The Page View Controller will have three scre ens that the user can swipe through ( "Green", "Red", and "Blue" screen s). The final tab will be named "Maps" and will consist of a Map View th at zooms in to the user's current location, with a blue dot on the map representing the user's location. THE SWIFT PROCESS First up was iOS and Swift. Learning Swift was relatively easy, as it is similar to many languages I already know (Java, C++) Lea rning Cocoa Touch (the iOS framework), h owever, was a much harder task. I watched Rob Percival's video series on

PAGE 13

10 Udemy .com which ran me from the introduction of Swift through the completion of several apps. Even after the introductory videos, I was still having trouble understanding Cocoa Touch. Much of the "learning" in these videos involved copy/pasting code but we weren't quite sure what it did. I got the feeling even the teacher did not know and just memorized it. I do not like not knowing what every l ine of my code does. Apple's IDE (Xcode) is without a doubt very advanced and user f riendly. You can click on what is called a Storyboard and set up the app screens in the order you want, putting an arrow on the screen where the app is to begin. In the first tab ("Profile") I was able to drag the image view, name label, and email label where I wanted Then, I dragged it to the code and made a connection creating a new variable in the code in the process. Then, programmatically, once the user logged in t hrough Facebook, I would set these variable names with their corresponding Facebook values It took 3 weeks to make it through the video series and get c omfortable coding in Swift/iOS. You can view my code for the Swift version of this app at GitHub at t his link : https://github.com/jcalderaio/swift honors app

PAGE 14

11 Figure 5. Swift Tab 1 (Facebook Login) Figure 6 Swift Tab 2 (To Do List)

PAGE 15

12 Figure 7. Swift Tab 3 (Page View) Figure 8. Swift Tab 4 (Maps)

PAGE 16

13 THE REACT NATIVE PROCESS Second up was React Native. Learning JavaScript was a bit harder than Swift but still not difficult I tried coding the app from bits and pieces of React Native I had learnt off of the Internet but it wasn't enough. I needed some video lectures. Returning to Udemy .com I watched Stephen Grider 's spectacular introduction to React Native. At first I was incredibly overwhelmed. React Native's structure made no sense to me whatsoever, but after only a week of watching Stephen's lectures I was able to start coding on my own. What I really like about React Native is that, unlike iOS, every line of code you write makes sense you know what each line of code does. In addition, unlike in iOS (where you had to tweak settings for each page to look good in landscape and portrait for different screen sizes), in React Native all the tweaking is done for you. Witho ut any setup whatsoever, I was using the app I made in landscape and it looked perfectly fine. I ran the app in a number of different iPhone sizes and they looked fine there too. Because React Native uses flexbox (similar to CSS for HTML) it is responsive to the size of the screen the app is being displayed on. You can view my code for the React Native version of this app at GitHub at this link: https://github.com/jcalderaio/react nativ e honors app

PAGE 17

14 Figure 9. React Native Tab 1 (Facebook Login) Figure 10. React Native Tab 2 (To Do List)

PAGE 18

15 Figure 11 React Native Tab 3 (Page View) Figure 12 React Native Tab 4 (Maps)

PAGE 19

16 THE DATA Now comes the time to pit the apps against eachother to see which one performs better I will be using Apple Instruments (a tool packaged within Xcode Apple's IDE ) to test the two apps across three main categories: CPU ("Time Profiler Tool"), GPU ("Core A nimation T ool ) and Memory Usage ("Allocations T ool ) Apple Instruments allows me to plug my phone in, pick an y running app on my phone pick the measurement tool I wa nt to use, then begin recording (M, Igor). There are 4 tabs in each app and each tab has a task which I will be performing to measure in each category. The first ("Profile ) tab's function will be to login through Facebook. In the code is a graph request for profile picture, email, and name to be returned to the app from Facebook's serve r. The second ("To Do List") app's task will be to add and dele te a "to do item" from the list The third ("Page View") tab's task is to swipe through 3 P age V iew screens. The fourth ("Map s ") tab's task is to just click on the tab, and the code will cause the GPS to zoom in on the map to my current location and put a blue, radiating blip on me CPU MEASUREMENTS The first data set we will graph are the CPU measurements. I wil l perform one task per tab, for each Swift and React Native and write down the measurements. m I will take the average and plot it in the following chart.

PAGE 20

17 Figure 13 Swift vs React Native CPU Usage Let's go over each category: Profile : React Native wins this tab slightly with 1.86% more efficient use of CPU. While performing the task and recording the measurements, a spike in CPU usage was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native also barely wins this tab with 1.53% more efficient use of CPU. While performing the task and re cording the measurements, spikes in CPU usage were observed at the exact moment I added an item to the "list" and when I deleted it. Page View: This time, Swift beat out React Native with 8.82% more efficient use of CPU. While performing the task and recording the measurements, spikes in CPU usage were observed at the exact moment I swiped to a different page in the page view. Once I stayed on a page, the CPU usage decreased, but if I swiped the page again the CPU usage increased. Profile To Do List Page View Maps Swift 28.38 45.73 17 42.34 R-N 26.52 44.2 24.29 56.02 0 50 100 150 200 % Memory (100% per Core) CPU Usage

PAGE 21

18 Maps: Swift wins this category again with 13.68% more efficient use of CPU. While performing the task and recording the measurements, a spike in CPU usage was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my current location and highlight it with a blue, pulsating dot. Yes, Swift won two tabs and React Native won two tabs but overall Swift used the CPU 17.58% more efficiently The results may have been different if I allowed myself more time in each app instead of just focusing on the one task and stopping. I did notice that CPU was not used at all when changing from tab to tab, however. GPU MEASUREMENTS The second data se t we will graph are the G PU measurements. I will perform one task per tab, for each Swift and React Native and write down the measurements. The Y axis goes up to 60 frames/second Each second over the course of time I am performing the tab's task a measu rement will be recorded by the "Core Animation" tool. I will take the average of these and plot it in the following chart.

PAGE 22

19 Figure 14 Swift vs React Native G PU Usage Let's go over each category: Profile : Swift wins this tab slightly by running at 1 .7 frames/second higher than React Native While performing the task and recording the measurements, a spike in frames/second was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native wins this category by running at 6.25 frames/second higher than Swift While performing the task and recordi ng the measurements, a spike in frames/s was observed at the exact moment I added an item to the "list" and when I deleted it. Page View: Swift beat React Native in this tab by running at 3.6 frames/second higher While performing the task a nd recording the measurements, I observed that the Profile To Do List Page View Maps Swift 44 30.75 28.6 33 R-N 42.3 37 25 36 0 10 20 30 40 50 60 Framers per second GPU Usage

PAGE 23

20 frames/second shot up to the high 50s if I swiped through the pages fast Once I stayed on a page, the frames/s decreased, but if I s wiped the page again the frames shot up again. Maps: React Native wins this category because it runs 3 frames/s higher than Swift While performing the task and recording the measurements, a spike in frames/s was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my current location and highlight it with a blue, pulsating dot. Once again Swift wins two tabs and React Native wins two tabs However, React Native wins thi s category overall by .95 frames/s It is amazing how much juice Facebook was able to squeeze out of React Native's code so far it seems as if it is holding up against n ative iOS (Swift) MEMORY MEASUREMENTS The third data set we will graph are the Memory measurements. I will perform one task per tab, for each Swift and React Native and write down the measurements. The Y axis (Memory) will go as high as my highest measurement. My sample interval for CPU usage is 1 ms. Each ms, while I am performing t he task, a measurement will be recorded by the Allocations tool. I will take the average and plot it in the following chart.

PAGE 24

21 Figure 15 Swift vs React Native Memory Usage Let's go over each category: Profile : Swift wins this tab slightly by using 0.02 MiB less memory While performing the task and recording the measurements, a spike in Memory usage was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native wins this tab by using 0.83 MiB less memory than its Swift counterpart While performing the task a nd recording the measurements, spikes in Memory usage were observed at the exact moment I added an item to the "list" and the memory usage decreased when I deleted an item from the list. Page View: In this tab React Native beat out Swift by using 0.04 MiB less memor y While performing the task and recording the measurements, I noticed NO memory spikes when switching between pages in Page View Literally nothing changed. Profile To Do List Page View Maps Swift 2.09 4.74 0.72 118 R-N 2.11 3.91 0.68 56.89 0 20 40 60 80 100 120 MiB of Memory Memory Usage

PAGE 25

22 Maps: React Native wins this catego ry by a huge margin by using a whopping 6 1.11 MiB less memory than Swift While performing the task and recording the measurements, a spike in Memory usage was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my cur rent location and highlight it with a blue, pulsating dot. In both apps, t he memory kept increasing over the course of the task but eventually reached stasis. React Na tive won three tabs and Swift won one. Overall, React Native used 61.96 MiB less memory and won the Memory category The results may have been different if I allowed myself more time in each app instead of just focusing on the one task and stopping. I did notice in the "Maps" tab (in both apps) that when I zoomed out of the map or moved the map around, the memory used increased exponentially "Maps" used by far the most memory in each case. CONCLUSION The mobile applications I made for Swift and React Native are almost identical in their physical appearance As you can see from the data I collected through measuring both of the application's CPU, GPU, and Memory during the tasks in each of the four tabs, the apps are also almost identical in how they perform. Swift won overall in the CPU category, React Native won the GPU category (barely), and React Native won big time in the Memory category. I can infer from this data that Swift uses the CPU of the iPhone more efficiently than React Native, React Native uses the GPU of the iPhone slightly more effectively than Swift, and that React Native somehow leverages the

PAGE 26

23 iPhone's memory much more effectively than Swift does. React Native, winning two out of three categories, comes in first place as the better performing platform. What I did not account for was Native Android. iOS is my preferred plat form of choice, so it is what I cared about most. However, I may soon try the same experiment on Android for completions sake. I would be curious to see what the results are but I would be willing to bet that if React Native can beat out n ative iOS perform ance than it can beat out native Android performance as well. I am now more convinced than ever that React Native is the framework of the future it has so many advantages and so few disadvantages. React Native can be written in Javascript (a language s o many developers already know), its codebase can be deployed to both iOS and Android platforms, it is faster and cheaper to produce apps, and developers can push update s directly to users so that users do not have to worry about downloading updates. Best of all, at only a year o ld React Native is already outperforming n ative iOS Swift applications. REFERENCES "2016 Is the Year Small Businesses Must Develop Mobile Apps." Small Business Trends 29 July 2016, smallbiztrends.com/2016/03/2016 year small bu sinesses must develop mobile apps.html#comments. Accessed 4 Dec 2016. Abed, Robbie. "Hybrid vs Native Mobile Apps The Answer Is Clear." Y Media Labs 10 Nov. 2016, www.ymedialabs.com/hybrid vs native mobile apps the answer is clear/. Accessed 5 December 2016.

PAGE 27

medium.com/@mandrigin/ios app performance instruments beyond 48fe7b7cdf2#.6knqxp1gd. Acces sed 4 Dec 2016. www.smartinsights.com/mobile marketing/mobile marketing analytics/mobile marketing statistics/. Accessed 4 Dec 2016. facebook.github.io/react native/releases/next/. Accessed 5 Dec 2016. develope rs.magmic.com/developing on ios vs android there is one clear winner/. Accessed 4 Dec 2016. much does a pp cost massive review pricing budget considerations/. Accessed 4 Dec 2016. 24



PAGE 1

Honors Thesis Submission Form Name: John Calderaio UFID: 3303 6479 Additional Authors: Email: jcalderaio@ufl.edu Major: CSE Advisor Name: Dr. Sumi Helal Advisor Email: helal@cise.ufl.edu Advisor Department: CISE Thesis Title: Comparing Performance Between Native iOS (Swift) and React Native Abstract (200 words max): In order to thrive as a business, it is obvious in today's culture that every company needs a mobile app. However, should you choose iOS or Android? Each has their benefits. Or, you could choose a hybrid mobile application. The benefits of hybrid apps are that most web developers already know JavaScript, they are cheaper and faster to produce, and one codebase can be d eployed to both Android and iOS. However, hybrid apps tend to perform slower. If that problem were fixed, hybrid would be preferred in most situations. React Native is a new hybrid framework that promises native performance while maintaining other benefit s of hybrid mobile apps. My goal is to find out if they can deliver on what they promised. To achieve this, I programmed the same mobile app in both iOS (using Swift) and React Native. Then, I used Apple Instruments to test the performance of the two apps in three categories: CPU, GPU, and Memory. Swift won the CPU category, React Native won the GPU category, and React Native won the Memory category. Overall, React Native outperformed native iOS (Swift). React Native is the framework that Native developer s have always feared I believe it will lar gely replace native in the near future. (For Office Use Only) Major: _________________ Designation: ____________

PAGE 2

Student Signature/Date _________________________________________ Thesis Advisor Signature/Date _________________________________________ Departmental Honors Coordinator Signature _________________________________________ Please indicate your preference for public access to your thesis by initialing the appropriate statement below: ____ I grant permission to the University of Florida to list the title and abstract of this thesis in a publicly accessible database. _____ I do not grant permission to the University of Florida to list the title and abstract of this thesis publicly. If you wish to make the entire thesis publicly available, you must also complete the Internet Distribution Permissions Form, available at http://digital.uflib.ufl.edu/procedures/copyright/GrantofPermissions.doc If you do not include this form, your thesis will be archived but will not be viewable online.



PAGE 1

Comparing Performance Between Native iOS (Swift) and React Native by John Anthony Calderaio Mentor: Dr. Sumi Helal A Senior Honors Thesis Submitted to the Faculty of The University of Florida In Partial Fulfillment of the Requirements for the Honors Degree in Bachelor of Science In Computer Science Engineering December 2016 Copyright 2016 All Rights Reserved

PAGE 2

ii ABSTRACT Only 8 years ago consumers were spending about 1/10 of their daily Internet usage through a mobile device Today that number has increased to more than 50%. As a consequence in order to stay relevant and reach their intended audiences, most businesses need mobile apps to thrive. However, there is the question of what mobile platform to choose iOS or Android? Each has their be nefit s Or, you could have a hybrid app made (an app made in JavaScript/HTML). The benefits of hybrid apps are that most web developers probably already know JavaScript, the apps are cheaper and faster to produce, and one codebase can be deployed to both A ndroid and iOS However, hybrid apps tend to perform slower I f that problem were fixed, however, hybrid would be preferred in most situations. React Native is a new hybrid mobile framework by Facebook that promises Native performance while maintaining th e other benefits of hybrid mobile apps. My goal is to find out if they can deliver on what they promised. To achieve this, I must test how two similar apps (one in iOS and one in React Native) perform against each other. First, I programmed the same mobile app in both iOS (using Swift) and React Native. Then, I used Apple Instruments to test the performance of the two apps in three categories: CPU, GPU, and Memory. Swift won the CPU category, React Native won the GPU category, and React Native won the Memory category by a large amount. Over all, React Native outperformed n ative iOS (Swift). React Native is the framework that Native developers have always feared I believe i t will come to largely replace n ative in the near future

PAGE 3

iii TABLE OF CONTENTS ABSTRACT ii INTRODUCTION 1 THE MOBILE TREND 2 BUSINESSES NEED MOBILE APPS 4 ANDROID VS APPLE FOR BUSINESS? 5 ENTER HYBRID MOBILE APPS 6 ENTER REACT NATIVE 8 THE APPLICATION 9 THE SWIFT PROCESS 9 THE REACT NATIVE PROCESS 13 THE DATA 16 CPU MEASUREMENTS 16 GPU MEASUREMENTS 18 MEMORY MEASUREMENTS 20 CONCLUSION 22 REFERENCES 2 3 BIBLIOGRAPHY 24

PAGE 4

INTRODUCTION This document will serve as John Calderaio's Honors Thesis at the University of Florida and will reflect upon the process and result of his research project within the Computer Science Engineering program This document will attempt to identify exactly why it is important to dedicate research to this subject, what I did to produce measuremen ts, and to provide an assessment of the success of the projec t. It is a fact that much of the Internet is now accessed from mobile phones. In order for a business to be competitive in this day in age, it must have it's own app for clients to buy pro ducts, get company news, or perform other tasks However, it is not cheap to have an application made. Mobile application developers are some of the most highly paid software engineers there are, making anywhere from $60,000 to $120,000 per year. Then ther e is the decision of whether to code an i OS or an Android app first. I f funds are limited there is the decision of whether to make the app in for only one platform Another option is to have a hybrid mobile application made. A hybrid mobile application is one that has a code base that can be used to run it on either iOS or Android. React Native is the newest and fastest hybrid mobile framework on the scene. In my project, I am going to code a simple mobile application in Swift and an identical one in Rea ct Native. I will describe my experiences learning both native iOS and coding the native app in Swift, then learning React Native and coding the hybrid app in JavaScript. After both apps are finished I will use Apple Instruments to compare the CPU, GPU, a nd Memory usages of the Swift app to the React Native app to see which app performs better.

PAGE 5

2 THE MOBILE TREND In 2008, consumers spent only 12% of their total daily time on the Internet connected through their mobile devices. In 2015, that number sig nific antly climbed to reach 51%. Figure 1. The increase of mobile connectivity The implications of this are clear if you cannot reach your intended market through mobile web or provide them with a sufficiently sophisticated mobile experience, you are going to miss out on a piece of the pie.

PAGE 6

3 Another key figure has to do with the a mount of time a user spend s in apps versus browsers on their phones A statistic from Flurry Analytics shows that app usage completely dominates web usage at a whopping 90% of the time. Figure 2. Amount of time spent in apps versus browsers on mobile ph ones This figure is enlightening to companies as they decide whether to have a mobile app developed or just a mobile responsive website. This figure may seem staggering now but it shows absolutely no signs of stopping. In 2015, the average mobile app usage across 10 categories showed a 58% increase. The only sign of negative growth is in the category of "games" ( "M obile Marketing Statistics 2016 ).

PAGE 7

4 Figure 3. App usage increase across 10 categories (average is 58%). BUSINESSES NEED MOBILE APPS Hav ing an app is no longer reserved for "hip" and "tech savvy" businesses it is vita l to stay afloat in the industry. One reason for this recent shift in paradigm is that mobile apps imbue a strong "call to action" to persuade the user to purchase a product or service from businesses Another reason is that an app can make the difference between closing the sale or losing the client to a competitor by having the ability to showcase data or portfolio pieces, and sometimes eliminating the need for meeting the client altogether.

PAGE 8

5 Mobile sales reached $74 billion in 2015 an increase of 32% from 2014 Millennial s now conduct 30% of all online purchases through a smartphone, a huge opportunity missed for companies that opt out of building an app. Over the next 5 years, non game app downloads are estimated to grow 23% and mobile sales to $182 billion. It is now more imperative than ever to have an app developed for your business ( "2016 Is the Year Small Busi nesses Must Develop Mobile Apps ). ANDROID VS APPLE FOR BUSINESS? Having an app developed can cost anywhere between $50,000 to $1,000,000, depending on how complex the app is and how polished you want it. It really comes down to the specific feature set of the app. If there is not a server or any APIs involved in the apps development, the previously mentioned costs may be cut in half ( Yarmosh, Ken ). Then there is the question of whether to develop for iOS first then Android later, Android first then iOS later, or build both simultaneously. There are m any pros and cons of each platform: Device Fragmentation iOS is closed platform. This gives Apple complete control over their devices, software, and how the software is released. It also makes it so that there are fewer variables to wor ry about when deve loping an app for its platform. Android, on the other hand, comes in many devices in many differen t resolutions and screen sizes, making it sometimes nightmarish to develop for.

PAGE 9

6 App Store Visibility An app released for iOS can only be seen on the Apple App Store. However an app released for Android can be downloaded from a number of different stores such as Google Play, the Amazon App Store, or any number of independent app stores. This can be a good or b ad thing. It i s good because the app can be seen from a number of different stores, but bad because there can be inconsistency between the stores reviews of the app, the number one thing customers look at before downloading. App Revenue If you are looking to make money directly from the app either bec ause it costs money or from in app purchase s, you are much better off choosing iOS. Because iOS devices cost more money, an owner of an iOS device is more likely to spend money on the Apple App Store. However, if your app is free and you are going for bran d presence and marketing, Android may be a better choice since Android devices are owned by about 80% of the global mobile phone market ( Simon, Jonathan ). ENTER HYBRID MOBILE APPS Let's get some terminology out of the way. A native application is a smartphone application developed specifically for a mobile operating system (Objective C or Swift for iOS and Java for Android). A native application just "feels right" and has faster performance since it is developed within a mature ecosystem followi ng the user experience guidelines o f the O perating S ystem What I mean by "feels right" is that the app has a look and feel consistent with the other apps built in to the OS (Weather,

PAGE 10

7 Calendar, M essaging, etc. ). Finally, a native app has the advantage of h aving access to the hardware capabilities of the device, such as the camera, GPS, etc Instead of needing to choose Android over iOS or vice versa, another option is to go hybrid. Hybrid mobile applications are apps that have the advantage of being writte n in one code base and released for multiple platforms. M any hybrid frameworks are bu ilt using HTML and JavaScript so if a company already has a front end Web Developer there is no need to hire a mobile application developer as well More advantages are that hybrid apps are cheaper and faster to produce. Finally, with a hybrid application the user does not need to update the app in the app store. There are ways for developers to push updates directly to users so that they do not have t o worry about downloading updates. In contrast, for native applications the user needs to update the app from the app store. Figure 4. Native vs Hybrid App Quick Wins

PAGE 11

8 However, Hybrid Mobile apps aren't without their downfalls, and they are drast ic Mo st hybrid mobile apps are basically a Web App wrapped in a native container, which loads most of the content on the page as the user navigates throughout the app. Conversely, Native Apps download most of the content on th e phone when they are installed Th is causes most Hybrid Apps to lag and run frustratingly slow ( Abed, Robbie ). I have personally written two apps using the Apache Cordova hybrid platform. It was incredibly easy to use and I could code an app in a few days, which would take weeks in the nat ive environment. Howeve r, the resulting apps lagged and were slow. Ultimately, it caused me to lose interest in coding hybrid mobile apps. Users are extremely picky about their apps nowadays They expect a great experience from the get go and will usually NOT give an app a second chance. User experience is the key to an application's success. How, then, can you provide a user a great experience using hybrid mobile technology if they perform s lowly? ENTER REACT NATIVE React Native is a hybrid mobile framework that lets you build apps using only JavaScript. However, unlike other hybrid mobile technologies you a re not building a "mobile Web App" (Web App wrapped in a native container). In the end, you get the real thing. Your JavaScript codebase is compiled to a mobile app indistinguishable from an iOS app built using Objective C or an Android app using Java. ( "React Native | A Framework for B uilding Native Apps Using React ). This means that R eact Native

PAGE 12

9 provides the benefits from both Native and Hybrid Mobile A pps, without any of the drawbacks. THE APPLICATION I will need to build an app in both Swift and React Native simple enough so that I can learn both languages and complete the apps in time, but complex enough so that it allows me to compare the CPU, GPU, Memory Usage, and Power Usage of each app. The app will have four tabs. The first one will be n amed "Profile" and will prompt the user to login to F acebook in order to retrieve the use r's profile photo, name, and email and display them on the page. The second tab will be called "To Do List" and will be a simple to do list using NSUserDefaults (iPhone internal memory). It will have "add item and "delete item" functions. The third tab wil l be named "Page Viewer" and will consist of a Page View Controller. The Page View Controller will have three scre ens that the user can swipe through ( "Green", "Red", and "Blue" screen s). The final tab will be named "Maps" and will consist of a Map View th at zooms in to the user's current location, with a blue dot on the map representing the user's location. THE SWIFT PROCESS First up was iOS and Swift. Learning Swift was relatively easy, as it is similar to many languages I already know (Java, C++) Lea rning Cocoa Touch (the iOS framework), h owever, was a much harder task. I watched Rob Percival's video series on

PAGE 13

10 Udemy .com which ran me from the introduction of Swift through the completion of several apps. Even after the introductory videos, I was still having trouble understanding Cocoa Touch. Much of the "learning" in these videos involved copy/pasting code but we weren't quite sure what it did. I got the feeling even the teacher did not know and just memorized it. I do not like not knowing what every l ine of my code does. Apple's IDE (Xcode) is without a doubt very advanced and user f riendly. You can click on what is called a Storyboard and set up the app screens in the order you want, putting an arrow on the screen where the app is to begin. In the first tab ("Profile") I was able to drag the image view, name label, and email label where I wanted Then, I dragged it to the code and made a connection creating a new variable in the code in the process. Then, programmatically, once the user logged in t hrough Facebook, I would set these variable names with their corresponding Facebook values It took 3 weeks to make it through the video series and get c omfortable coding in Swift/iOS. You can view my code for the Swift version of this app at GitHub at t his link : https://github.com/jcalderaio/swift honors app

PAGE 14

11 Figure 5. Swift Tab 1 (Facebook Login) Figure 6 Swift Tab 2 (To Do List)

PAGE 15

12 Figure 7. Swift Tab 3 (Page View) Figure 8. Swift Tab 4 (Maps)

PAGE 16

13 THE REACT NATIVE PROCESS Second up was React Native. Learning JavaScript was a bit harder than Swift but still not difficult I tried coding the app from bits and pieces of React Native I had learnt off of the Internet but it wasn't enough. I needed some video lectures. Returning to Udemy .com I watched Stephen Grider 's spectacular introduction to React Native. At first I was incredibly overwhelmed. React Native's structure made no sense to me whatsoever, but after only a week of watching Stephen's lectures I was able to start coding on my own. What I really like about React Native is that, unlike iOS, every line of code you write makes sense you know what each line of code does. In addition, unlike in iOS (where you had to tweak settings for each page to look good in landscape and portrait for different screen sizes), in React Native all the tweaking is done for you. Witho ut any setup whatsoever, I was using the app I made in landscape and it looked perfectly fine. I ran the app in a number of different iPhone sizes and they looked fine there too. Because React Native uses flexbox (similar to CSS for HTML) it is responsive to the size of the screen the app is being displayed on. You can view my code for the React Native version of this app at GitHub at this link: https://github.com/jcalderaio/react nativ e honors app

PAGE 17

14 Figure 9. React Native Tab 1 (Facebook Login) Figure 10. React Native Tab 2 (To Do List)

PAGE 18

15 Figure 11 React Native Tab 3 (Page View) Figure 12 React Native Tab 4 (Maps)

PAGE 19

16 THE DATA Now comes the time to pit the apps against eachother to see which one performs better I will be using Apple Instruments (a tool packaged within Xcode Apple's IDE ) to test the two apps across three main categories: CPU ("Time Profiler Tool"), GPU ("Core A nimation T ool ) and Memory Usage ("Allocations T ool ) Apple Instruments allows me to plug my phone in, pick an y running app on my phone pick the measurement tool I wa nt to use, then begin recording (M, Igor). There are 4 tabs in each app and each tab has a task which I will be performing to measure in each category. The first ("Profile ) tab's function will be to login through Facebook. In the code is a graph request for profile picture, email, and name to be returned to the app from Facebook's serve r. The second ("To Do List") app's task will be to add and dele te a "to do item" from the list The third ("Page View") tab's task is to swipe through 3 P age V iew screens. The fourth ("Map s ") tab's task is to just click on the tab, and the code will cause the GPS to zoom in on the map to my current location and put a blue, radiating blip on me CPU MEASUREMENTS The first data set we will graph are the CPU measurements. I wil l perform one task per tab, for each Swift and React Native and write down the measurements. m I will take the average and plot it in the following chart.

PAGE 20

17 Figure 13 Swift vs React Native CPU Usage Let's go over each category: Profile : React Native wins this tab slightly with 1.86% more efficient use of CPU. While performing the task and recording the measurements, a spike in CPU usage was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native also barely wins this tab with 1.53% more efficient use of CPU. While performing the task and re cording the measurements, spikes in CPU usage were observed at the exact moment I added an item to the "list" and when I deleted it. Page View: This time, Swift beat out React Native with 8.82% more efficient use of CPU. While performing the task and recording the measurements, spikes in CPU usage were observed at the exact moment I swiped to a different page in the page view. Once I stayed on a page, the CPU usage decreased, but if I swiped the page again the CPU usage increased. Profile To Do List Page View Maps Swift 28.38 45.73 17 42.34 R-N 26.52 44.2 24.29 56.02 0 50 100 150 200 % Memory (100% per Core) CPU Usage

PAGE 21

18 Maps: Swift wins this category again with 13.68% more efficient use of CPU. While performing the task and recording the measurements, a spike in CPU usage was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my current location and highlight it with a blue, pulsating dot. Yes, Swift won two tabs and React Native won two tabs but overall Swift used the CPU 17.58% more efficiently The results may have been different if I allowed myself more time in each app instead of just focusing on the one task and stopping. I did notice that CPU was not used at all when changing from tab to tab, however. GPU MEASUREMENTS The second data se t we will graph are the G PU measurements. I will perform one task per tab, for each Swift and React Native and write down the measurements. The Y axis goes up to 60 frames/second Each second over the course of time I am performing the tab's task a measu rement will be recorded by the "Core Animation" tool. I will take the average of these and plot it in the following chart.

PAGE 22

19 Figure 14 Swift vs React Native G PU Usage Let's go over each category: Profile : Swift wins this tab slightly by running at 1 .7 frames/second higher than React Native While performing the task and recording the measurements, a spike in frames/second was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native wins this category by running at 6.25 frames/second higher than Swift While performing the task and recordi ng the measurements, a spike in frames/s was observed at the exact moment I added an item to the "list" and when I deleted it. Page View: Swift beat React Native in this tab by running at 3.6 frames/second higher While performing the task a nd recording the measurements, I observed that the Profile To Do List Page View Maps Swift 44 30.75 28.6 33 R-N 42.3 37 25 36 0 10 20 30 40 50 60 Framers per second GPU Usage

PAGE 23

20 frames/second shot up to the high 50s if I swiped through the pages fast Once I stayed on a page, the frames/s decreased, but if I s wiped the page again the frames shot up again. Maps: React Native wins this category because it runs 3 frames/s higher than Swift While performing the task and recording the measurements, a spike in frames/s was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my current location and highlight it with a blue, pulsating dot. Once again Swift wins two tabs and React Native wins two tabs However, React Native wins thi s category overall by .95 frames/s It is amazing how much juice Facebook was able to squeeze out of React Native's code so far it seems as if it is holding up against n ative iOS (Swift) MEMORY MEASUREMENTS The third data set we will graph are the Memory measurements. I will perform one task per tab, for each Swift and React Native and write down the measurements. The Y axis (Memory) will go as high as my highest measurement. My sample interval for CPU usage is 1 ms. Each ms, while I am performing t he task, a measurement will be recorded by the Allocations tool. I will take the average and plot it in the following chart.

PAGE 24

21 Figure 15 Swift vs React Native Memory Usage Let's go over each category: Profile : Swift wins this tab slightly by using 0.02 MiB less memory While performing the task and recording the measurements, a spike in Memory usage was observed at the exact moment I pressed the "Log in with Facebook" button. To Do List: React Native wins this tab by using 0.83 MiB less memory than its Swift counterpart While performing the task a nd recording the measurements, spikes in Memory usage were observed at the exact moment I added an item to the "list" and the memory usage decreased when I deleted an item from the list. Page View: In this tab React Native beat out Swift by using 0.04 MiB less memor y While performing the task and recording the measurements, I noticed NO memory spikes when switching between pages in Page View Literally nothing changed. Profile To Do List Page View Maps Swift 2.09 4.74 0.72 118 R-N 2.11 3.91 0.68 56.89 0 20 40 60 80 100 120 MiB of Memory Memory Usage

PAGE 25

22 Maps: React Native wins this catego ry by a huge margin by using a whopping 6 1.11 MiB less memory than Swift While performing the task and recording the measurements, a spike in Memory usage was observed at the exact moment I pressed the "Maps" tab, which prompted the MapView to find my cur rent location and highlight it with a blue, pulsating dot. In both apps, t he memory kept increasing over the course of the task but eventually reached stasis. React Na tive won three tabs and Swift won one. Overall, React Native used 61.96 MiB less memory and won the Memory category The results may have been different if I allowed myself more time in each app instead of just focusing on the one task and stopping. I did notice in the "Maps" tab (in both apps) that when I zoomed out of the map or moved the map around, the memory used increased exponentially "Maps" used by far the most memory in each case. CONCLUSION The mobile applications I made for Swift and React Native are almost identical in their physical appearance As you can see from the data I collected through measuring both of the application's CPU, GPU, and Memory during the tasks in each of the four tabs, the apps are also almost identical in how they perform. Swift won overall in the CPU category, React Native won the GPU category (barely), and React Native won big time in the Memory category. I can infer from this data that Swift uses the CPU of the iPhone more efficiently than React Native, React Native uses the GPU of the iPhone slightly more effectively than Swift, and that React Native somehow leverages the

PAGE 26

23 iPhone's memory much more effectively than Swift does. React Native, winning two out of three categories, comes in first place as the better performing platform. What I did not account for was Native Android. iOS is my preferred plat form of choice, so it is what I cared about most. However, I may soon try the same experiment on Android for completions sake. I would be curious to see what the results are but I would be willing to bet that if React Native can beat out n ative iOS perform ance than it can beat out native Android performance as well. I am now more convinced than ever that React Native is the framework of the future it has so many advantages and so few disadvantages. React Native can be written in Javascript (a language s o many developers already know), its codebase can be deployed to both iOS and Android platforms, it is faster and cheaper to produce apps, and developers can push update s directly to users so that users do not have to worry about downloading updates. Best of all, at only a year o ld React Native is already outperforming n ative iOS Swift applications. REFERENCES "2016 Is the Year Small Businesses Must Develop Mobile Apps." Small Business Trends 29 July 2016, smallbiztrends.com/2016/03/2016 year small bu sinesses must develop mobile apps.html#comments. Accessed 4 Dec 2016. Abed, Robbie. "Hybrid vs Native Mobile Apps The Answer Is Clear." Y Media Labs 10 Nov. 2016, www.ymedialabs.com/hybrid vs native mobile apps the answer is clear/. Accessed 5 December 2016.

PAGE 27

24 M, Igor. "IOS App Performance: Instruments &Amp; Beyond." Medium 2 Feb. 2016, medium.com/@mandrigin/ios app performance instruments beyond 48fe7b7cdf2#.6knqxp1gd. Accessed 4 Dec 2016. "Mobile Marketing Statistics 2016." Smart In sights 26 Oct. 2016, www.smartinsights.com/mobile marketing/mobile marketing analytics/mobile marketing statistics/. Accessed 4 Dec 2016. "React Native | A Framework for Building Native Apps Using React." React Native facebook.github.io/react native/rele ases/next/. Accessed 5 Dec 2016. Simon, Jonathan. "Developing on IOS vs. Android There Is One Clear Winner." Magmic 1 Dec. 2015, developers.magmic.com/developing on ios vs android there is one clear winner/. Accessed 4 Dec 2016. Yarmosh Ken. "How Much Does an App Cost: A Massive Review of Pricing and Other Budget Considerations." Savvy Apps 4 Feb. 2015, savvyapps.com/blog/how much does app cost massive review pricing budget considerations/. Accessed 4 Dec 2016. BIBLIOGRAPHY John Ant hony Calderaio was born in Boynton Beach, Florida on June 24, 1986 Taking up Tae Kwon Do at a young age, he earned his brown belt at 9 years old. Martial Arts taught him discipline, which would later become his defining quality. John completed his seconda ry education at Jupiter High School, where he also wrestled and lifted weights. John was a talented weight lifter, bench pressing multiple times his own

PAGE 28

25 weight. When John graduated high school, he went on to study Computer and Information Science at the Un iversity of Florida where he earned his baccalaureate with a 3.9 GPA and Summa Cum Laude top honors. Mr. Calderaio started his own contracting company, Online Gainesville, and currently codes iOS and Android apps in React Native for a living. John has a g irlfriend name d Este, who is also an Engineer (industrial). They are moving to Cape Canaveral in May, where she will be working at Lockheed Martin. John enjoys watching movies, playing board games, video games, strumming his guitar, and spending time with his family.