Blog: Pros and Cons of Developing Native vs. Cross-Platform Web-Based Mobile Application

1. Searching for an optimal solution

During the last several years the evolution of the mobile market has led both the mobile developers and the clients to face the two core questions:

Should we build a native app for each popular platform (iOS, Android, Win8, Blackberry etc.)   or  should we look for a cross-platform solution? And if we decide to go with a cross-platform development to lower costs/efforts, should we build it as a native app (using 3d party cross-platform frameworks)   or should we build an HTML5 web-based solution?

Supporting all mobile platforms: Apple, Android, Windows 8, Blackberry…Of course if you ask a client, the anticipated reaction would be the willingness to capture the biggest share of the mobile platforms market. In this case, however, one would have to develop at least four (!) mobile applications for iOS, Android, Windows Phone and Blackberry platforms.

Here are some major factors that we assessed while searching for an optimal solution and the right balance between cost, time-to-market and app performance:

• TIME: native mobile app development and porting it to other platforms is very time consuming as each new platform requires more or less similar amount of coding time;
• TALENT and DEVELOPMENT SKILLSET: native app development leads to an increased range of the required skills – hence, the increased number of the developers involved in the project;
• COST: as a result of the two factors mentioned above – the cost of native mobile apps development might be doubled, tripled or even quadrupled depending on the number of platforms one would like to cover.

Having said that there are certain cases when it’s preferable to develop a native mobile application:

• when high performance is essential;
• when solution requires processing large amounts of data on the client side;
• when developing utilities that manage system resources or Operating Systems (OS);
• when developing mobile solutions based on video or game scenarios.

However if all of the above factors are not crucial for your application structure, we can try and look for more cost-effective development solutions. We were determined to find a more budget-friendly and less time-consuming solution for developing a not so complex mobile application for all the existing platforms, without having to compromise on both quality and performance of the final product. After doing some research on the general awareness of this problem, we found several articles from very credible sources like Mashable.com, Forbes.com, and Theappentrepreneur.com, which supported our approach and line of reasoning. Just as we expected, no one offered a quick, simple and universal solution, so we’ve decided to perform our own analysis and find a less expensive solution that won’t scare away our mid and small business customers, who are not able to afford development of several native mobile apps at once.

We took the best native apps features to be our criteria:

• better performance;
• hardware (camera, local DB, mic) /OS access provided by the native API;
• lack of serious limitations or show-stoppers between creativity and platforms capabilities.

Chart 1 below sums up the main factors for determining the optimal solution:

 

We ended up facing a choice between the following most popular alternative solutions:

• mobile cross-platform solutions (developed for instance with the help of Phone Gap);
• hybrid cross-platform solutions (mobile website + native app shell for each of the platforms);
• HTML5 mobile website.

By this time we already had experience trying several cross-platform development frameworks (MultiTouch, PhoneGap and etc.) for our customers and spent a considerable time researching what the market says (Brightcove.com, Iconoclastlabs.com, Slideshare). Putting together our experience with developing native apps we could compare it with the cross-platform development. Mobile cross-platform solutions like Phone Gap, for instance, had some serious performance problems when developing complex customized applications based on our customers’ needs.

Here are some of the difficulties that we have experienced when using PhoneGap:

• quick start of the project was quite impossible due to the complexity of this framework;
• it had a high entry barrier (our developers had to spend a lot of time on studying the documentation on minimal default settings changes implementation);
• some system bugs or malperformance required direct involvement of the PhoneGap tech support, slowing down the development process;
• poor performance, caused by some heavy original modules were hard to customize for our needs, but also impossible to ignore;
• OS and hardware access performed not through the native API, but through Phone Gap API, was slowing down the already poor performance even more, and in some cases has limited the app functionality options.

With the HTML5 mobile websites the problem was completely different: according to statistics users spend 25% time more using mobile applications, since mobile websites for the most part have less interactive interface, are not accessible in the offline mode, and have limited functionality.

There is an additional advantage of developing a native app, that’s worth mentioning: when developing native mobile apps for each platform, the application will be caching the maximum amount of data on the client side of the app by default. On the other hand, when developing a web-based solution (either mobile website or mobile web application), the issue of caching, in most of the cases, is not being properly addressed or even ignored by the developers,resulting in a slightly lower performance.

Also for a web-based mobile app, internet connection would be an essential requirement. But at the same time, if we are developing an application based on a client-server architecture, which would perform complex data processing operations on a server side and would send the end-results to the client-side, the need to constantly connect to the back-end server through data connection mainly have to do with the requirement of providing the client with the most updated information.

After performing a thorough analysis of all the solutions, we came to a conclusion, that in certain cases of cross-platform mobile applications development we can achieve almost all the benefits of using the native app, by using the hybrid solution of mobile website and application:

• any client-server application would in any case require internet connection due to the need of communication with web API;
• the hybrid solution would allow access to geo-location data;
• application will be available right after you install it (no need to open the native browser and type in the web address);

In addition to that if the user would connect her device through a high speed data provider, we can achieve the level of performance, which would be comparable to the performance of the native mobile apps. Of course any client-server application, regardless of how it’s implemented, would report poor performance when connected to a network with the low data transfer capability.

2. Selecting a Web-Based Technology: How We Chose Google Closure Framework

With the growth of mobile traffic we faced the need of developing a mobile solution for one of our start-up projects – Pikaba.com. (You are welcome to learn about this project on Pikaba YouTube channel)

In the middle of 2012, we’ve developed a mobile cross-platform application using jQuery Mobile Framework. Back then we already used a hybrid of mobile website and browser container (platform-specific native app shell): we implemented customized templates, styles and screen transitions.
However already at this stage of development it became clear, that this framework would not work for solutions involving processing large amounts of data and requiring a lot of customized features:

• jQuery Mobile made a lot of changes to the initial structure (DOM) and made it more complex and heavy;
• it required a lot of API requests on the server side;
• there was a duplication of data serialization and deserialization due to the data transmission between the server and ASP.NET -based web application;
• there was no code compilation and optimization on a server side;
• one of the main problems in the app performance on the client side was a certain level of “hybernation” during the in-between screen transition and data upload from the current DOM.

All the above led to a very slow and poor performance, which pushed us to look for a more efficient solution, which at the same timewould be more cost-effective than developing a native mobile application for each platform.

First of all we identified an optimal architecture: the SPA (Single Page Application) website written on JavaScript, which is rendered within a native application, based on the browser with the limited browser features.

At the end we would get a mobile website-application, with the following capabilities:

• the app structure (DOM) was much more compact than the one we had in our previous solution;
• all the operations were performed on the server side, moving the workload away from the client;
• it tracked pages hashtags and provided asynchronous content loading;
• it had practically full access to the hardware and software of the device, as oppose to a regular mobile website, uploaded through browser;
• development cost was much lower, since we only needed to develop containers for each platform to cover all of them.

Now we only had to make the most important decision – choose the framework to work with JavaScript. Among the strongest candidates we have considered were Backbone.JS Framework and Google Closure Tools. One can spend lots of time debating on pros and cons of each technology stack, and for the most part choosing a certain framework would depend on personal preferences and experience. We have decided to go with Google Closure Tools (and as we have discovered later we were not the only ones).

The following parameters became the decisive factors for us:

• our team has already had experience of working with this framework, which lowered the entry barrier to the productive stage of the development process;
• the fact that Google had its own compiler, which allowed code optimization and minimization by compiling it into a single file, was a clear advantage;
• the ability to write unit-tests directly on Google Closure base without any need to look for additional tools (like Jasmine or others);
• ability of your MVC Framework (Model–View–Controller) implementation;

In addition to that, although Google JavaScript compiler could work with any framework (e.g. Blackbone.JS), our development team has decided to go with the tandem of two products by the same company.

3. Case Study: Implementing Our Cross-Platform Solution on Pikaba Mobile

Having decided on the technology stack, at the end of 2012 we started the development ot Pikaba Mobile cross-platform mobile application. We’ve decided to create the functional part for the buyers first, and address all the merchant-oriented features at a later stage.

We started with just the basic number of features, which would allow user to :

• login and create accounts;
• create, edit and save requests;
• browse requests, products and services or search for the specific ones;
• browse profiles and grids.

Our team had first to develop our own MVC Framework to work with Google Closure. Of course we were aware of the already existing frameworks, such as AngularJS, EmberJS, KnockoutJS, where MVC model has been already implemented and communication with UI would have been much easier. However all the extra perks from Google Closure Tools such as super-functional compiler, support and unit-test writing tools were strong enough for us to make us spend some extra time on writing our own framework.

Overall we spent much less time on developing, testing and deploying the complete features package mentioned above compared to our previous approach. On top of this, most of the features had unit-tests written directly on Google Closure Tools basis.

 

THE BOTTOM LINE: We managed to build a web-based cross-platform mobile app with performance level being so high that you could barely distinguish it from the one achieved with a native app. This was the key success factor, which proved our management that suggested solution was a great choice. After all, if we can build a high performing cross-platform app, which costs 3 times less than native ones, no one would argue with such efficiency!!

4. Afterwords and Summary

Of course there is no universal solution which could address all our clients’ requests, but we managed to find a solution, which is both cost-effective and presents a good alternative to developing native mobile applications for each platform, and would therefore address a great amount of incoming requests for mobile applications development.

This hybrid solution combining a mobile website and a native app shell preserves all the mobile website advantages: we can integrate Google Analytics and research users’ behavior within the app, we can segment the audience, and track users’ moves within our mobile website application, as well as perform other analytical operations.

Another unbeatable advantage of such a hybrid solution: there is no need to release new app versions on Google Play, iTunes and other app stores for bug fixes or upgrades. For the user to benefit from all the recent updates, bug fixes or upgrades, she would simply need to refresh the page or re-open the application.

For many of our clients such solution will help to cut maintenance and support expenses in a long run. In case some new platform enters the market – our client can easily cover it by developing another native app shell with us, while concentrating on improving and expanding the functional part of the application.