Native VS Cross-platform

What does native mean? What is cross-platform?

First, we need to define those concepts in terms of mobile development. Majority of smart devices (e.g.  smartphones, tablets) use one of two platforms: Android or iOS.
As of February 2020, mobile operating system market share in Estonia was divided as follows: 67,68% for Android OS, 31,7% for iOS and reminder 0,62% for other operating systems. That is why most of the apps are developed for Android and iOS devices.

Main differences between Android and iOS come from the use of different architectures, and programming languages that are used to write the code - Java or Kotlin for Android and Objective-C or Swift for iOS.
Native approach means that the code written for the Android app cannot be used to build an iOS application. So, if the objective is to reach as many users as possible, you will need to develop two different apps - one for Android and one for iOS.

In contrary, cross-platform app is developed using intermediate programming language.

Comparison of native and cross-platform:
-    Performance
Native (N):
Native apps have the ability to make use of most of the features offered by respective platform and hardware. It is also easier for native apps to use device resources (like memory, battery and CPU) more efficiently.
Cross-platform (CP):
These apps have limited access to the features offered by devices. One-size-fits-all-approach means that CP apps often have lower performance and can sometimes act unpredictably.

Winner: Native

-    Cost of development
N: Developing native apps consumes initially more time and money, because reaching more users means developing two apps - one for Android and one for iOS.
CP: The initial development cost is lower because only one codebase is needed.
That being said, some CP apps that have more complicated functionality might have significantly more bugs. Also identifying and fixing those bugs might take longer than in the case of native apps. So, regarding to CP apps - it takes less time to get them going but the long-term cost is likely going to be on par with the development cost of native apps.

Winner: It is a draw!
-    User experience
N: There are platform-specific IDEs (integrated development environments) that allow to simplify the design and development process of native apps. Also, it is easier to fulfill high UI and UX standards defined by Google and Apple.
CP: Android has different requirements for UI and UX than iOS, and it is not that easy to achieve both of those sets of requirements with one app. Also using CP app might feel strange for a person who is used to interacting with native apps.

Winner: Native
-    Number of users
N: There are platform-specific IDEs (integrated development environments) N: You will probably have to choose one platform if there are limitations in time or budget, however this means you will lose a remarkable share of users.
CP: One portable code means that you can reach all the users regardless of the platform they are using.

Winner: Cross-platform
-    OS update integration
N: Native languages and tools support OS updates since day one.
CP: There is an inevitable period of latency between the release of OS updates and integrating them into CP frameworks.

Winner: Native
-    Integration of updates for the app
N: Having two apps (one for iOS and one for Android) means that integrating design or functionality updates consumes more resources because you have to modify two apps.
CP: One code means that users of different platforms can receive app updates faster and simultaneously.

Winner: Cross-platform
Considerations before making the decision between native and cross-platform:

As you can see, both approaches have their pros and cons. Next step is to determine what kind of an app do you need.

. Enterprise app aka business-to-employee or B2E app (for example some kind of a tool or inner communication app). B2E apps are expected to be long-lasting and can be quite complicated but might not need to support the latest functionalities of platforms. Also, the company might decide to use one platform strategy, so there's no need to cover more than one OS.
 
. App for customers that are used daily aka business-to-customer or B2C app (for example e-commerce app). These apps are expected to have a long shelf-life, provide as good performance and user experience as possible and should be available for both Android and iOS users.
 
. Marketing app to clients that are also B2C facing (for example an app developed for one-time event or campaign). These apps are expected to remain in the app stores for a short period of time, to be pretty simple but eye-catching.
 
. App for business partners aka business-to-business or B2B app.
 
. These apps are pretty similar to B2E apps regarding to the longevity and the higher level on complexity, but the main difference is that you do not have control over the device strategy used by your business partner. It means that supporting different platforms is recommended.


Some guidelines:
If you are planning to build a complicated app that largely depends on native tools and platform-specific capabilities or uses the latest technologies like augmented reality or machine learning, then you are probably best off choosing native approach.

Integration of different services (e.g. Dropbox or Stripe) might not have good support in cross-platform frameworks. In some cases, they might not be supported at all, which means that developer must write the bridging component themselves or depend on unreliable or outdated third-party library.

If you plan to develop B2C app with long lifetime and good performance the suggestion is to use native approach.

If you have done enough research, your app has simpler business logic and there are noticeable time and financial constraints present, then the suggestion is to use cross-platform approach.

Conclusion:
There is no single answer to the question "Should I use native or cross-platform approach?". Careful analysis is needed to determine main factors affecting the decision. How complex is the app going to be? What is the expected lifetime of the app? Who are going to use the app? Are there enough resources allocated to the development? Extensive research and discussions with specialists will help you to find the best solution for your needs.