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.
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
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.
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:
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.
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:
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:
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.