Native vs html5 vs Hybrid — that debate again

So in our team the html5 vs Native vs Hybrid apps discussion started again. We have had this debate many many times. Earlier, every new product that we developed started with this debate. Our partners and clients asked us about this choice every time. Over the period of time we had developed strong competency in Native platforms so a natural bias towards Native existed. However, we would try and weigh in all the pros and cons before deciding on the technology. The easiest answer to the choice of platform is “It depends”. It depends on the type of app you want to develop and the sort of stage your product is at. Instead of writing pros and cons of each approach I will just narrate one of our experience

Our Experience

I remember we had quite some experimentation done on this in late 2013. We were making an in-house attendance management app that we later launched by the name of Clockit.

We were experimenting with multiple things at that time. Some of our objectives were to enable the team to i) create and launch applications rapidly ii) push the backend developers to use hybrid app development platforms to launch mobile apps without the need of Native application development knowledge, and iii) experiment with platforms like google cloud and parse.com to enable ourselves for faster development.

1st iteration was good

In the first iteration we developed the backend in Parse.com and started development of the mobile app in Phonegap. The results were good. Although the team needed some time to get acquainted with the new frameworks, we were able to produce the first iteration failry quickly. The developer that worked on this app did not have earlier experience in either of the platforms but was well versed in PHP and javascript.

2nd iteration made us rethink

Some requirements came up in the second iteration that made us think whether we were going in the right direction with this approach or not. Just to be very specific, on a certain action we needed to launch the front camera in the app by default. At the time we found it very hard to make it work on all devices so we started writing custom (native) code within Phonegap to handle this requirement. The team needed help form the core mobile development team to address this situation. The other bottleneck started to show on Parse.com side. There were a few background services that we wanted to run and Parse’s cloud code was becoming cumbersome for it. Clockit app would record the attendance of the individuals on the mobile device and sync with the cloud as a background service. We needed to enable the application for environments where network connectivity was not constant. Clockit attendance management system works in offline and online mode and syncs the data automatically when it finds network connectivity. We handled the situation in Parse with the hybrid app but the limitations of our tech choice started to become evident. Since it was an attendance app that would let the users checkin and checkout it needed to be fast. We had a goal of 4 second checkin for the app.

3rd iteration and the inevitable switch

In order to reach the goal of less than 4 second checkin we had to create a custom camera screen. We wanted to dedicate a portion of the screen for camera. This is where Phonegap could not catchup. Additionally Parse created a very difficult data model for the background sync functionality and reporting to be efficient. Although Parse had some really good back sync functions already present but the reports became very slow. Another limitation was the availability of debugger tools for Phonegap. In this regard the native application development platforms were and are way superior. This was one of the big reason why the biggest proponent of html5 apps Linkedin ditched it for Native as well.

We then made a decision to go Native and created a custom backend as well. We were able to achieve our performance objectives for the app because now everything was in our control. AND then we lived happily ever after! :) OR did we?

Analysis of the situation

One of our Tech Advisors actually created a list in the recent debate we were having on this topic. If the requirements are to have a really slick app with amazing UX native is the right choice. This choice comes with a price though. The roll out of the app will take time and resources. Unless you have a super team of Full stack developers you will need experts in the backend technology that you choose with the developers proficient in the native platforms. Thankfully with the decline of Windows, Blackberry and symbian; now you just need iOS and Android developers. On the contrary if the resources and time is limited then maybe go with the Hybrid platforms. I still do not agree 100% with the turnaround time part but that maybe because we are not very well versed in these frameworks at the moment.

So if we do not have high UI/UX requirements we can avoid Native platforms right?

The answer is yes BUT only for short while. As the app usage grows you will need to make the UI and UX better. By that time maybe the framework that you developed the app in may evolve OR you will have enough resources to manage a team of Native application developers.

Since our last (rigorous) experimentation things have evolved for the Hybrid platforms as well. Ionic, Sencha, Famo.us and many more have evolved and have come quite close to Native in performance. Our analysis might look dated since we have not experimented with all the new frameworks very rigorously. If the target is “Rapid Application Development”, as one of our Tech advisors and Mentors has started to call our approach, then developing competency in these frameworks is the right strategy. If you already have enough funding and time and want to make the right product for you, build the right team and choose Native. Native will remain closer to the device functions because it is released and supported by the same vendor that actually is doing R&D on the future iteration of the OS and the device. Hybrid platforms will remain followers. The choice will always depend on your situation.

As always things will continue to evolve and my recommendations will become void with the evolution of technologies. While we already have expertis is iOS and Android development, our plan is to start experimentation in these frameworks again.

You “might” find me writing a blog in support of one of the frameworks vs Native if we find that they now cater to our needs. Till then…