Native vs Hybrid Mobile App Development

To be or not to be?

One of the questions most organizations struggle with is whether or not to build their Mobile Applications in native or not? Let's first analyze what is native.

So, what is Native?

Each Mobile OS provides a standard set of interfaces to create applications in their ecosystem. Eg: iOS provides UIKit.framework that provides classes like UIButton to create a button in the Mobile Application. The concept has been around for almost ever as people have been building Windows Applications for decades. 

In the past you might have heard native applications to be referred as thick clients and the comparison used to be in within thick vs thin clients.

Ok, what is the thin client now?

A thin client is an application that has majority or all of its functionality residing on some remote server. The most preferred location of the server being World Wide Web (www.domain.com). So, in the old days you can totally think of business evaluating whether or not to ask the users to install the exe (app) on their windows machine or simply expect them to type the url in the web address. 

So, if not native then what choice do businesses have? What's the competition?

Hybrid is the competition and you would hear about it a lot as organizations dwell to create new sales or service opportunities for their business. 

What's Hybrid?

Hybrid is basically Ferrari body running a Toyota Corolla Engine inside. That may be harsh but more or less this is the reality. Hybrid means that you will have an actual native app - an application that users can download from the App Store (iTunes, Google Play, Microsoft Store etc) but internally for some of the functions these native apps won't have native code but will be displaying the Mobile Web (HTML, Javascript) pages in the app or custom tab using the WebView or custom tab capability of the app.

Why would organizations pick hybrid? Considering hybrid exists it must have a use case considering implicit preference of organizations?

There are a bunch of arguments and i will list them but i believe the crux of the never ending hybrid pursuit is the software ideology of write once and use anywhere. Java did made lives simple for all of us when it came with write once and run anywhere solution with Java Virtual machine. So, ideally we would want to write the Mobile application once and have it run the same on any device, why should it matter whether i am running on iPhone vs Pixel when it doesn't matters when my application runs Pixel vs Samsung vs LG vs HTC and so on.

Sounds good, what's the hinderance...

The native applications are compiled into binaries that can be understood by the native Operating Systems. So, either iOS would have to start understanding dex or Android needs to start understanding .app, which either platform - iOS or Android has no incentive to do. One of the obvious reasons is performance as anything the native OS will add to understand a binary compiled for alternate operating systems ecosystem will result in a virtual machines presence on the device that will slow down the performance of the app, which would be un-desirable. Eg: Consider this, if a third party seller provides you a slow shipment on Amazon then doesn't it leaves a bad taste in your mouth? Ideally you knew the order is not being serviced by Amazon.

Can major OS companies do something to solve the problem?

Of course they can, incentives may not be aligned though. The biggest step was recently taken by Apple when they open sourced swift. Theoretically, Android could have used the signal to provide swift-core library and allow for swift adoption on Android devices. But that never happened, the reasons could be hidden in multiple layers of technology strategy discussions that are beyond the scope of this article. Also, Android recently adopted Kotlin as a fully supported language, which means the likelihood of Android supporting a third language may be bleak.

Circling back - what are the benefits of hybrid? Let's list some arguments

• Write once run anywhere dream that is discussed above
• Have the business logic written once
• Speed to market

Let's evaluate the claims

Basically the claims boil down to Costs of development (write once) and maintenance (concentrated business logic). I believe the arguments are weak and here is why:

• Write Once - There is no real write once. Yes, the business logic can be concentrated in a commonly written Javascript but for UI most of the write once use anywhere components end up with if else conditions based on OS, so there is additional work happening to support different OS. If your company have Mobile Web site then it is your Mobile web team doing it. There are other solutions like React Native available in the industry where a third party like Facebook is taking care of the if else conditions for you. 

• Performance - The hybrid functions will not be able to match the native OS on performance terms. People can try and beat around the bush but it is what it is. The easiest comparison being for any native app, launch the native app vs open the website in Safari/Chrome and you will see the difference. Also, if you think that customers don't value performance then you may want to re-access your metrics collection system. One example that always ring in my mind is "Toys R Us". Whenever my son demanded a new toy the first service to look the toy at was Toys R Us. But Toys R Us didn't had a native app (it had hybrid app on Android). The performance was so bad and features so restrictive that i almost always ended by jumping to Amazon and purchasing the toy. Quiet interestingly, Toys r us didn't had a native iOS App. I think they assumed there customer base (parents) have lots of free time at hand instead of less.

• Cost Of Development - The write once model seems nice because it is auto assumed that it means that we will require 1x the effort instead of 2x effort (say 1x for iOS and 1x for Android). Turns out it is not so, most of the folks end up with 1.5x times the effort as it is more effort to support multiple OS and you still need to test on all OS).

• Usability - If i live in US i am used to driving on the right side of the road and if i live in England then i am used to driving on the left side of the road. Basically, my intuitions work based on the ecosystem i have been trained on. The iOS users are used to iOS ecosystem and Android users are used to Android ecosystem i.e. the users expect the controls to be available and function as defined natively by their ecosystem. And all the write once UI means you are actually hosting a Mobile Web UI that is not intuitive for the OS and hence customers will end up with usability issues.

• Maintenance - Now let's look at the business logic concentrated in a common place logic. Of course, the business logic needs to be concentrated in a single location to avoid bugs but that locations needs to be on server side (a service) and not the client. So, only place where the argument makes sense is where the client has no server components which could be true for a small developer trying to do everything locally on the client but for most useful apps the argument carries no weight as those have a server component and the business logic needs to be moved to the server and not left on the client.

• Peripheral Support - If your app needs peripheral support like Camera, Face Id, Touch ID/Finger ID, Audio In then it only makes sense to use native app development. Trying to use WebViews for Peripheral Support would result in teams burning lot of hours un-surfacing issues one after another and more than likely consume more time than less.

• Speed to Market - Speed to market claim stands at i will spend 1.5x instead of 2x upfront and try to achieve the following:
• We want to be the first to market - That argument doesn't makes sense as i am spending 1.5x the effort instead of 1x per platform. The two platforms could have been developed in parallel so if i would go native then i can theoretically be faster (or at least enter at the same time as hybrid based on the resources used).
• Evaluate Customer Adoption - If we want to bring in new customer, wonder if it is a good idea to put our best foot forward (native) or provide them an average experience and hope adoption occurs.
• Keep costs low to support organic growth - There are few catches here as well. If we are looking for organic growth then we don't need to go big bang in like most organizations do, we should roll the features most desired by customer and evaluate if there is adoption. If customers adopt then we add features. Also, If customers adopt then we are not trying to re-write the hybrid features to native again.

That seems like a long list of native pros then why the ongoing argument for Hybrid?

There are always more forces under play then what we see. I will try and list my take on those forces:

• Agency Problem - Agency problem is basically people running their own agenda instead of organizations agenda. So, if you already have a Online website then their skillset is already Javascript/HTML development and not native then for them hybrid makes the most sense to implement considering the organizations skillset. Also, this is the organization most likely to be called upon by executives when they are planning to kick off venture into native app development. 

• Talent Pool - When your organizations skill is web development then your organization needs to ramp up and now identify and hire these skilled native app developers and firms may find this challenging. To be fair, finding and hiring good developers is always challenging no matter which organization you belong to but then there is no alternative to hiring good developers. 

• Artificial Complexities - All native OS providers put in significant effort to ensure App Development is easy so as to attract large number of developers. This is true you adhere to simple guidelines provided but the OS providers like Standard OS Controls. Most big organizations kind of deviate from usage of standard controls and keep trying to come up with custom controls in the name of usability studies (how come it is more user friendly not to build UI to the OS standards that the customer is used to using on a daily basis). These custom controls now consume a lot more time to develop as native OS don't really support them and they keep breaking with each new OS release resulting in higher maintenance cost. For such firms that believe usage of custom controls result in better return on investment or more customer affinity (both arguable) the hybrid approach doesn't makes any sense at all as they are already draining money in creation of custom controls then why not give the customer better performance as well.

Where to learn Native Development?

If you are interested in learning native Swift and iOS Development then the below youtube channel would let you learn at your pace.

http://bit.ly/iOSLearning

Do look at the description of the videos as they have links to download the playgrounds so you can practice coding.