Framework research for Scheduled app

Brthrs’ app development specialists are not sitting still. In addition to the apps we develop for clients, such as the Stopcoach and Great Neighborhood, we also work on our own projects. A good example of such a project is Scheduled, the app that allows you to schedule written messages.

To develop the new Scheduled, we want to go cross-platform. This means hybrid development of the app so that it can be used on all smartphones. This brings two major advantages for us as developers, namely:

• Updates can be made for all platforms at the same time.
• No specialized developers are needed for Android and iOS.

In the past, React Native has been used for this. React Native is a very useful framework for writing apps for multiple platforms with one codebase, but the framework often comes out with new updates that render older versions unusable. For this, we set out to find an alternative that would be easier to maintain and still deliver a good experience for users. The solution to updates for hybrid apps is described in this article.

Introducing opportunities

The first step in this process was to gather a list of possible solutions. Each potential option was then analyzed for specifications. The following options made it to this list.

• React Native
• Xamarin
• Qt
• Cordova
• Flutter
• Progressive Web App
• NativeScript

Framework and programming language

Then, for each option, we looked at what kind of framework it is and what languages it is written in. Regarding the type of framework, a distinction is made between different development methods, specifically:

• Native, where the code is directly intended for a platform and is therefore executable by default (Java/Kotlin for Android and Objective-C/Swift for iOS).
• Hybrid, where apps are actually websites packaged into a native app so they can also be installed as an app.
• Compiled, where the code is “translated” into the native code or UI components of the platform.
• Progressive Web Apps, are similar to Hybrid, but in this case exist as a Web site that opens in the browser, but, lack distinctive browser components such as a URL bar.

Frameworks, methods and programming languages for each possibility are listed below.

• React Native
  • Method:Compiled
  • Language: XML/JS/CSS
• Xamarin
  • Method:Compiled
  • Language: XML/C#
• Qt
  • Method:Compiled
  • Language: XML/JS/C++/CSS
• Cordova
  • Method:Hybrid
  • Language: HTML/JS/CSS
• Flutter
  • Method:Compiled
  • Language: Dart
• Progressive Web App
  • Method:PWA
  • Language: HTML/JS/CSS
• NativeScript
  • Method:Compiled
  • Language: XML/JS/CSS

These frameworks were further examined to see if they have the functional requirements for the app. Among other things, the framework must have the ability to read contacts from the phone and it must be able to work with Firebase, our database solution. It also explored using the framework to read from the calendar for possible extensions in the future.

From the list of possible options, it was decided to drop the frameworks Xamarin, Qt and Flutter. Xamarin, because it does not support Firebase and because contacts and calendar could not be integrated. Qt, because it has no support for Firebase and the calendar. The last option that did not make the selection was Flutter, because there is little experience within the organization with the Dart programming language.

App prototyping

The first round of testing tested fairly general features of the frameworks. Creating a prototype offers more insights into the possibilities a framework can offer.

The remaining items from the list: React Native, Cordova, PWAs and NativeScript, were therefore examined using prototypes. These prototypes are based on a functional foundation of the Scheduled app. This included reading and writing tasks to the database as well as importing and scoring contacts.

These prototypes were tested for functional requirements. These requirements were the speed performance of the app, the amount of time it took to develop the prototype and the amount of code that could be shared between different platforms. In addition, online research was done on the number of components that can be worked with, how often breaking updates are made and the size of the community around each framework.

Functionally, React Native and Cordova were able to meet all the requirements. NativeScript failed to import contacts, and PWAs can only import contacts through a secure, certified connection on Chrome for Android, making the hybrid aspect impossible. The results of the various tests are described in more detail below.

Measuring speed performance

The first test described in detail is the speed test. Speed results were measured in an Android emulator. The results themselves are measured by frametimes, the unit of which is the number of milliseconds it took the graphics processor to display an image. Because thousands of frames are shown while using the app, the results are broken down into the 50th^{, 90th}, ^95th and ^99th percentiles of all frame times.

Below is the graph of these results. Lower numbers mean more frames shown per second, making it feel like a fluid app to the user.

Number of components count

The second test consisted of measuring how many native or native-looking components, per framework. These types of components follow the design guidelines of the platform and make users feel like they are using an app made specifically for the platform. Compiled apps translate the native components where immediately the number of components can be counted. Hybrid apps are actually web apps and thus use standard HTML components.

An additional framework can be used for this purpose. Among developers, Ionic is almost synonymous with Cordova, as the two are often used in combination. Ionic controls the platform it runs on and displays the components that follow the design rules of that platform. So for the Cordova and PWA solutions, the number of Ionic components will be counted. All of this results in the following numbers:

Measure cross-platform code, measure work time and look for breaking updates

The results of the tests for cross-platform code, working time and breaking updates are compiled in a table. For each prototype, it was determined how much code could be shared between different platforms and how long it took to set up the prototype. Furthermore, the number of breaking updates per framework was examined over a two-year period.

 

• React Native
  • Percentage of code shared: 80%
  • Working time (days): 8
  • Number of breaking changes: 10
• NativeScript
  • Percentage of code shared: 90%
  • Working time (days): 8
  • Number of breaking changes: 1
• Cordova
  • Percentage of code shared: 95%
  • Working time (days): 6
  • Number of breaking changes: 0
• PWA
  • Percentage of code shared: 100%
  • Working time (days): 5
  • Number of breaking changes: 0

Community size by framework measurement

Finally, the size of each framework’s community was measured online. The larger the community, the more likely it is that problems you encounter as a developer have already been solved by someone else. Possible solutions are then already known and need only be looked up.

Through GitHub, it measured how many developers are interested in the technology. And through NPM, the package manager that allows these frameworks to be downloaded, it has been measured approximately how much each framework is used.

Conclusion

The tests performed provide important insight into the frameworks’ capabilities. Since NativeScript and PWAs are functionally unsuitable for Scheduled, only React Native and Cordova remain.

The user experience delivered by React Native is significantly smoother than for Cordova. It features fewer components, but also a higher possibility of customization than with Ionic, which focuses more on theming the components. So for the Scheduled app, we decided to continue using React Native.

Alternatives to other projects

However, PWAs are an interesting possibility to keep in mind for future projects. For Scheduled, the framework does not offer all the functionality needed, but qualitatively it is a strong option. The advantage, as well as the disadvantage, of PWAs is that app marketplaces such as the Apple App Store and Google Play can be bypassed. This means it is not useful for public apps because most people install their apps through a marketplace. On the other hand, for private apps, such as in-house solutions for external parties, it would be very convenient if all required functionalities are supported by the browser.

Want to learn more about developing apps in collaboration with Brthrs? Read more about developing a hybrid app, an iOS app, an Android app, a web app or contact Brthrs’ specialists directly.