Over the years, many articles have been written about app development paradigms, and the importance of well crafted APIs. These topics tend to generate some rather interesting discussions, riddled with things like "DOM will always be slower", "Web apps will take over", "APIs are more important" etc. In the heat of the moment we sometimes forget that at the end of the day there needs to be a balance between user experience and cost.

Ideally we all want to create apps that provide a "crisp" and "snappy" user interface, with equally "crisp" and "snappy" data. After all, what good is a speedy graphical interface when the user is forced to look at a spinner more often than not? Even though the spinner can do somersaults in Native code.

With that in mind let's first visit the three approaches of app development and set aside the API that powers its data for the moment.

The Usual Suspects

The three most popular app development paradigms of Native, Web, and Hybrid are commonly cited. The Native approach involves the use of native tools, and workflows to develop an app. For iOS this means Xcode and Objective-C, for Android, it's time to fire up Android Studio (or if you still prefer Eclipse, you should really consider switching) and write some Java code. For Windows it's Visual Studio and C#. Once the app has been developed and properly QA'd it is published to the platform specific app store. Users would then download/install the app, and start using it.

On the other hand, Web, or let's say pure Web apps, are developed with a Web development stack, which at its core consists of HTML5, CSS/3, and JavaScript. Users need not download/install the app, rather they would simply point their mobile browser to a website, not unlike their desktop, but optimized for mobile. There are too many web development frameworks to name, but they all implement some form of MVC (Model View Controller) which involve a model to manage the data, a view with a template to render it, and some routing mechanism to handle URI entry points as controller.

Finally there is the Hybrid approach. Like Native, the app includes pure native code, but in addition it contains Web code in the form of HTML5/CSS/JavaScript. The Web part is made possible thanks to a special object known as a "WebView" which is available on all platforms, and it can be thought of as an embedded web browser. The app is still published to the platform specific app store, and the user goes through an install before launching the app.

So why would you choose one approach over another? The decision comes down to app capabilities, developer skills, time to market, budget, and long term strategy.

For example if you need to build the capability to capture a cheque or a receipt as an image using the smartphone's camera, then you need Native or Hybrid. Without getting into too much technical detail, we can simply say it's really about striking a balance between user experience and cost. Developing a native app for each platform requires platform specific skills. Instead of having one team to develop an app, you'll need two or more teams depending on the number of platforms you're targeting, this naturally drives up cost. Which might be OK if it can be justified in terms of user experience, and up take.

In practise more and more apps are being developed using the Hybrid approach. Some parts of the app are purely written in native code while others are handled through web code executing in a WebView with some sort of bridging technology to exchange state with the native portion. With this approach you can get that extra 60fps performance in scrolling list views, while still maintaining a decent set of capabilities using web code. There is also the decision of whether to support a platform at all, or perhaps a limited version of it? If iOS and Android cover 90% of the target audience then maybe a Web approach with limited capabilities for Windows and BlackBerry is enough.

A Thought or Two

I'm willing to go out on a limb here and say Hybrid is a great approach since it combines the best of both worlds, namely Native and Web, but with the caveat that there needs to be a healthy dose of each.

Keep in mind that releasing an app is just the beginning of the journey. Like all written code/software, more requirements undoubtedly make their way back through various channels, eg. user feedback or competitive pressure to innovate, which translates into more features and enhancements.

The more code written in web the less you need native platform teams to maintain it. So, changing an existing feature which might have been implemented part web and part native, the part web portion is the common denominator, and will cost less. On the other hand maybe the feature enhancement is not possible any more using web code given the new performance requirements, so it's time to make it native. The other way around is also possible, again it depends on the user experience / cost balance, i.e. a feature might have initially been written in Native code, but later discovered that it can be ported to Web code while still maintaining the user experience.

In Part 2, we'll take a look at the other side of the equation, APIs.

For more information, please visit: OMNI-MaaS.