Hybrid app development is a godsend for Startups, but should you take that route?

If you were to look at the current market distribution when it comes to mobile operating systems, there are only two main players on the field: Android and iOS. The market share of all the remaining mobile operating systems put together is less than 1% of the total. That would seem to be good for an indie mobile app developer. There are only 2 platforms to target. But therein lies the problem.

Development for Android and iOS themselves have a drastically different ecosystem. On the Android-side, you will have to work on Android Studio and code in Java or Kotlin. On the iOS-side, you will have to work on XCode and code in Objective C or Swift. To add fuel to the fire, XCode is only available in Mac OSX. That means that if you have a Windows or Linux computer, you simply cannot even develop apps for iOS, let alone publish it in the App Store.

Here is the good news. Many developers have actually looked at this problem and have come up with a solution: Hybrid app development. Hybrid app development is basically you developing an app by writing a single code base in a different programming language, which is either converted to the native languages of each of the platforms or made to run on these different platforms by having a middleware layer that interacts with the native APIs.

This is great since you no longer have to maintain 2 separate code bases for Android and iOS. Any changes you make in the codebase would be affecting both the platforms. And of course, you could have some piece of code that is included for only one of the platforms and not for the other. Examples of some of the frameworks that provide Hybrid app development are Ionic, Flutter, Xamarin, React Native

Having said all this, what do I think is the best route to go? Here are 3 points that I want to discuss, covering different aspects of these 2 options:

Why are Hybrid apps a godsend for Startups?

Most startups usually start with a limited amount of resources: whether it may be money or people. Even if the startup is not related to technology, there is a high chance that it requires a mobile app and a website. If startups were to go the native route, they would have to invest in 3 teams of resources – 1 for Android, 1 for iOS and 1 for the Web. This is however not a feasible thing to do in a company that just barely started and isn’t certain of its path. If in a few months the company had to take a different path on what type of company they are, and what type of services they want to provide, it will be mind-boggling to try to update the apps on all the 3 platforms.

Now, what happens if they decided to go through the hybrid app route? They would really need only one resource. Someone who knows how to develop apps on that framework. Many of these frameworks have out-of-the-box support for the Web (as they are usually written in HTML, CSS, and JS after all), making it super easy to work on 3 platforms at the same time. After a few months, if the company decides to take a change of course in their purpose, they can very well just update the single code base that they have, and update the apps on all the 3 platforms.

The point that I want to emphasize here is efficiency and flexibility. Less is at stake when you take the Hybrid app route.

When does Native app development make sense then?

The first app that I ever developed was a native app. It was the GirdThySword app that I and a couple of other guys teamed up to work on and then published to the Play Store. It is no longer in the Play Store cause I forgot to take the target audience questionnaire which needs to be updated every year. I still can take it back up, but since it was just a prototype anyways from which we learned app development, and it wasn’t that well built, I decided not to republish it. The second app that I built (which is a native app as well) which is GirdThySword Pro is available on the Play Store and can be downloaded for free.

The main thing that I learned while developing for Android was that I only had to target a specific group of people. People who had an Android phone. Any feature or functionality that I implemented is natively supported by Android itself as I am not relying on a third-party middleware to interact with the native APIs for me. I am the one who writes code to interact with the native APIs. And to be honest, the apps themselves were way faster since there wasn’t a web view that was rendering the UI but the native UI engine itself.

Also, any app that requires a lot of raw performance (say a video player app), would run better natively than in a web view. Also, some of the advanced features such as Picture-in-Picture where the video is even displayed after you close the app as a minimized tile is only possible in natively run apps.

So when it comes to performance and advanced features, Native apps score. When you want to go all in, native is the way to go.

At the end of the day, which is better?

It depends on the use case. If you want to build something which would intensely use some of the audio and video functionalities of the mobile device, then maybe you should take the Native route. If you just want to build an application that works best on the web, but also work as a mobile app, with minimal audio/video processing, then I would say take the Hybrid app route. That being said, hybrid app development is such an amazing option now, which I would definitely take if I were to work on a project today.

Until next time!

Processing…
Success! You're on the list.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.