Web vs. native?

I've recently read PPK's article titled "Web vs. native: let’s concede defeat". I've also seen countless "web vs. native" debates in forms of either presentations or articles. Some of them claiming native is a sure winner, some that web is superior... I want to show how fruitless the debate really is and how you – as a developer – should decide (or help your boss decide).

The war of web vs. apps

A web developer will tell you that there are changes that make the web stronger (like API to get user location and such), but web is already strong by being the most common thing on Earth. But any iPhone programmer will tell you that there is no easier way to build apps than with Xcode, as will Windows Phone dev say for Visual Studio, as will Android developers say for Eclipse or Netbeans, as will Blackberry developers say for Momentics IDE... And with time many of them will say their main programming language (be it JavaScript, Objective C, C#, Java or C++) is great to code in.

Do you see what I'm getting at? I might surprise you, because I think they are all right. In a way. Eventually you can learn to live with specifics and restrictions of any platform (be it language disabilities, tools failing and what not). If you can have a specialist for all those platforms then go ahead and build purely native apps and a separate website. You will probably make some common API that incorporates most of the logic and develop all GUI in almost complete separation. And that is OK! It really is. If, however, you are not fortunate enough to have a department for each platform, you will probably choose something else.

And that is my point. There is no single, better way to build mobile apps. There should be no war here. There are simply some development strategies to choose from and you need to know what are the strong points of each one.

Superior native user experience?

First let's ask – what is a good user experience? It's when user expectations are met. When you open a Facebook application do you expect something in particular? You probably expect your feed will be there, you can find your friends there... But do you expect a button to look in any particular way on any given platform? No. You expect the app too look like Facebook. You expect Twitter app to look like Twitter...

Almost any big application has it's own user experience. Almost all game-apps have a different layout and different interactions and such. In fact for many apps the more you differentiate the better. For example in Fruit Ninja you don't push buttons – you slash them. It might not be what users expect at first but it does create a great user experience once it is discovered. It's just immersive and simply fun.

Take any of your two favorite apps. Do they look the same?

Native, Web, Hybrid and more

Native vs. web debate is usually understood as two options:

1. Use tools native to the platform (i.e. Xcode for iOS, Visual Studio for Windows Phone, Android SDK in Eclipse or Netbeans for Android).
2. Just build a mobile friendly web page.

But this is oversimplification. For example many game-apps are written in C/C++ and talk to some drawing API like OpenGL. Other kinds of apps can use "native" API/SDK for building application GUI. I use "native" in quotes because all big platforms have at least two types of development kits, e.g. for Android you have Android SDK for standard apps and Android NDK for games and other apps that draw on screen instead of using built in components.

And of course there are hybrid solutions. But not just web-native hybrid as you might think. What you usually hear to be called "hybrid" is a web-native hybrid like an application build with PhoneGap. Technically it's a web page put inside a native application, a web page that can interact with a system more freely than a website in a browser. This also means that a hybrid app is distributed as any other app (pushed to platform's shop, downloaded from one and upgraded – all in a standard way). There are also hybrids that use native components, but allow developers to use JavaScript to control them. Like Appcelerator Titanium that is using some fixed set of components instead of HTML. Or something like AppGyver Steroids that uses some native concepts (like views), but allows you to use HTML. So there are shades even in this category...

But there are also cross-platform frameworks built on top of "native-drawing" APIs. One such framework is Cocs2d-X. I must add that by drawing API I mean something like OpenGL (or Direct 3D) which allows freely drawing shapes on screen. Shapes that user can interact with in very distinct ways (as aforementioned Fruit Ninja).

With things like asm.js and OpenGL coming to browsers even the differences between purely "native-drawing" apps and "web-native" hybrid might become even more blur on user side. In the end the only difference left might be the tools and the language used. Which is what the end-users cannot care less about.

Confused? You might be if you only hear about web vs. native war over and over again.

Are layers bad?

You might have heard that building hybrid applications is bad because you add an extra layer. The truth is that every application you've used in the last 5 years has layers and talks to other layers. If you make apps for many platforms you have to have some extra layer. Otherwise you would have to keep completely separate code for each platform... Why not go deeper – ditch the system, and use an assembler to talk to devices directly. Go for it. You will have superior performance...

Note that if you build application for each platform then you will build separate apps that only look similar. That would be bad in many ways.

1. Development cycle would have to be separate for each platform. This is very bad for pushing out new features.
2. Testing and quality assurance would have to be done separately for each of the platforms. Writing separate code is one thing. Making sure this separate code (with no common layer) works the same on each platform is pure horror.
3. Look&feel of your application will be different on each system. Think about it for a minute. Your users might switch systems and will be frustrated that their favourite app is behaving differently. Friends will not be able to share experience of using the same app. And if you provide any kind of manual or support then it would also have to be separate for each system.

Todays' applications are always built on top of something. Cross platform applications always have an extra layer or two to be able to actually be cross platform.

What should I choose?

By now I hope that you can see that you need some kind of common ground when you are building cross-platform applications. Applications can be cross-platform in terms of coding, testing and end-user experience. The question if your app should be cross-platform in any of this ways might just be a key to success. It is also tightly coupled with a question of choosing the right development strategy and the base framework.

Let me help you just a bit and give you some questions to answer:

• Do you need to target many platforms? Not everybody do. It's nice to have as many user bases as possible, but I can imagine you just want go for Android users or just iPhone users. It's a business decision really. Just remember that friends of your users might be very upset when they won't be able to use your app. If eventually you need to be cross-platform then use some cross-platform framework (or just build a website).
• Do you want to create a whole new world of experience? This is true for almost any game where you not only have custom buttons but also custom input methods. This is again not bad, just differentiate. Use drawing frameworks if you want draw and interact freely (whether cross-platform framework like Cocs2d or more platform dependent like Android NDK).
• Will your users want to have your app for longer or just peek at specific content? Or as Benedict Evans put it – do people want to put your icon on their home screen? Think bigger than just news websites where you read the article and close it. Think about stuff like shopping center maps or anything you might want to give out in a leaflet when someone walks by (or walks in)... Anything temporary you might want to show to users without the burden of download and installation. If it's temporary and shareable stuff, then you probably just need a website.

You might ask – what about web-native hybrid applications? Well if you want to be cross-platform, and you want to differentiate a bit from others, and want to distribute actual apps (that users have on their home screen), then I would say hybrid is your answer. As mentioned before – mobile web is maybe not ready for 3D games or intensive 2D games... yet. I say web-native hybrids will be ready for almost anything by 2020.

Remember. You users don't care what you use. They care about experience, quality and new features. Give them that based on your abilities and restrictions. Migrate as much as possible to server if you cannot decide upfront.