Back

TechnologyMay 19, 2014

Native Applications Are Better Than a Cross-Platform Framework, Right? Not So Fast

Jeff English

Cross-platform frameworks are a viable solution for many applications. The use of these frameworks can provide many benefits throughout the entire application lifecycle.  These frameworks do not provide 100% compatibility across all of the platforms, but the concept of write-once, adapt-many has tremendous value. Understand that a cross-platform framework can provide the benefit of:

–  Improving the architecture with well-defined layers

–  Leveraging the optimizations made by knowledgeable platform engineers

–  Focusing on improving performance only where needed

–  Allowing code to run on multiple platforms with incremental effort

–  Optimizing the application lifecycle across multiple platforms

Often times the resistance to using a cross-platform framework is based on past experiences or platform purity dogma. Examples of how an application written using a cross-platform framework performed poorly compared to the same application written natively are often cited as reasons not to use a framework. However, there are many more examples where the results were just the opposite. It is possible to write poorly performing code regardless of the approach, but also possible to write well-performing code. Whether writing native code or using a framework, it is always important to understand how the layer below works so you can architect and code in a way that is optimized for that layer.

Statements like, “A native application will perform much better than any cross-platform framework,” or “The application won’t perform well because you’re adding a layer to the code,” do not consider the full picture.  Those statements are based on several fallacies related to application architecture and design for cross-platform product development.

fallacy #1: adding layers is bad

The argument here is that any time you add a layer to the architecture you are slowing down the application. Intuitively that may make sense since it sounds like more code has to execute, but in practice that is rarely the case. Layers are a sound architectural practice that provides robustness and increased productivity to an application through proper abstractions and functionality that is optimized for a particular task or set of tasks.

fallacy #2: native code is always faster

If all of your developers understood every API and were well schooled in architecture, design patterns, best practices, memory management techniques, etc., then given enough time it would be possible to write native code that outperforms most frameworks. The task is made even more difficult when you introduce the need to do that on multiple platforms with the same functionality and results. Even then, the most seasoned developers can produce code that is not optimal for a particular application environment.

A framework is not a panacea for all situations since it is designed and optimized with certain assumptions and constraints regarding the majority of applications that will be built using it. However, one of the benefits of using a cross-platform framework is that many of the nuances of the platforms have been analyzed and implemented in the framework to provide the most common functionality in the most optimal way possible.

fallacy #3: all code must be as fast as possible

It sounds reasonable to say that if all code is made to run as fast as possible it will produce an application that is as fast as possible. While code efficiency should always be considered, having faster code does not always deliver an application experience that is faster than it otherwise would be. It is perfectly acceptable for an infrequent operation to take an extra fraction of a second to execute if the user would never notice the perceived impact. Adding three hundredths of a second to an operation that has to go through a layer in most cases makes no difference since a user would never perceive it.

The emphasis in most applications is to create a user experience that is perceived to be very fast and responsive. In general, the idea is to optimize where the impact on performance will have an effect on the perceived performance of the application. Unless an operation is going to be repeated numerous times, squeezing out a few extra milliseconds will most likely not have an impact.

fallacy #4: porting code to another platform is straightforward

One development approach often used is to identify the primary platform the application will be launched on and then write the code for that platform. The thinking is once that is done the code will be ported to the other platform(s).

There are a couple of problems with that approach:

  1. Most likely the native programming language for each of the secondary platforms is different than the primary platform and therefore it will be necessary to rewrite the code and maintain multiple code bases going forward.

  2. Differences in the user interface make it necessary to write user interface code specific to each platform.

While a cross-platform framework won’t eliminate all of the porting issues, it can greatly reduce the amount of work that has to be done.

fallacy #5: performance is the most critical factor for my application

Even if your application has time-critical performance requirements, performance is only one of the factors that should influence the decision to use a cross-platform framework or develop a native application.  Questions like the following need to be considered:

–  Is the code maintainable and readable?

–  How much effort is needed to port the code to other platforms?

–  Does your team have the expertise to code on all of the platforms?

–  How much code can be reused across each platform implementation?

–  Can you afford the time to figure out the differences across all of the platforms so you can create a common experience for the user?

Performance is certainly a critical part of any application, but many other components should factor into the strategic architectural approach. Additionally, sometimes the native API can be rather verbose or require multiple steps in order to get it to do what you need it to do. Each of these required steps is an opportunity to introduce an error in the code or slow down the developer. Most cross-platform frameworks will provide abstractions that can greatly simplify the coding required for even a single platform.

summary

Focusing solely on the performance of an API or infrequently executed code misses the mark.  Whether you choose a framework or go native, it is vital to understand how the layers work together and how to use them in an optimal manner for your needs. In many cases, the overall business benefit of using a framework can pay dividends for your product.