Hybrid application: how to avoid project failure due to poor performance?

Posted on by Olivier PHILIPPOT
Reading Time: 4 minutes

In a time of digitalization and strong growth in mobility, the development of mobile applications has become strategic for all businesses.

Current mobile applications challenge

The multiple mobile screens have indeed become the privileged interfaces of all services (digital or not): bank window, form for operators, showcase for the trade… This strategic positioning in the value chain of the company implies a strong pressure on development teams: tight schedules, need to cover different platforms (iOS, Android…), need to start from the existing information system… This pressure implies technical choices on technologies and architectures that best meet these needs.

If the architecture choices initially allow one to answer the constraints of the market, they pose many problems when the application arrives in production. Indeed, these choices don’t necessarily take into account all the criteria (performance, energy consumption, debt…). GREENSPECTOR unfortunately steps in frequently after production starts with critical issues: unsatisfactory performance, impact on battery life too high… And hybrid applications are often the cause of these problems.

Indeed, efficiency is one of the most important criteria for the success of an application. Users are waiting for speed but also want smartphones that last. It’s important to choose the technology taking into account of course the project and market constraints but also this user need. Without this, we risk a pitfall of the project. In the project of an already decided choice of technology and an application in production, the improvement is however possible.

State of the art of mobile architectures

It’s necessary to clearly distinguish the different technologies to develop a mobile application:

  • Native applications are developed in the language supported by the platform. For Android: Java or Kotlin). For iOS: Objective-C. The advantage is that the application will be optimized for the platform. The problem is that it’s necessary to develop as many applications as platforms covered.
  • Hybrid applications will allow the use of non-native technologies to mobile platforms and mainly web technologies. The advantage is to be able to use code that has potentially already been developed for the web or simply to develop a mobile application with web teams. The most widespread technology is Cordova but React Native becomes more and more used.
  • Progressive Web App (PWA) are the logical next step of hybrid applications. Mobile browsers and the HTML standard having integrated communication capabilities with the platform (Bluetooth Low Energy for instance), it’s now possible to develop a full web application.

Criteria of choice for architecture and pitfalls

The criteria of choice at the start of the project are mainly based on three points:

  • Developers are mainly Web.
  • There are already many solutions (legacy, CMS…) for the web that will allow me to go faster.
  • We will go faster because there are no two applications (iOS and Android) to develop.

The economic calculation seems indeed simple. However it is important to make a calculation over the entire life cycle of the application.
It is therefore necessary to identify the potential problems that we will encounter:

  • The encapsulation of web technologies leads to tooling problems. For example, once encapsulated in a Cordova application, a web application will be difficult to parse. It will be difficult to track resource consumption, internal behavior… in native tools. Nothing is impossible (for example via Chrome’s remote debugging tools) but a barrier that some teams will not want to go through. In the end, we will arrive at a controlled development on the web part but with a black box behavior on the final platform.
  • Libraries, legacy code or CMS originally designed for the web do not take into account the constraints of mobile platforms (radio connection with a different behavior of the wifi, not optimization…). And even if an adaptation to mobile platforms has been made, the initial design and architecture can not be changed. In the end, there is a risk of integrating non-optimal mechanisms for mobile platforms.
  • In the case of technologies like Cordova, the initial framework is heavy in terms of resources. It takes more than 100 MB of memory consumption to run Cordova (against a few tens for a native application). We can not optimize this stub of consumption.

The risk on the final application is to have impacts on the fluidity and performance of the application. We have observed loading times of more than 10 seconds on application views while 2 seconds could have been done in native, application crashes spread over several APKs, energy consumption leading to autonomies not. In the end, these pitfalls require the analysis by teams, the intervention of external experts, refactoring projects, new validation campaigns… Not to mention the economic impact of a non-performing application for the user.
The simplified economic analysis at the beginning of the project is no longer appropriate.

My architecture was badly chosen, what to do?

If you are in the case of a hybrid application, it’s possible that everything goes well (Display less than 3s in 2G, no impact on the battery, low consumption on low end devices…). If this isn’t the case, it’s always possible to improve the performance by using and applying good practices of software ecodesign or performance. However, it’s likely that you won’t achieve the equivalent efficiency of a native application, depending on the level of efficiency you want for the user.
If web technologies are an axis that you still want to use, it will be better to study technologies like React or PWA applications. Performance promises are more important for these technologies. However, like any new technology, these promises may not be there. It’s therefore important firstly to benchmark the solutions before choosing them (study of the impact on resources, performance of the “Hello World”…) and secondly to continuously measure the impact of your application. Indeed, whatever the technology, the integration of third-party libraries or bad practices will cancel the initial efforts of optimization.
From the perspective of maximum efficiency, native technologies will be preferred. The point of attention of web technologies (control of a potential drift of consumption) is however still true.
No miracle solution therefore, it is necessary to control continuously (When choosing technologies, development and maintenance) the resource consumption and the performance of the applications. Indeed the promises of performance and rapid development of frameworks and libraries is perhaps true, the entropy of software is systematically verified. There is only one way to control it: continuous measurement.