Native app vs cross-platform app: which factors matter?

Are you facing the decision between native app development and a hybrid development approach? Do you currently run a native mobile app for Android and iOS, but are considering switching to cross-platform technology, or vice versa? Are you wondering which technology is suitable for your use case and what risks may come with the promise of higher profitability? We will address all of these questions below and present a concrete solution proposal. This article about mobile app development gives you an overview of the important topics in advance.

Scenario: migrating a native Android and iOS app to hybrid Flutter development

To make the topic easy to understand, we use the following concrete case: you have successfully operated an Android and iOS e-commerce app natively for several years. The shopping app has the usual features (product catalog, search, shopping cart, and so on) and, apart from the camera, does not use any other hardware of the mobile device, such as Bluetooth.

Instead of having to develop and maintain separate code bases for the Android and iOS app, we now want to evaluate whether switching to a cross-platform app using Flutter - as a representative of hybrid app development frameworks - makes sense and is economically viable.

In the following, we explain that from a technical point of view Flutter is generally very well suited to gradually convert existing native apps to hybrid development as further features are developed step by step.

A hybrid approach will still not cut development effort in half, because testing on both target systems, for example, is required. Realistically, around one third of the total development time can be saved. In the short term, switching to Flutter will create some additional work because of the initial project setup and the partial migration of existing functionality, such as backend communication. In the medium to long term, however, that investment pays off.

A possible change in technology can have far-reaching consequences. We therefore recommend not making a hasty decision - our concrete solution proposal is at the end of the article.

Cross-platform app development for Android and iOS

In recent years, many different companies have increasingly jumped on the cross-platform app development bandwagon. Their goal was - instead of developing separate Android and iOS apps -

• to maintain only one codebase,
• to reach market maturity faster, and ultimately
• to save costs.

But even pioneers such as Facebook and AirBnB have switched back to native app development despite significant investments in technologies such as React Native, because the promises could not be kept. More information on the exact reasons can be found here.

Flutter - hit or miss

Google released the first version of its new cross-platform toolkit, Flutter, in December 2018. It promises to solve many well-known problems. We already collected our first impressions in early 2019 in the blog post How Flutter works under the hood and why it is game-changing.

Since then, we have developed various prototypes and products for clients with Flutter - including a logistics app used on handheld scanners to record goods in a freight chain. Flutter is still in its infancy, but it is constantly being developed and improved.

One major advantage of Flutter is the possibility of integrating it into an existing Android/iOS app, so Flutter can initially be tried experimentally for one or a few new features without major risk.

Accordingly, we recommend carrying out a detailed evaluation and risk assessment for each concrete use case before making such a fundamental technology decision.

Flutter system architecture

Flutter differs from other cross-platform frameworks such as React Native or Xamarin mainly in that it does not try to build a bridge to native UI components for reuse. Instead, every pixel on the screen is drawn itself. This gives Flutter full control over the appearance and interaction with elements such as buttons in an app. Corresponding Android- and iOS-specific UI components are already included with the Flutter SDK, so users cannot tell the difference.

This UI and its interaction are created in Flutter’s programming language Dart and can be executed within the Flutter framework on Android and iOS. Based on the framework, the underlying business logic of the app or requests to a backend system can also be implemented. These functions are therefore platform-independent as well.

Internally, the Flutter SDK uses so-called platform channels to communicate with the target system (Android/iOS) and make use of certain features, such as the camera or GPS. You can think of these platform channels as translators between the hybrid and the native world, or as the corresponding API in a client-server system. Some of these channels are implemented either by the Flutter SDK itself or by existing libraries and can be reused; others may need to be created manually.

The following diagram shows this accordingly.

How is a native e-commerce app migrated into a Flutter project?

Because the requirements for smartphone-specific hardware - such as Bluetooth communication - are low, the example shopping app is generally well suited for a hybrid development approach. Flutter in particular seems like a very good technology choice, because the existing native app for Android and iOS can continue to be used exactly as it is, without requiring a fundamental reimplementation.

For implementation, a new Flutter project is created as the starting point. The existing native code of the apps is integrated as an Android/iOS service. When the app starts, the almost empty Flutter project runs first and directly uses the platform channel to launch the app corresponding to the current operating system. Implementing a platform channel must happen on all three sides - Android, Flutter, and iOS. Both original app variants are now united in one project, and new functionality can either be implemented in Flutter or continue to be implemented natively - a key advantage over other hybrid frameworks. It is also possible to integrate web elements, such as checkout from the shop system, without any problems.

It is important to note that this adjustment alone already requires changes to the release process, meaning the creation of the final app artifacts for publication in the respective app stores. The CI/CD pipeline in particular - the automated assurance of code quality through code analysis, tests, and app artifact generation - has to be adapted, just like the app signing. Compatibility checks must be carried out to ensure that users can update from the current native app to the new Flutter-based app without problems.

Flutter’s strength lies in its integration with existing Android/iOS code and its planned extensibility with regard to new subpages or even entire areas and functions of an app. From the earlier explanation of Flutter’s system architecture, it should be clear that Flutter is not suitable for merely modifying isolated design elements - for example buttons or text fields - on a natively implemented page. This is because Flutter draws its UI components itself and uses the entire screen as its canvas. Accordingly, these changes must either continue to be implemented natively, or the entire page must be migrated to Flutter.

Once the complete UI of a page has been implemented in Flutter, the business logic of the previous native implementation can be called and reused via a platform channel. In the long term, however, this part should also be gradually moved into Flutter in order to benefit from the hybrid development approach. The appealing thing is that the amount of work can be weighed and implemented according to the functionality involved.

But how do you decide whether switching from native development to Flutter makes sense?

Proposed solution: evaluation project for cost-risk trade-off

Since a native implementation always offers the greatest flexibility and a technology switch can have far-reaching consequences, we recommend not making a hasty decision, but instead weighing the possible risk against the costs.

If the current native implementation is in good shape, meaning the apps run stably, customer satisfaction is high, and no major overhaul of legacy code is needed, we recommend first focusing purely on the potential savings on the cost side.

Potential cost savings of hybrid development

As mentioned at the beginning, development costs will not be cut in half through a hybrid approach; rather, around one third of the costs can be saved in the medium term. It is also important to note that a pure app facelift - in which certain pages are adapted - is not a good use case for switching to Flutter. Instead, you should only take into account the effort for new feature development in your calculation.

Even though the initial costs of switching an app are highly project-specific, we assume below that these costs are amortized within the scope of a feature development effort of 100 person-days. In other words, a feature that would require 100 person-days of native development can also be delivered in 100 person-days with Flutter, including an initial introduction of the technology into the project.

If only 150 to 200 person-days per year are needed for new feature development, the savings potential would be around 50 person-days. In that case, we would rather advise against a technology change, because the uncertainty and possible risks do not justify the cost savings and native development keeps all options open.

If the annual development effort for the native Android and iOS apps is significantly above this 200-person-day threshold, it is worth looking at the issue in more depth from an economic point of view.

Technical evaluation and risk assessment

With every new technology, you also potentially bring a new risk into the house. Accordingly, a technical evaluation is essential before making such a far-reaching decision. The devil is usually in the details, and every app is highly individual, so in most cases no blanket decision can be made.

That is why, for customers facing such a decision, we suggest combining their existing apps in a Flutter evaluation project limited to ten person-days and implementing one exemplary hybrid feature. On that basis, technical feasibility, the resulting Android and iOS apps, and the necessary adjustments to existing processes (from design to release) can be assessed, and a fact-based decision for the future can be made.

If the evaluation is positive, those initial steps toward switching development to Flutter have already paid off. If the evaluation shows that a hybrid approach is not effective, that decision can be backed by facts and used as a basis for arguments in budget discussions.

Since the first versions of Android and iOS devices, we have been developing apps for these platforms and are specialists in this field. We are also happy to help you and your team make the right technology decision. Feel free to arrange a free consultation appointment with us and let us tackle your evaluation project together.