Hybrid apps versus native apps. HTML5 and Sencha Touch development

Hybrid apps versus native apps. HTML5 and Sencha Touch development

150 150 admin

In my previous article, I mentioned the convenience of developing hybrid mobile apps using Javascript/HTML5 frameworks and I recommended Sencha Touch as my favorite. Since then, this framework has evolved and the Sencha development team has continued to support and improve their products. Specifically for mobile development, they now offer the following tools:

  • Sencha Architect
  • Sencha Touch
  • Sencha Eclipse Plugin
  • Sencha Touch Charts
  • Sencha Mobile Packaging
  • Sencha Support Package

(You can get all the information you need about these tools and some usage examples in the Sencha website so I am not going to get into details.)

After over three years of experience developing mobile apps, I still believe Sencha Touch is one of the most advanced mobile frameworks out there, although it doesn’t escape from the inconsistencies of HTML5 implementations in the real world.

I wish I could say everything is smooth and easy in hybrid application development but I can’t. One of the main problems I have found when developing hybrid apps in Sencha Touch is that they (in many case) don’t have the same behavior in every platform. Somehow this would be expected, but things get worse when trying to create a generic application for the Android platform. Due to the number of Android devices manufacturers and different (sometimes customized) versions of Android OS, it is very challenging creating an HTML5 based mobile app that is compatible with the HTML5 implementation of all these devices and versions. In the case of iOS, since all the devices are manufactured by the same company and the HTML5 implementation in Mobile Safari is standard across devices, making an in-platform compatible mobile app is much easier.

The other problem I have found with hybrid apps developed in Sencha Touch compared to native apps is performance. This can also be expected when considering that we are using the browser UI and pretty large javascript files in order to run our HTML app. In some cases this difference in performance does not represent a real problem when comparing it to the convenience of developing a hybrid app. Also, considering that mobile devices are more advanced every year with faster processors and more hardware capabilities in general, this should become less of a problem. However, in some heavy apps the slower performance can be noticeable.

We can’t really blame mobile HTML5 based frameworks for any of these issues since they are inherent to the solution itself. These frameworks provide an alternative to the standard native application development method but are not perfect, and it is very important to understand the pros and cons.

In conclusion, developing hybrid apps could save developers a considerable amount of time, but it could also be a nightmare trying to make them work in all the mobile frameworks and devices. My advice is evaluating the specifications of the app and compatibility requirements before making any development decisions. In some cases, we have been able to create hybrid apps that meet all of our customers’ specifications and compatibility requirements without any problem, but in other cases, we have taken (for good) the path of developing native apps.

Next time you develop a mobile app, consider all the options. The more experienced you get, the better choices you will make. Doesn’t this principle apply pretty much to everything in our daily lives?