Choosing Between Native and Hybrid Language

The journey of computer languages have gone too far to the point that two AI robots have to be shut down because they made up a non-human-understandable language. We can conclude from this that the robots are taking over everything in the vein of an Asimov nightmare.

However, for the time being, developers will have to use computer languages to bridge communication between man and machine. That is, before technological singularity launch nuclear missiles all over the world’s major cities. This shit is real, people.

Computer languages come in many shapes and forms, serving slightly different purposes. Hybrid and native languages are, of course, no different. Clients often ask whether it’s better to work with native or hybrid languages. Our answer is always the same: it depends.

There are many factors at play for your company to make the best possible decision on whether to use React Native or Java or Swift. Every single one of these languages have their pros and cons. The secret is to know which language to use that align best with your business goals.

So let us help you. There are already hundreds of articles out there, but we will look at it in terms of the business. The choice of going one way or the other may make or break your empire.

The Return of the Native

For a long time, applications are written in native code. Actually, it has been messier than that for a long time. Software developers come up with their own devices, using proprietary languages. We can’t blame them. Manufacturers bank that their device will be widely adopted, hoping to the moon that their product becomes a platform. It follows that the languages that they created will then be adopted.

However, this makes the choice a lot easier. Back then, if you want to launch rockets, you'd use FORTRAN. At least back in the 50s. If you want to develop for Windows, you'd use BASIC. Native language was the only way to go.

However, languages come and go as easily as jeggings and piano neckties back in the ’80s. Languages become redundant rather quickly as technology moves at breakneck speed. Some platforms, despite all challenges, catch on like wildfire.

Enter iOS and Android.

The growth of both platforms during a time when smartphones are fast replacing the old iPods, coupled with the ability to do everything with a device smaller than a chocolate bar, and the fact that Silicon Valley is soon swimming in investor money, means that the end user is spoiled for choice. In a running economy, this is definitely great. For developers, the headache is yet to come.

In the early days, startups will have to focus on shifting their resources into a single platform: a choice between iOS and Android. Thus they have to develop in the platform’s native languages: Java for Android; Swift or Objective-C for iOS.

Then developers start to think: isn’t it easier to just write a single code for both platforms?

Hybrid: The Savior or the Villain?

The truth is, hybrid languages have been around even before smartphones infiltrated our lives. JavaScript, HTML and CSS all serve different platforms for years.

For some developers, coding in hybrid makes perfect sense. Hybrid is far more cost effective and saves a ridiculous amount of time, not to mention the difference of resources required. We will address this later as we examine what sort of language your business will choose.

Hybrid languages for mobile apps are still quite new. Thus, there is some stigma that follows due to its novelty. Yet, the criticism that comes with them are mostly justified. Let’s take a brief look.

Hybrid Languages Perform Poorly

In comparison to native languages, hybrid languages have their limitations. The general consensus is the performance.

We cannot hide the fact that hybrid languages in mobile apps are a set of HTML, CSS and JS native wrappers on the device. This leads to higher server request and load balance request. As a result, performance inevitably suffer.

However, this depends on the size of the application and the potential concurrent users. You may not be building an application which will have fifteen features built-in. An app with a singular purpose do perfectly well in hybrid.

At a certain critical mass, you may want to consider moving the app back to native. Facebook decided to make such a move after years in React Native. Funnily enough, it was Facebook who came up with React Native. The app is just simply too complex and too big. Nevertheless, they’ve done well.

The quality of the coding matters. Good programmers will be able to mitigate the weaknesses of the application by structuring the app correctly in the first place, making sure the architecture in place can support the users’ needs and potential traffic.

Hybrid Languages Are Difficult to Debug

Like we mentioned, hybrid languages are relatively new. For example, React Native is still evolving, with new updates monthly to fix the inherent bugs. On a positive note, with every update, React Native is getting better and better.

However, from a user’s perspective, the app may crash more often than expected, loading may suffer from slowness, and the UI may not fit as expected compared to an app developed in native language. Great developers may find the time to find a run-around, but the bugs are there.

New Features in Hybrid Take Longer to Develop

Hybrid Languages are great to create an app which may be moderate in size. However, as the app itself scales up, it becomes more and more clunky to develop new features.

Some experts staunchly argue against developing in hybrid, opting every time for native. At the end of the day, performance is king, because the user is king. Hybrid languages are still a fair distance away to keep up with its native counterpart. A poorly performing app kills the user experience and the app will be promptly punished via deletion.

Having said that, there are situations when developing in hybrid makes sense, or native is just the plain answer. In the next section, we will discuss what you should consider before jumping to a decision of what language is better than the other.

Once again, it depends

Where you are in the business, your team, your client requirements, the weather outside should all matter. A word of warning: this decision will be a key factor in developing your app; it will be difficult to backtrack from native to hybrid, and vice versa. Treat this decision as though Ctrl + Z is missing. The cost of rewriting your app may be at best, an arm and a leg. At worst, your head.

Ask yourself these:

Where Are You in the Business?

And how fast do you want to grow? Many startups nowadays opt for hybrid option as they want to iterate quickly and publish quickly. They are not necessarily taking a shortcut, but it may have to do with their ambitions and trends in the app they’re building. Possibly, there are competitors developing a similar product, thus going hybrid is the most sane choice to seize the first-mover advantage.

What resources do you have in your bag?

And how good are they? You may have endless amounts of developers under your wing, but they may not be the answer. Fast growth usually means fast hiring, and this is not without its own risks. However, it is important to find the right balance.

Don’t forget: time is also a finite resource. If you have an endless resource of good developers, but not much time, then you'll still run into issues.

By experience, finding developers who are more than capable of writing hybrid code is as hard as catching salmon from a waterfall, especially in a developing economy.

Yet, they do exist and you have to make sure they have all the systems in place so they can kick ass.

What Are You Developing?

Are you a startup with a solid core idea? Then maybe you are focusing on developing an MVP, with only core functions. Everything else comes later. If that’s the case then, a hybrid language is ideal for fast deployment. If your app is complex with inter-related features, then maybe you should consider writing in native code.

In general, content driven features can use hybrid language as its platform. Apps such as newspapers, blogs, simple task planners and catalogs may use hybrid code without batting an eyelid. More complex apps such as games, fitness apps, and chat apps usually use native code.

Conclusion

The debate for hybrid versus native code will go on endlessly. Then again, this debate is healthy and examines the core of technology, not only as a platform, but as a business asset. There are bigger things taking place more than tech itself.

Ask yourself the questions above before plunging into a choice, because it does matter. We have developed appls in React Native when the client team is small and they wanted only core features. We have developed complex loyalty apps using native, building it in Swift and Kotlin. The decisions we have made impact the future of the app.

As I said, ask yourself these questions. As binary and simple the choices may be, this choice may be a deciding factor whether your business fails or succeeds. Whatever you do, choose wisely.

Further Reading

As we said, many developers support one or the other. So we’ve made it easier for you. We separated the articles that support each, and debunked both.