Developing a web app vs. a native app

Posted on Published
Developing a web app vs. a native app
There’s a lot of back-and-forth between developers on whether one should focus on developing web apps, or native apps when it comes to mobile platforms. I’ve done a bunch of thinking on this, and having developed both types of apps, I wanted to share my point-of-view. I’m mostly going to be referring to iOS and Android here. Other environments, like Windows 8 or BB10 let you make native apps using web technologies. I’d also like to note that this guide is aimed more at indie developers, and not for large organizations. Ok, let’s jump in.

Defining Terms

First, let’s define what these terms mean. A web app is an app that built using HTML, CSS, and JavaScript for the most part. I’m going to include hybrid apps (web apps within a Webview container, so that they can be packaged natively) as a web app, because most of your application code is still using the web stack. In contrast, a native app is an app that is built using the native stack (iOS/Android SDK with Objective-C or Java). A native app may still have webviews, with some code that is rendered in HTML. It just means that the bulk of the app is made using native technologies.

Pros

Web apps have the following pros:

  • Faster to prototype in HTML/CSS/JS, than code an entire app in Objective-C.
  • No need to send updates through the app store – you can publish updates anytime
  • Your app runs in multiple environments. Gets close to the “write once, run everywhere” dream.

Native apps have the following pros:

  • More performant than a web app since you’re closer to the metal.
  • UI/UX looks and feels more natural.
  • Less time spent styling elements to make them feel native.

Cons

Web apps have the following cons:

  • Your app will never be as performant as it’s native counterpart. You’re always executing code in a browser-context, which is slower than the native context.
  • It’s a pain (near impossible) to get your app to look and feel native. This is especially true in iOS.
  • For hybrid apps, communicating between the web and native layer is a pain, and not elegant.
  • Webviews will always reload when you re-launch the app, causing an unpleasant user experience.

Native apps have the following cons:

  • Write once, for a single platform. Very far from the “write once, run anywhere” dream.
  • Your app updates have to be explicitly downloaded by the users, meaning you will have a fragmented user-base.
  • At the mercy of the app store.

My thoughts

Make (responsive) web apps if you want to reach a large audience; make native apps if you want your small audience to have the best experience possible.

My thoughts on this subject have changed over the last few months. Initially, I really believed that web apps were the way to go. I tried everything – Phonegap, Titanium, hybrid apps, and regular web apps added to the home screen. At the end of the day, I realized a web app cannot stand up to its native counterpart. It is too damn hard to make a web app feel native. By this, I mean that the styling, transitions and DOM structure necessary to make a web app feel usable on iOS is very difficult. Attempting to do this takes up more time than it would take me make a native app, in my opinion. The Android browser is even worse, especially since a good chunk of Android users are stuck on v2.3.x.

Now, even if you aren’t worried about getting your application to look and feel native, you still run into issues. For instance, for any app that requires a slightly complicated DOM structure, suddenly you have to worry a lot about memory management, webview scrolling jankiness, and more. LinkedIn is on of the few companies that have a successful hybrid app in the App Store, but most hybrid apps fail due to bad user experience. LinkedIn did some great work with NodeJS, and were able to keep their DOM and HTML structure extremely simple by removing DOM elements on the fly – not a trivial task, and one that is automatically handled for you when using native views.

You see, when it comes to making a web app, I face two challenges.

  1. Writing my application logic.
  2. Making sure my application’s UI/UX was not crappy on mobile devices.

When it comes to writing native apps, I only worry about (#1), which is the only thing that I want to think about. So, these days, I adopt to this principle: Make (responsive) web apps if you want to reach a large audience; make native apps if you want your small audience to have the best experience possible.

Concluding Remarks

Web apps and native apps serve different purposes. I think it makes sense to start off with a web app (faster to prototype, larger user base, etc.), and then make a mobile app if the idea sticks. Of course, the opposite works as well (Instagram went mobile-first, for example).

As a front-end engineer, and someone who loves to improve user experience, I think it’s a great idea to get some experience making mobile and web apps. They both have their own challenges, and I find them both to be equally fun to develop.

  1. Thanks for an interesting and thoughtful write-up. But we should not need to make such trade-offs IMHO. Instead, systems should be modeled and from the models, an appropriate runtime system _generated_. It’s fundamentally a compiler and IP management issue to make this possible. More about this here if you’re interested. http://encapsule.org. Regards, Chris

  2. This is excellent article, indeed. The dilemma web or native is present in all serious developers or website owners. This “Make (responsive) web apps if you want to reach a large audience; make native apps if you want your small audience to have the best experience possible.” sums it all up. Thank you for a very good insight.

  3. Creating native and HTML5 apps is no longer a problem. Due to user friendly and flexible online app building platforms it is really easy to get an app in the Appstore and Google Play even if you have no programming skills. Among the services I used myself I would recommend Snappii as their opportunities in mobile app development seem to be endless and can suit any business needs.

  8. This article presents an oddly limited point of view. Two examples: author says a ‘con’ of native is “Write once, for a single platform.” Well, Adobe AIR is designed to provide a single codebase for both Android and iOS apps, and it does a very good job of that for the many apps that don’t require special native API access. For those that do, Adobe Native Extensions save the day.

    Another native ‘con’ of the author’s: “At the mercy of the app store.” Again, not true for an entire large class of native app: the business app intended for an internal audience (sales reps, contractors, general employees, product users). For iOS, at least, these can be distributed via the devloper’s own web site, no trip to appstore required.

    The ‘native for small audience’ — ‘web for large audience’ dichotomy presented here is just weird. Think ”Flappy Birds.”

  9. Pingback: Hybrid Applications And Android Native Browser « globetrotter

Comments are closed.

Up Next:

Cricket Time

Cricket Time