Understanding the compounding costs of native development

The manufacturer of every platform or operating system provides a software development kit (SDK), which contains everything necessary for someone to develop applications on that specific platform or OS. Here, we are referring to a native development process, where someone uses that SDK to develop applications for that single platform.

Cross-platform frameworks have a separate SDK, which is usually a layer on top of a native SDK.

Cross-platform solutions are becoming more and more popular; for example, as of May 2021, out of ~5 million apps on the Google Play Store, more than 200,000 are Flutter-based apps, which is not bad for fairly new technology (4-6% of all the apps published in Google Play Store).

For a more detailed look at some of Google Play's statistics, visit https://www.appventurez.com/blog/google-play-store-statistics.

If you are interested in learning a bit more about Flutter-based applications, check out https://www.youtube.com/watch?v=a553D0s7HeE&t=1779s.

To understand why there is an increasing demand for cross-platform solutions, we need to understand what issues people face with native development.

One of the reasons for the increase in demand for cross-platform solutions is developer convenience. Becoming an expert nowadays, and especially staying one, in any programming language or framework is not an easy job. While transferring concepts and general knowledge can be achieved in varying degrees, depending on the similarity between two platforms, becoming an expert in a new language still requires learning. Therefore, those people who'd like to become an all-around frontend developer with considerable expertise in Android, the web, and iOS have to learn not only three different frameworks but their primary languages as well: Swift/Obj-C, Kotlin/Java, and JavaScript. This is the case unless there is a shortcut providing passage between these worlds, which is generally covered by cross-platform technologies.

This explains the openness developers have toward using cross-platform, but it's only one part of the equation – the supply – and we still need demand for it.

There is another major reason for developers steering away from native solutions: cost.

The cost of native app development

So, why doesn't everyone want to go with a native development process? This choice is somewhat similar to buying tailored garments versus ready-made garments from clothing stores: it's cheaper.

Before we understand the costs associated with Native development, let's introduce the concept of nativeness first. Nativeness is a measure of the degree to which the quality of a product conforms with the peculiarities of a platform. For example, imagine the differences between a native English speaker and a non-native one (potentially the author of this book, who has an imperfect Hungarian accent). The differences can range from subtle to more obvious, based on the complexity of the words and the non-native speaker's skills.

Now, why would anyone give up nativeness? It's mainly because people can achieve lower costs (or at least they think they can).

To get a better picture of the cost variance between native, cross-platform, and multiplatform, we're going to examine the relationship between a feature's complexity and the development cost that's needed to bring it to life in a simplistic manner. Features can consist of multiple sub-features. So, for example, a delivery app can be thought of as an app with one delivery feature, where the complexity of this feature is the sum of all of its sub-features.

In the case of native development, since there is little to no cost reduction, the cost of development is determined as follows:

Cost of development (n) = n * FC

Here, n is the number of platforms and FC is the feature complexity, which, as we mentioned earlier, is the sum of all the sub-features that comprise a feature.

Important Note

This and the following calculations are approximations and only describe the reality simplistically. Nevertheless, they should provide you with a better picture to understand the cost differences between frameworks.

This is what costs would look like if you were developing a product on two (blue line) and three (red line) platforms, respectively, where there is no cost reduction by sharing code:

Figure 1.1 – Cost of native development as a function of feature complexity

Unfortunately, there is a little beast known as synchronization between platforms that we didn't take into account, which can significantly increase development costs, bit by bit; it's hard to plan for it, so it can be an unknown variable in calculations.

Synchronization

What is the specialty of frontend and mobile products in general? They are mostly similar, though they do have some differences. Thus, the goal of developers is to achieve consistency between platforms while paying attention to nativeness. This is a lot harder than it sounds. Why? There are a couple of reasons for this:

• People think differently.
• Platforms are different (an option that's easy to implement on iOS may not even be available to Android).
• Creating software requirements documentation that covers everything is impossible.
• Communication is costly, but no communication is costlier.

Because people think differently and are biased, communication is not easy, and platforms can drive developers toward different solutions, platform-native apps will likely have differences. As feature complexity increases, implementations will likely begin to differ more and more, causing greater and greater differences between platforms. Due to this, the costs of synchronization will compound. At some point, the development team will have to account for the differences between the implementations on the platforms as well.

Taking the synchronization costs into account, we could update our cost of development calculation as follows:

Cost of development (n) = n * FC + Sync Costs ^ FC

Here, n is the number of platforms and FC is the feature complexity.

Synchronization costs typically depend on your team's processes and its ability to communicate. The following chart provides an example of how synchronization in the native world could increase your costs significantly as feature complexity grows:

Figure 1.2 – The cost of native development with and without synchronization costs as a function of feature complexity

Here, we can see why the outlook of costs scares clients and directs them toward cross-platform solutions. But do cross-platform technologies save costs? Yes, though not in all cases and they may lure you into traps.