Cross-platform vs. native apps: comparing and selecting approaches

Which type of app development is preferable in what circumstances — native or cross-platform?

Cross-platform vs. native apps: comparing and selecting approaches

Cross-platform vs. native apps: comparing and selecting approaches

Cross-platform vs. native apps: comparing and selecting approaches , photo 1

App-venture Time

As a general rule, every business goes online according to the following scenario — the company opens up a website which is then adapted for mobile devices, and if an increase in traffic is observed, the company finds it worthwhile to secure its position among mobile device owners and releases an app.

Comparing a mobile website and an app seems redundant, as an app is obviously superior with its broader range of features and a responsive interface that is much more comfortable to use on a phone or a tablet. Moreover, an app can be used offline.

Regardless of what your business is primarily focused on — sales, services or education — you simply can’t afford to ignore the amount of time people spend with their mobile gadgets.

This article is aimed to shed light on two distinct approaches in app development — native and cross-platform.

Both approaches have their own specifics that greatly influence the end product. To help the customer and the developer understand each other better, it seems like a good idea to elaborate on both approaches, highlight their pros and cons, strike at the deep-seated stereotypes that surround the process of development and try to answer the big question: what is the most viable approach?

Native approach

The apps you encounter on the first day of using your device are native — they are your default browser, mail client, address book, alarm clock, calendar and other basic programs.

When the developers use a programming language that is conventional for the specific platform like Objective-C and Swift for iOS or Java for Android, the app is considered native. Native apps have access to all services and features of the phone like camera, microphone, geolocation, accelerometer, calendar, media files, notifications and so on. In other words, native apps fit right in with the device and feel «at home».

Cross-platform approach

On the other hand, imagine a mobile website that doesn’t have to be online and that is closer to mobile apps instead of web pages from a design standpoint. This is a rough outline of what cross-platform apps are.

They are often created using formatting and styles (HTML, CSS and JavaScript), much like mobile websites. This is a viable approach because, after all, most Internet content consists of HTML pages. Such apps are written for all platforms simultaneously and are suitable for most devices as they use a browser engine to work.

Most specialists who deal with such apps use the PhoneGap framework, which is remarkable for granting the app access to most software and hardware capabilities of the platform. Cross-platform development is also done using techs like Xamarin, Unity and others, but they are less popular than web technologies for app development.

«Live Typing» has experience in  cross-platform app development. Some of our projects such as Classboom and Pocket career were build on PhoneGap technology. Below is a quote from our short technology review for Clutch.

«PhoneGap helps us build reliable cross-platform apps that run on both iOS and Android. In particular, PhoneGap helps us reduce the time it takes to build an app, which reduces costs for our clients."

Vladislav Korobov, Live Typing`s COO

Hybrid apps

Apparently, the bar to enter the immensely profitable mobile app development field has lowered significantly, so one might think that layout designers who are fine with using tried and true HTML and CSS will now take the bread away from proper coders. Some, however, consider the cross-platform approach to be the future in which time and resources spent on app development will be fully optimized. Both sides have solid arguments that present their respective approach to development as the right one.

But when we look for a solution to a specific task, the most effective way is to combine both approaches by employing the cross-platform capabilities of HTML to shape the app’s content, while making the menus and other interface elements that require responsiveness and high performance native. This way, we spend the least amount of resources, time and budget. Such apps are called «hybrid» and in their case only the amount of native code determines which approach is better suited for their development.

What situations may call for a hybrid approach? Let’s say the customer requires a straightforward newsfeed that contains nothing but text and images. With this task in mind, the developer is right to choose the cross-platform approach. But if after a while the customer wants the app to store a large amount of data or process sound or graphics, the task becomes more complex. The developer now has to write native code for each specific platform, and the app that was once fully cross-platform goes hybrid.

It is a popular fallacy that behind every icon on the user’s desktop there is a native app. This fallacy is so  deep-rooted that even professional groups are sometimes guilty of using highly absurd terms like «native PhoneGap app». As it is perfectly normal to put a website link on the user’s desktop, an icon is no guarantee of a native app, so it’s equally possible for an icon to lead the user to either a native or a  cross-platform app.

Approach comparison

The market of offers is expanding. Mobile app sales statistics indicate that year after year gadget users switch default services to alternative ones. The built-in task manager is replaced with Wunderlist, the default mail client is substituted with the Mailbox app and Evernote is preferred to the standard note editor.

It’s essential for the customer to know the pros and cons of both approaches and don’t have unreasonably high expectations when making their choice. A range of criteria would be appropriate for a comparative analysis of both approaches.

Platform dependency

It may look as if a  cross-platform app is equally at home on all platforms down to the least popular ones. This is partially correct with the caveat that an additional fragment of code might have to be written for each platform. In case of native apps excellent performance is almost certain, but each platform requires its own version.

Interface design

When talking about mobile apps, mentioning guidelines is inevitable. Guidelines are valuable instructions that the companies that create platforms provide for mobile app developers to help them fit their design and features into the platform design standards. Guidelines are the psychological foundation of the user’s comfort — simply put, they ensure that the interface elements look familiar and are conveniently arranged.

The language environment in which native apps are developed contains the tools necessary to create an interface that would be familiar to the user. Web technology, however, is different — making a  cross-platform app look like a native app takes a lot of effort. Various cross-platform frameworks (Framework 7, Sencha Touch, Kendo UI, Ionic, etc.) help imitate the native interface more or less believably, but responsiveness, animation speed, effects and overall design will differ more often than not, which leads us to our next topic.

User experience

The first thing the user subconsciously expects from an app is responsiveness. Each of the user’s action must elicit a response, page scrolling and animation has to be smooth and nothing should freeze up. Cross-platforms apps fall short of native ones in this regard; to put it bluntly, their greatest disadvantage is that they lag.

The user is also convinced that every interface element and icon is supposed to have a consistent look and position on the app’s screen. These standards vary on different platforms, and if a  cross-platform app is made according to iOS guidelines, Android users would find it inconvenient and vice-versa.

The Back button is one of the most vivid examples — it’s a typical Android feature which has no iOS counterpart. As a result, when creating a  cross-platform app the developer has to settle for one of the two trade-offs: either the design stays the same for both platforms and some users will have to adapt, or different designs which take into account each platform’s specifics have to be made. In the second case, two apps are actually made using one cross-platform language.


A native app written for a specific platform feels completely at home in it, enjoying full access to the device’s services and features. But when designing a  cross-platform app the developer has to keep in mind that he only has the capabilities provided by the framework, which are limited.

Frameworks are also liable to have a whole range of versions and the older the version, the more limitations it imposes. Even in the best scenario a  cross-platform app has access only to a part of the platform’s features. With this being said, full integration is not always necessary — everything depends on the task the app is supposed to do.


HTTPS exists as the standard secure data transfer protocol for all popular browsers. But if a higher level of encryption is required, the developer is expected to come up with a solution. The trick is that reliable data security can only be guaranteed with native development, as security requires extensive calculations, and thus requires maximum efficiency of hardware usage.

Maintenance and support

Complex maintenance of native apps for two platforms at once (troubleshooting, updates and literally every single small patch) on average takes twice as much resources because two different specialists (iOS and Android) are required. A  cross-platform app is easily supported by a single developer.

Price formation for mobile app development and time spent on it is a topic mired in fallacies and myths, which is why these issues should be brought up separately in an attempt to set matters straight or at least try to clear things up somewhat.

Is quick and cheap cross-platform development a myth or a reality?

Cross-platform development is usually cheaper and takes up fewer resources compared to native development. However, there are certain pitfalls one can only avoid by understanding the basic principles of price formation.

Always keep in mind that timescales and prices are, first and foremost, governed by the difficulty of the task and the end quality of the solution. Let’s say that to develop our cross-platform product we hired one specialist who is skilled in HTML, CSS, JavaScript and has some PhoneGap experience. Let’s regard this specialist as an abstract resource unit (say, a man month).

Two such units are required for native app development — for iOS and Android. As a result, 2 man months are required for the native project, and 1.5 — for the cross-platform project.

A fair question is in order: «Why one and a half instead of one»? Sadly, in reality a  cross-platform app that performs nicely on iOS will work poorly on Android as all browser engines have their own specifics, and, as a result, one half of a man month might be spent on optimizing the app for Android.

Here is an estimate of mobile app development cost in case of both native and cross-platform approach in the form of two tables. The results are loosely based on the average hourly rate of freelancers from the international database in USD.

PlatformAVG Freelancer, $Man monthsHoursTotal, $
Hybrid app251,52406000

When we were comparing the approaches according to several criteria, we mentioned that the degree of platform integration of the app is determined by the difficulty of the task the app solves. Be aware that using a specific template or a  ready-made solution can be a cheap way to create an app as long as this template or solution’s capabilities are enough for your specific task.

But there’s a catch

And the catch is in the app’s structural specifics. More often than not a functioning app implies that there’s a server side where the users save their data and using which they exchange their data with others. This leads to further expenses. Working on the server side may take up to one third of development time and even more if an admin panel has to be created for convenient data management.


By all means, go for native development if:

  • Your application requires full access to the phone’s resources and services;
  • You want your app to be as responsive as possible;
  • The app has to work offline;
  • Your app should have maximum efficiency when using the device’s hardware.

Cross-platform development should be your choice if:

  • You can live with lower responsiveness;
  • You do not intend your app to contain complex animation or carry out calculations;
  • Your app requires stable Internet connection to download content;
  • You need to enter the market quickly to test your idea;
  • You have a website and you want to turn it into an app for a minimal price.

The final choice of your strategy is determined by individual circumstances, something for which no article can give you a universally applicable answer.

This text is more of an  entry-level, generic guide aimed to help the customer and the developer come to terms with each other. At the end of the day, your final decision should be made with the developer’s advice in mind. The more reasons the developer provides for this or that approach, the better.

For Customers
How to Create an Effective eCommerce App

One third of online purchases are made through mobile apps, and that part is increasing from year to year. What should be the eCommerce mobile app to bring money to your business? Follo...

For Customers
August 01, 2019
How to save money on back-end development for mobile app

The backend for a mobile application is one of the most expensive graphs at the development stage. In this article we will talk about how to reduce costs withou...

For Customers
August 09, 2019
Dealing With Android: The 5 Pains And The Remedy

«Live Typing» Android department`s teamlead Alexander Mirko explained about pitfalls of Android-development and ways to avoid them

For Customers
March 20, 2016