Development Series: Hybrid vs. Native app

Development Series: Hybrid vs. Native app

Hi! We're back with the development series. This time we felt the need to give answer to a question that we’ve encountered from our clients: the hybrid vs. native discussion. Let's say your company wants an app. Before creating one there's this 'dilemma' to sort out. It's like you have to deal with that little angel on one shoulder and that sneaky devil on the other, which raise the question about what kind of app best fits for your company and how to build it. In other words, what technology to use?We want to make this choice a little easier for our clients and those who are thinking of creating an app to give more insight into our developing process. This study arises from a healthy interest to make our work better and not only be fixated on our way of mobile development. Our developers at aFrogleap are part software engineers, part scientists, and because of that we should be completely honest and admit that we are not always familiar with all the technologies. How can we be honest while not giving it a try? We’d like to take you on a journey into our exploration of two of the technologies, Xamarin and React.JS and React Native.

We will take you through a sequence of blogs in which we outline the pro’s and cons. The question that we basically want to examine is: Why would you go for what and when? But before we go there, we have a healthy dose of biases that we are going to share. In this article we will briefly show the difference between the options for a web vs. web app vs. hybrid vs. native app.

development series hybrid vs. native

Our bias

In mobile app development we are, of course, talking about technologies that aid in maintenance of cross-platform code sharing such as Xamarin, Phonegap, Cordova, Appcelerator, Ionic, React.JS and Native. There are probably many more obscure technologies out there that we haven't listed. The idea of these technologies is usually the same: functioning as a proxy that compiles many different apps from one codebase.

technologies

We have experience in the development of rich websites and are fluent when it comes to responsiveness and heavy Java scripts. So Phonegap and alike (that is used for building web apps) are quite straightforward for us, even too straightforward perhaps. The way we develop mobile apps at aFrogleap is by means of custom native development. However, there are other ways for mobile app development, which we like to investigate in this series.

Miscellaneous notes

But first, let’s define some terms that we will be using a few times and briefly explain what we mean when using those terms.

Let’s start with mobile websites.

From our point of view there are three different ways of mobile development. The most simple version is obviously a mobile website. This is basically a website that is or isn’t optimized for mobile display. This type is called responsive and simply makes sure that the elements that were originally designed for a desktop (think large monitor and loads of space) are a bit better organized for mobile display (think smaller screen and less space).

It should be made clear that no matter how mobile friendly this website is, it’s not really an app - i.e. you are not downloading the app from the Appstore; you are merely viewing a website in your browser.

devices - desktop vs. responsive

What it means to be hybrid.

Secondly, we have the hybrid app. Hybrid apps are basically web apps hidden behind a native app shell. This app is usually built with the help of Cordova or Phonegap. The programming is done just like a mobile website. If you want to use mobile functionality, such as the camera feature, the hybrid part comes in. Using the platform provided by the hybrid system, you are able to use the functionality of the phone. This can be things like the camera, using the system to store information, using the sensors like the gyroscope, or simply making a phone call.

The way that this works, is that when you’re pressing a button to send a photograph, the browser on your mobile is calling a javascript method that calls the Phonegap functionality, that calls the platform SDK, that calls the actual native camera.

[Information flow = HTML+CSS+JS > JAR > SDK > NATIVE]

Native app development.

Last but not least, native apps are smartphone and tablet applications developed precisely for a specific mobile operating system. In the native approach the programming is done on the SDK that is provided by the platform vendor (Android, iOS, or Windows). When you require the mobile functionality like a GPS location provider, you can directly access it by using the SDK.

The way that this differs from the hybrid click, is that there is no web-browser on the user-end. The user-end for the hybrid is usually a slower javascript part and thus feels unnatural to the end-user.

[Information flow =  JAVA > SDK > NATIVE]

About that native... A lot of engineers like to tease Android engineers when talking about native functionality and ask them what the “N” in NDK stands for. Obviously it stands for Native (as in Native Development Kit), while SDK stands for Software Development Kit; so if you’re writing your code using the SDK, then how can you call it Native? Well, Native as in “Native to the platform”. So we’re talking about using the vision of the platform through the SDK’s functionality. We’re talking camera functionality using the SDK’s interfaces. We’re talking about functionality that is provided by the Play services integration. etc...

Why would you go for what and when.

So, this is the main question that we aim to answer in this study. Because when it comes to creating an app, our clients want to know: How to create it. Firstly, the most obvious solution is to make a website that does the same thing as your app would do. If you type in the url for your website (www.yourawesomewebsite.com) we can pretend it’s an app. As far as the hybrid vs. native discussion concerns, our techies think that they could make the mobile website act more or less the same as an app, but they would have to spend a lot of time into mimicking everything that an app does. This 'mimicking time' is costly and something you would only spend if you would be trying to prove something instead of actually making a product that users like to use.

Our UX experts here at aFrogleap can’t stress enough that the experience a user has on a mobile website can become so frustrating to the point that the user will just not use your product or service. They describe the “snappiness” that native apps have that mobile websites and hybrid apps just don’t have. On top of that, it cannot use the full set of features of a smartphone. End users expect certain components to feel a certain way. For example, they expect the menu to slide in and out within 80 milliseconds. When this is not the case you have them doubting their own sanity, and that is probably not what you want. Your product should be simple and user friendly.

In the coming articles we will zoom in on the functionality of native technologies such as Xamarin and React. Xamarin has what we call a shared codebase. It means that the source code can compile (or metaphorically bake) an Android app, an iOS app, and a Windows app. Normally, you would have three separate codebases for each platform. A cross-platform codebase seems like a no-brainer, right? In what world would this not be a good idea? Stay tuned and learn which of the technologies will do the best job in developing your app and giving the best experience for the user.