ITIDO

Applications for mobile platforms became the norm with the explosive proliferation of mobile devices. Engineers develop with Kotlin/Java for Android and with Swift/Objective C for iOS. These became known as “native” technologies.
However, with the growing need to cover every platform came a timely engineering response: going hybrid. It means developing with a single codebase for both Android and iOS. As of late 2022, there are several popular hybrid frameworks:

• Flutter
• React Native
• Kotlin Multiplatform mobile (KMM)
• Ionic
• Xamarin

At ITIDO, we’re experienced mainly with Flutter and React Native – frameworks that were initially released in 2017 and 2015, respectively. Even though these are relatively new, they are backed by large communities. Moreover, corporations like Meta and Google pour resources into the future of React Native and Flutter. Thousands of digital products rely on them every day.

Going hybrid: the advantages plus some risks

The advantages of a hybrid approach vary depending on the application’s functionality, the experience of the dev team, the budget, etc. The ITIDO engineers believe that if your app has a huge scope of functionality or much of it depends on device sensors, it is better to stick with native. There are many native Android and iOS applications in the app stores. Popular examples of such products include LinkedIn, Skrill, and Tinder.
When is it ok to go hybrid then? If you aim to build a minimum viable product (MVP) to test a business idea, it is reasonable to go hybrid. What are the advantages here?

• There is one code base for both platforms. In the case of Flutter web is also supported.
• Balancing man-power with workload. This lowers the overall cost for developing, launching and supporting an app. Developers in one team could cover colleagues when they are absent. This is regardless of the platform. In contrast, for a product with two native apps, the Android engineers can’t take up the work of the iOS person who is on sick leave.
• Most of the hybrid frameworks have ready-to-use widgets and libraries for the most common functionalities like List views, VIew Pagers, Navigation components, etc.
• A hybrid framework may be a reasonable choice when you already have experts with knowledge of the framework’s language. For example, web developers from your team can be open to accept the challenge and adopt a React Native framework.

Again, these are all the pros of betting on hybrid in an MVP context. To be fair, there is also a downside. Hybrid technologies come with some inherent risks like hitting a bug not covered by the framework’s functionality crucial for the project. This calls for engineering a workaround or implementation in the native framework. All this means incurring additional expenses as well as introducing complexity in the project.

When is native appropriate

For companies that have already proven their ideas, we believe that the native iOS and Android approach is preferable. Let’s explain why.
Beyond the MVP, it’s important to achieve stability and compliance. It’s not a rare case that a product should implement some critical functionalities required by the stakeholders. These features turn out to be available only for the native apps. Regularly, some new requirements of the App Store or Google Play emerge. So your app should implement them in order to gain new users.
For the hybrid apps, the same requirements must first be implemented in the framework by the respective development community. Then you should update the framework for your project in order to take full advantage of them. This often creates more headaches. For instance, triggering a chain of updates of different libraries or refactoring a big part of the app in order to be compatible with the framework’s new version.
Note that the variety of hybrid platforms is greater than the main technologies behind Android and iOS. This suggests that the probability to find a suitable fit for your hybrid technology team is lower than to find native Android or iOS developers. Nevertheless, there are large applications like Facebook, Google Ads, and Uber that are written in hybrid technologies.
The technology landscape is quite rich. Ultimately, the CTO makes the native vs. hybrid decision after careful analysis.

Considering the alternatives

For partners who have validated their proof of concept and seek to develop a working mobile product, starting with hybrid technology like Flutter or React Native may be the right approach. With a relatively small mobile development team (where engineers can rotate), the product would be made available for both iOS and Android. However, not every capability of the former is available for the latter and vice versa. Development teams have to be aware of potential inconsistencies.
Alternatively, if the goal is to launch a digital product suitable for both desktop and mobile devices, entrepreneurs can bet on a web application with responsive design (again, Flutter can do this job). Yes, it’s not going to be native in the sense that transition between screens and browser windows may not be seamless. However, it gives the product team the chance to see how the app fares with users.