App development

Native or hybrid app

From a quality point of view, we always recommend native app development. Here you can read why.

Native or hybrid app?
Native or hybrid app?

Why do we recommend native app development?

At Makeable, we have a clear preference for native app solutions. They perform better technically, ensure higher performance, provide a more responsive user experience (UX) and a better user interface (UI). Native apps are also optimised for the specific platform, ensuring better security and reliability. In addition, app longevity, maintainability and customisability and far better cross-platform performance.

And why is that? Native apps are tailored to specific devices, ensuring optimal performance and integration for your business or idea.

Read on below to learn more about the difference between native apps and hybrid apps and why we recommend native app development.

Native or hybrid app?
Native or hybrid app?

Benefits of native apps

With native development, performance is top notch and the utilisation of the device hardware is optimal. It always gives the best results and is the safest choice, as there is full access to the devices’ hardware. At the same time, there is always access to the latest features in the devices’ software/operating system (iOS/Android).

If an app relies on hardware or communication with external hardware as its focal point, a native app – developed in Swift for iOS or Kotlin for Android – will provide the ability to utilise 100% of the device’s functionality and ensure a better IT architecture. In contrast, a hybrid app will not be able to interact with external hardware without undue customisation.

Disadvantages of native apps

The only downside to native solutions is budget. Native can take a little longer to develop. On the other hand, you avoid having to develop additional (native) elements later on, which is often the case with a hybrid app.

In addition, it’s usually easier to find one person to develop the whole thing for a hybrid app, whereas with native you usually have one person specialising in Android and one specialising in iOS. In other words, more developers need to be involved in the process. Here you can argue the value of not placing it all in the hands of a single individual in relation to the professional level of the finished app solution.

By using specialised developers, you also get an app that is more compliant with the platform’s standards because the developers know them. In many areas, there are big differences between how an app should behave on Android and iOS.

Native or hybrid app?

Disadvantages of hybrid apps

Once a hybrid app is developed, it can run on both Android and iPhone. In order to handle both systems, it uses an extra ‘translation layer’ that dictates to the two apps what they can and cannot do. An extra, unnecessary dependency will therefore be included in the app, which in both the short and long term can cause challenges for the upcoming development, future operation and maintenance of the app.

For this reason, a hybrid app will not perform as well as a native app and there will be limitations in terms of access to the device hardware. Since a hybrid app contains a translator layer provided by a third party (e.g. Microsoft, Facebook or Adobe), there will be an inappropriate dependency on the provider of the software that creates this translator. This can cause inconvenience when running the app and when Apple and Android update their operating systems.

In addition, hybrid development languages are developed in large organisations that have primarily aimed to develop apps to power their own products. For the same reason, there is limited interest in developing functionality that does not benefit their own platform. Examples include:

React Native is developed by Facebook for its own platform

Xamarin is developed by Microsoft for its own platform

Flutter is developed by Google for its own platform

Furthermore, despite React having “native” in its name, hybrid tools are based on web technology and not app technology. If the app needs to use a feature that is not yet supported in the hybrid platform, native iOS and Android code must be developed, and this is where the hybrid developer quickly falls short.

The same applies when integrating with third-party services. The vast majority of third-party services only develop SDKs (development kits/tools) for native iOS and Android. Therefore, you cannot use their exposed SDKs until a translator has been developed for the chosen hybrid language.

Often a native developer needs to be involved anyway

Basically, you should always see a pure hybrid solution as the ability to use the lowest common denominator on the two platforms, meaning that if something is only available on one platform, such as NFC reading or similar, you will not be able to use this in a hybrid solution as it must be available on both platforms.

However, you may choose to include some native development as a “skin” on your hybrid solution to open up specific platform possibilities. By doing this, a native developer will need to be involved, reducing the savings that hybrid development has provided. It also increases complexity, which affects reliability.

Advantages of hybrid apps

Hybrid solutions are usually cheaper than native solutions. At least in the short term. In addition, you can assign a smaller team/individual to the task, as the same resource(s) will handle the task for both platforms – as long as no native elements need to be developed into the hybrid app, which is the case for most hybrid solutions sooner or later. Of course, it can be seen as an advantage that the option to connect native modules is available at all.

Hybrid solutions are ideal for smaller projects and prototypes with lower app performance requirements

Native or hybrid app?

We were there from the beginning
and have helped 100+ businesses

Why opt out of a hybrid solution?

Limitations of a hybrid app

As mentioned, we also develop hybrid apps here at Makeable, but common to the solutions where we have recommended a hybrid solution is that it has been limited to projects that have either:

  • A short-term focus
  • A tight economy in the first version, so you deliberately choose to create an app that you don’t want to develop further in the long term
  • A solution that will not guarantee operation for more than 1-2 years.

Experience with hybrid that has led to native

We have been involved in several projects where the customer wanted to use a hybrid platform and we advised the customer to choose a native solution due to project complexity, reliability etc.

In some cases, the customer has maintained their desire for a hybrid solution and we have therefore declined the assignment for professional reasons. In several of these cases, the customer returned to us after launching their hybrid solution and asked us to develop a new native app.

Native or hybrid app?

Why switching from native app to hybrid app can be a bad idea

Bankdata provides a common app platform for eight Danish banks including Jyske Bank, Sydbank and Ringkjøbing Landbobank. The app for these banks has been a very popular and acclaimed app based on native technology.

During the summer of 2021, Bankdata relaunched all these banks’ online banking apps as a hybrid solution. This relaunch has resulted in a significantly worse app that generally provides a lacklustre user experience compared to the native app that users have previously been used to.