Starting with iOS, there has always been a divide between native and non-native (or responsive apps). Early on, the functionality of native apps was much more limited than it is today, so the divide wasn’t as noticeable. But today, with advances in hardware, location-based services, video, voice, and more the divide between what a mobile site and a native app can do has grown considerably, creating a considerable amount of tension between native and responsive design.

The most salient tension today is between function and form. This wasn't always the case, as responsive and native apps used to be quite similar in terms of functionality. Another way to look at the tension is in terms of costs and investment in development. As with function and form, the differences here used to be minimal. But as the mobile ecosystem has evolved—specifically native apps—the differences have grown.

What Separates Native from Responsive?

Currently, the difference between native app development and responsive design is like the difference between the major leagues and the minors. Native apps—with access to everything from compass, location, voice, camera, and video—is the major leagues. Responsive design is in the minor leagues, seeking to emulate performance levels in the major leagues. The major leagues will always set the course for performance.

This might seem like a simplistic view, but it accurately summarizes the relationship between the two.

Native Takes the Lead

A couple of years ago, it would have been crazy to say something dismissive of responsive design. With the gains of HTML5 and promised future improvements, responsive was treated as an equal to native. Remember, even Facebook's first iteration on mobile was a responsive app.

However, after a year or two of HTML5 promising to eliminate the differences between responsive and native—with native design advancing quickly—it's now widely recognized from a pure design and UI perspective that native is substantially better. Instead of attempting to adapt to the medium (a phone's OS), native apps live in the medium.

The Race is Far from Over

So native apps are better, game over? Not quite. Despite native providing improved design and UI/UX, responsive and HTML5 has nearly 50% adoption in most markets. So it's certainly a practical tool for many developers and businesses.

What makes HTML5 and responsive so pragmatic? Well, a big part of the tension between the responsive and native design is the cost. Early on, this wasn't the case because there was either iOS or responsive. Android at that time was spread out across about 10 releases and 150+ screen sizes. Designing for Android was so unpractical that it was avoided altogether. That left the choice between either a responsive mobile site or an iOS app.

The differences between responsive and native continue to grow, exposing very different capabilities

Things are much different today. Android has improved by leaps and bounds and now has a much broader distribution across recent releases. It's improved to such an extent that now there's a major cost consideration. The choice is between a responsive mobile app or an iOS and an Android app. After all, Android and iOS each have about 45% of the mobile market share. Now it's a choice between two full on development projects or two teams, depending on the size of your organization, or one project with one team. This is a significant difference in resources.

Coupled with that, there are major performance differences to factor in. Responsive doesn't have near the capabilities that native has for accessing a phone's functionality. Want a photo-related app? It must be native. What about a music-listening app like Shazam? It must be native. Although responsive apps have been able to—with a user's permission—use a phone's location-tracking ability, access to other areas of a phone's OS or hardware is still out of reach.

From a pure app design and UI/UX perspective, these are serious limitations. Sure, you can provide rich information, even video. But to appear as though the app is actually a part of the phone, and to make it synonymous with the phone, as is a great app's intent, this is still impossible with responsive design.

A Case for Each Approach

Back when mobile was relatively undeveloped, just providing the desired information, regardless of form, was enough. But as we've seen with the U.S., European, and Asian markets, once the novelty of mobile information wears off and the competition around form and function kicks up, responsive will no longer suffice for those seeking recognition or widespread use.

Fortunately, for many apps, especially in developing mobile ecosystems like those in much of the third world, none of that is required. Just providing the desired information or functionality is enough for many apps.

This also applies to use cases for which the information, irrespective of its form or function, is largely sufficient. Take public transportation schedules or arrival information. At most, these require the location of the phone, from which they can alert the user to transportation options. They can even link map info to the native map option in the OS. That works because, unlike Uber of Lyft, the considerations for payment and hailing of transportation aren’t present.

Conclusion

As the pace of mobile innovation continues to accelerate, the differences between responsive and native development continue to grow, exposing very different capabilities. Fortunately, for most businesses it’s a fairly clear which route to take: If the core of your business is mobile, native is the right path. If not, responsive will likely suffice.

 

Image of dude carrying boxes courtesy Shutterstock.

Article No. 1 144 | November 18, 2013
Article No. 1 301 | September 4, 2014
Article No. 1 018 | May 14, 2013

Add new comment

Comments

Good article Sawyer, fully encapsulates that which I've been telling my clients for the last 8 years. As a full stack native mobile developer, I can attest to the fact that native will be the future of mobile applications (which is different from just "mobile"), due much in part to hardware manufacturers and the implementation of native sensors. In the case of Android currently, Manifest File Permissions offer support for 18 native sensors to called into a native written app (even though most devices don't currently offer ALL these sensors), which to me is a clear sign of where we're going. In fact, billion dollar industries have sprung up in the last few years, JUST based upon the efficacy of native sensors in mobile devices. So again, the honeymoon is over, now it's time to secure the marriage till death do us part! We've all done the mobile dance, and have gotten used to consuming information from our devices. But the future of mobile development (specifically mobile software), is firmly in the hands of developers that write natively, and stay pure to the craft! Cheers,

Excellent post. Very informative and sheds light on the appropriate aspects. The debate over native and responsive is going on from ages and will continue to do so. Responsive design needs a lot less work compare to native and many a times it is preferred over native. Also, responsive design is fast gaining pace and improving by leaps and bounds. So it is very early to predict who is the winner in this race though native seems to be better amongst the two. I absolutely agree with the last paragraph you've written that as mobile innovation continues to grow there is a lot many capabilities left to be exposed.

http://www.loungelizard.com/

Good topic and one we've been struggling with for a while. Another aspect if this is payment and the whole issue of in-app purchases. Has anyone come across p2p payment issues with native apps?

Interesting article. I agree with the article that native apps allow more. I know that capabilities of browsers do not grow as fast as the native allows now.

Please let me be a devil advocate. I will bet that it is possible to create a photo editing app using HTML5. So the app will be one for any devices you can imagine. Some today browsers allow using more and more hardware features. You can access a battery, camera, connection, compas, contacts, system notifications, gyroscope, offline memory and more. It requires permission as it needs it - not just apps which requires access to everything at once. But for now, only some browsers allows to access many hardware features - but the amount grows.

A lot has happened and matured till the inception of html5 and javascript frameworks . I am a huge fan of this stuff and worked on different projects but there was always the time when the guys in managment team wanted less efforts to capture both worlds using responive designs. But i think we should now be very vocal and confident in saying that native apps have just won the race and they will continually be doing so.  You said the accurate conclusive remarks and i surely second that as well. Great work .

Good article. Race is far from over, but mobile hardware/software industry moves a lot faster than the W3C -- or even browser development.

In South Africa we operate in an environment that is still dominated by feature phones, so although the core of our business is still mobile, native holds little value considering the cost to produce it.

Our consideration, based on how quickly things change is do we invest in responsive now or wait it out and go native in time.

This is a really good blog post and something I've been deliberating with for a while - so a really nice round up of the pros and cons of each. 

As far as business cases go, cost of production and, even, maintenance has to come into this as being an overriding factor. Going native, with so many different platforms (3 major) is much more expensive to produce and maintain than a responsive single entity. 

 

Completly agree with you, David.

Many don't see the very important factor of maintenance and marketplace administration (e.g. comments).

Native, hybrid or web apps?  

That is the question.

you mixed up some terms here. Responsive doesn't imply web/html apps. Responsive apps can be as native as any native app. It is defined by the UI framework.