The [dis]advantages of going cross-platform

Written by Fadil Žilić, Software Developer at ABC TECH Group.

Who even codes Native anymore?

In a field as fast-moving and improving as mobile application development, there is always a new thing going around, with most everyone being convinced that it is the best way to make mobile apps. At the time of writing this article, it could be argued that the thing is Flutter, but there have been many before, starting with PhoneGap, and going through Xamarin, React Native, and quite a few others.
This brings about the question:

Who is oblivious enough to work with native when it is so obviously better to go cross-platform?

Well, since there is obviously a significant number of native apps out there, there has to be a reason why.

Pros vs Cons

There are obviously many things to consider when making any lasting decision, especially one that might impact years of future development efforts. Most of these are neatly enumerated on the plethora of lists online and would be superfluous to reiterate here, but without going into much detail, most of those lists look a little like this:

Pros

• Reduced development costs
• Code reusability
• Faster development

Cons

• Performance
• Native integration
• Feature support

There is often a two-sentence explanation for each of these that rarely says anything more than the titles themselves, so they have been omitted here. However, since these must actually matter in one way or another, let’s take a detailed look at at least some.

Writing the code

The greatest compliment given to cross-platform apps is that they are quicker and cheaper to develop compared to native solutions. These words probably sound like gold to project managers and marketing teams but are unlikely to excite developers themselves because, to an extent, they just mean that developers need to work faster.
Realistically, that is not the goal, or often the case, but the criticism seems valid: in an average development environment, there are multiple teams working on their platforms of expertise, and going cross-platform does not necessarily cut the development time in half, since the separate native teams would have probably worked concurrently. However, since there is a case to be made for code reusability, and ignoring the joke where a project manager expects nine women to be able to make a baby in one month, let’s skip the theory and take a look at some code.
After setting the projects up, let’s take a look at making a simple one-screen app in Native Android and React Native, respectively. The goal of this imaginary app will be just to list images from the local gallery, after accessing and loading them. The entire code will not be shown here, just the relevant differences across platforms.
Let’s first design a simple list on our page. Since both platforms require a single list item to be designed (and reused), we will focus on the steps to show a list of images from the phone gallery. These can be seen below as such:

From the code side of things, both have their benefits and drawbacks. Android natively requires a ListAdapter, which is normally at least 20 lines of code that look something like this:

With the data consumption being fairly straightforward:

Where listView is an XML resource such as:

On the other hand, defining a list in React Native is as simple as:

Where the entire list is consumed in a fairly straightforward manner. However, the getView function from the list view adapter does need to exist, and here it is implemented as the renderItem function:

On the other hand, accessing gallery data on either platform is a fairly straightforward affair:

While on the React Native side of things, the first glance of code makes photo importing seem even easier than the native solution, looking like this:

Realistically, they are both a single function call, with parameters just defined differently. However, this is slightly deceptive because CameraRoll is a third-party library, which at the time of this writing does not fully support scoped storage introduced by Android 10, and still requires running in legacy mode. Besides that, getting the library to work in the first place requires the user to edit 4 different files just to be able to use it:

• MainApplication.java
• android/settings.gradle
• android/app/build.gradle
• AndroidManifest.xml

This is a one-time setup but is worth mentioning that it does take time to get it up and running, on both platforms.

Taking a peek under the hood

Given that the benefits in code design can lean either way, depending on what example is chosen, let’s also take a quick look at performance. Starting up the app(s) from above and running the profiler gives us the following results on Native Android:

The application does make a significant impact on the device, partially by design because of the number of images loaded directly into the memory. Below is the look at the same timeframe, but when running the React Native version of the application.

The differences here are not really massive, with CPU usage natively being on average 12% with a 17% spike, and React running on 15% average CPU with a 40% spike during app loading. More interestingly, the RAM usage using native code averages around 125MB with a 150MB spike, while React averages 160MB with a 200MB spike.

Although these differences are not massive, it is important to note that this is in fact a single-page application, with only one list that contains around 10 images. Scaling this to any bigger use case could result in much bigger differences, which could make the experience on low-end and midrange devices subpar.

Dealing with libraries

After taking a look at some technical differences regarding the app development, and runtime, let’s swivel and take a look at one aspect that is often forgotten in many discussions and bullet points mentioned above, the final phase of SDLC. Out of the eight steps commonly associated with Software Development Life Cycle, everyone mostly focuses on the Development and Deployment parts of the process, but rarely Maintenance.
With the hope of avoiding too many hypotheticals and direct comparisons, let’s focus on what is unavoidable: any framework that is built on top of Native development is built and maintained by a group of people separate from the developers of native solutions. That, in itself, is not a bad thing but does bring significant risks in choosing any specific platform.
The unavoidable pain point of any cross-platform software development has always been up-to-date feature parity. Third-party developers have no way of being aware of the upcoming tech in Native solutions, and cannot easily prepare their codebases to support them. Updating the libraries takes time and often forces them to deprecate features, which in turn forces everyone else running those on those platforms to spend a not-insignificant amount of time to get everything up to date.
Since third party library developers, which can often be a single person, have to wait for the frameworks to be updated before they can update their code if they can even put in the effort, and since any update requires testing, it is not uncommon to have to change libraries and refactor pages of code to get everything up and running, with month-long delays to reach feature-parity with native solutions and to comply with platform requirements.

Conclusion

After spending some time with the examples above, some of you might develop strong feelings for, or against cross-platform development, however, that is very far from the goal of this exercise. If there is anything this article is meant to do, it would be to break preexisting prejudice, both against and for either approach and dissuade anyone from thinking that one size fits all.

In this choice, as with many other things in life, nothing is really black and white, and you should make your decisions only after being as well informed as you can.

Follow ABC TECH Group:

Website: www.abc-techgroup.com
LinkedIn: www.linkedin.com/company/abc-techgroup
Facebook: www.facebook.com/ABCtech2017
Twitter: https://twitter.com/ABCTECH_Group
Instagram: https://www.instagram.com/abc.softwaredev/