The problem with mobile frameworks

Rob Borley

You have made the decision to develop a mobile app. Good for you. But should you build a native app or a hybrid / web app?

I’ve been talking a lot in recent weeks about developing a mobile strategy. When it makes sense to make use of apps and when it makes sense to utilise the mobile optimised web. In all of these discussions I have tried to talk generically about apps and not get into the debate surrounding ‘native’ and ‘hybrid’ technologies.

Today I am assuming that you have gone through the process of deciding how best to deliver your online offerings and that, in this case, you have decided, for whatever reason, to build an app. I am going to start to explore the process of deciding which technology set; web / hybrid or native, you should use to build your apps.

Do not allow technology to decide for you

The first thing to say is probably the most difficult to get over. It is important to not allow technology to make this decision. What do I mean buy that?

Mobile has drawn together two worlds in the technical space. The web industry and the software development industry. For many, mobile is the obvious next step for the web professional. Most clients do not understand difference between the Web and the environment which mobile platforms provide. They see mobile as an extension of the Web. However, these are different platforms that require different skills and different approaches.

The Internet is the underlying technology on which the World Wide Web sits. This same Internet is the technology that mobiles apps use to communicate too. Most of the general public use the terms Internet and Web interchangeably when describing their online behaviour. Conversations along the lines of; “I found this on the Internet” and “I found that on the Web”, are not uncommon. This has proliferated the confused concept that the Internet and the Web are one and the same thing. They are not. The Internet is a network of connected, networked, devices that are able to communicate with each other. A network of networks you might say. These devices may be computers, TV’s, mobile phones, fridges, cars, or anything else for that matter. The Web is a layer on top of the Internet which provides an easy way to publish and consume documents; websites. Apps, like websites, use the Internet in the same way. That is as a means of communicating with other devices, data, and services.

All developers and technical teams have their preferences. It maybe that they have come from a software development background and so prefer the ‘native’ technologies. Maybe they can already develop in Objective C (the language of iOS) and so they instantly lean towards this technology to provide solutions for their clients. On the other side of the fence are those who have come from a web background and so lean towards web technologies (HTML5 / CSS3 / Javascript) to develop the solutions that they need.

If a developer has come to mobile solutions from the world of the Web then their technological skill base is going to lead them towards developing hybrid app solutions that rely heavily on web technologies. If, on the other hand, they have arrived at the world of mobile development from a software development background then they will have the skill set to jump into native app development. While it is understandable to allow your current skill set to make the decision about the technology you use to develop your solution, it is not the correct way to make such a decision. Both hybrid and native solutions have their place. There are clear use cases for which each option is valid. These use cases are what should be used to make the decision as to the route to take, not the skills of the developers that you happen to be talking to.

Each platform; iOS, Windows, Android, has a distinctive flavour which drives not only the look and feel but the behaviour too.

For the purposes of this article I am taking a broad brush view of the world. It is worth baring in mind that each project should be taken on it’s merits. There are plenty of grey areas and half way houses but this is the place to start your thinking when approaching this decision. The key is to decide if you are going to build an immersive environment (games, Google+, Linkedin iPad) that runs on a mobile device or are you going to build an app that uses the native UI; look and feel (Things, Simpl, Instagram). Sometimes that’s a really obvious decision to make and sometimes not; I’m not going to look at that part of the process this time.


It can be quite difficult to build an immersive environment with the tools provided by the native platforms. Apple’s iOS platform, for example, relies heavily on table based layouts and interactions. This is where a hybrid approach using HTML5 comes into its own. Apps like Linkedin and Google+ show this off very well. By utilising the power of HTML5 and CSS3, with a fair sprinkling of native code too, they are able to provide the user with a custom, but vibrant and immersive user experience. The web technologies provide a flexibility that enables such a UI to be developed effectively.

Native UI

Developing with a native UI is often the route that is preferred. Each platform; iOS, Windows, Android, has a distinctive flavour which drives not only the look and feel but the behaviour too. Screen transitions, user feedback on gestures; swipes, taps, etc, as well as the navigation, buttons, tool bars and everything else. Apps on each platform feel like that belong to that platform. Transition time, feedback responses, etc. They just feel right. If you are developing an app with a native UI then you must, must, must, use native app development techniques and technology.


The mistake that many people make when developing an app is to fall back to the technology that they know best, irrespective of the solution that they are trying to develop. This is where the temptation to use a mobile framework rears it’s head. It is possible to develop a native-esk UI with HTML5, CSS3, and Javascript. There are numerous frameworks out there that can help you along the way, with varying degrees of success. JQTouch, JQuery Mobile, Sencha Touch (there are others) are all javascript based and essentially provide widgets to mimic the behaviour of native UI. However, the problem with each of these frameworks is that they are pretending to be something that they are not. They are trying to replicate a native UI but they don’t quite make it. A split second delay on a transition or a slightly different look to a button make a huge difference on a mobile device; disproportionately so.

As I’ve discussed before users have deep, emotional attachments to their mobile devices. Their tactile nature, their omnipresence, the data that they hold and the access to services that they grant combine to evoke a deep sense of connection with the device, As such, when they don’t behave exactly as the users expect, or the experience of using an app or service doesn’t meet their unrealistic expectations, a negative feeling is left behind. Such framework or other web technology based attempts at native UI leave your app feeling ill thought out and cheap. The initial presentation sets the users expectations that they are going to have an experience that they know and have come to expect, and then the reality falls short. This expectation is the key to the problem. I’m not against web technology in the mobile sphere. However, it should not pretend to be something it’s not. Such frameworks set the expectation of a native experience but they fail to deliver.

Never build a native UI based app in this way!

If we understand that it’s not a competition between hybrid and native; that there is a role for both approaches, then we can realise the potential of making the right friends and partnering with people who have the skills we lack.

Jack of all trades

It is not going to be possible for all developers / agencies / studios to acquire the skills needed to be expert in web technologies and hybrid apps as well as native technologies. That is OK. If we understand that it’s not a competition between hybrid and native; that there is a role for both approaches, then we can realise the potential of making the right friends and partnering with people who have the skills we lack.

Make decisions about app development techniques and technology based on what you are trying to achieve. Do not allow technology to make this decision for you. If you do, then you will end up with a sub standard user experience which will damage your brand disproportionally and not only mean that your development effort for your app is wasted but will also have consequences beyond the scope of the initial project.

Two simple guidelines

  1. If you want a native UI then build a native app.
  2. If you do not want a native UI then consider building a hybrid app with web technologies.