The Tip of the Iceberg: Your Mobile App is Really a Web App

True fact: many of the native iOS and Android apps you use daily haven’t always been native. Recognize any of these apps on your homescreen?

If you thought most of these apps are native, you’d be right! But heretofore, substantial portions of these apps were powered by front-end web technologies. Since many of these apps ended up native, why were web technologies used in the first place?

Web-powered mobile apps have been the subject of much hype and flame wars. To confuse the matter, there is a lot of terminology around web-powered mobile apps. So let’s make sure we speak the same language!

What is a Web App?

Web apps are applications that (historically) run in a browser and are built with web technologies, namely JavaScript, HTML, CSS and the Web APIs. Web apps have a lot to offer:

Broad appeal: They are accessible on any device with a browser. Responsive web apps adapt to various device characteristics (like screen size), which enables tailored experiences across a plethora of devices.

Discoverability: Search engines like Google can search and index web content, and with some Search Engine Optimization (SEO) can drive a substantial amount of traffic to the web app.

Try before you buy: Good web apps are small and load quickly, which makes it straightforward to try a service or browse its content without committing to the service.

There are also plenty of ways to ruin a web app with a poor user experience (UX). Users especially dread web apps that:

Load slowly or are large (> 2MB). While the web boasts easy discovery, users quickly abandon services that take more than a few seconds to load.

Feel laggy responding to touch events.

Lack gesture support because with the explosion of multi-touch devices, users are often taken aback when their favorite gesture does nothing.

Lack basic OS integrations, like push notifications or geolocation.

What is a Native App?

Native apps are iOS or Android apps that build on the operating system’s own unique platform rather than the web platform. On iOS, this means Swift + Xcode, and on Android it means Java + Android Studio. Users love native apps for a lot of reasons:

Deep hardware integration: Since native apps are individually tailored to the particular OS, they can offer advanced OS integrations like TouchID or Near Field Communication (NFC).

Discoverability: Native apps are easy to discover, download and securely purchase through the platform’s app store.

Native apps can also be frustrating for users:

Large downloads: When an app weighs in at 80MB, users may hesitate or lose interest in trying a new service if their download speed isn’t great.

Forced updates: Apps that are tightly integrated with a back-end often require forced updates, which interrupts the user’s workflow with an 80MB update.

OS incompatibility: To update the app, sometimes the user must update their OS as well.

Vendor lock-in: The user’s favorite apps may never come to other platforms, so the user may hesitate to commit to a service that is exclusive to one platform.

What is a Hybrid Web App?

A hybrid web app is an iOS or Android app where significant portions are implemented with web technologies. You’ll hear a handful of related buzzwords invoked when discussing hybrid web apps:

Progressive Web App (PWA): Equal parts marketing hype and groundbreaking APIs, PWAs are simply web apps that use modern Web APIs (like offline, local storage and notifications) to craft an experience that feels native. Hybrid web apps are often considered PWAs.

WebView: A UI component available on iOS and Android that allows an app to host an embedded browser. This is the most common mechanism for “embedding” web code into a native app.

Cordova: A popular open-source tool for bundling web apps into a hybrid web app that provides integrations with hardware and native OS features. Cordova is most commonly used for generating iOS and Android apps.

PhoneGap: Adobe’s custom distribution of Cordova. It comes with various plugins and integrations not included in vanilla Cordova.

Should I Build a Native App or Hybrid Web App?

Not unlike end users, developers have their own reasons to prefer native or hybrid web apps to the other. With native apps, a developer can create a refined experience that tightly integrates with OS features and leverages hardware for maximum performance. But with a hybrid app, a developer can craft a good experience for multiple platforms with a single codebase and push out updates (“hot code push”) without awaiting app store approval.

So should you build separate native apps for Android and iOS, or a hybrid web app that can be deployed to both? This so-called “native vs. web” debate has sparked many flame wars of old, and it’s a misleading question because it focuses purely on the technical perspective while ignoring business needs and the release timeline. In fact, a hybrid web app can be the perfect catalyst to building a delightful native app!

At Big Nerd Ranch, we build a lot of MVPs (minimum viable products), especially for our startup clients. During the MVP process, there are inherently risks and unknowns we want to answer: Who is the target audience? What features will resonate with this audience? Is the core functionality technologically feasible?

According to the lean startup approach, the MVP is merely an experiment for testing a set of hypotheses, incrementally correcting them, or eventually pivoting towards a completely new approach! Since the MVP is only an engine for collecting data, it needs to be cheap and quick to develop.

Hybrid web apps can often help in executing the lean startup approach. Here are some questions you should answer to determine if the hybrid approach will fit your app:

Are you developing an MVP? What are your constraints, and are you expecting high feature volatility? If you need to cover several platforms, you will need to iterate quickly on a feature set, test them on an audience, then make improvements. “Hot” releases with hybrid web apps cut out app store approval and the need to preserve backend compatibility, enabling you to vet an app with user data as quickly as possible or pivot when the data radically diverges from your initial assumptions.

Does your app deliver value beyond a great user experience (UX)? If it offers intriguing functionality not available from competitors, users will be more forgiving of a hybrid web app’s UI.

Is your app mirroring a desktop experience, and are the use-cases across mobile and desktop virtually the same? While Twitter users do similar things on desktop and mobile, Uber riders book cars exclusively through the mobile app.

Is your app content-focused or centered around a new mobile API, like TouchID? Content-rich apps like social media, store, news and chat apps change frequently, so the “liquid” layout of a web app will favor rapid iteration.

If you answered “yes” to most (or all) of those questions, your app is a great candidate for the hybrid web app approach!

Building an MVP with a Hybrid Web App

With any MVP, it’s important to plan a release timeline. If a hybrid web app is a good fit for your application, you have a new question to answer: when should you transition from the hybrid web app and build a native app to replace it? Here is a sample timeline:

Build a hybrid web app MVP-style. Thanks to “hot” code updates, you can iterate on the backend API without yet worrying about backwards compatibility for older mobile apps or waiting for app store approval. With a single codebase, a small team of developers can quickly deliver, improve or pivot on functionality.

Sometimes, a hybrid web app is good enough and there’s no financial reason to switch to a native app.

But often, a web-based mobile app is not the stopping point for a successful service. Once feature churn slows down and you understand your users, you can test a new set of assumptions: do users expect a native experience and certain OS integrations? When/if they do, you are ready to build a first-class native app to replace the hybrid web app, and by now you can (hopefully) fund the native rewrite with revenue from the hybrid web app!

Many well known services—like Instagram and Facebook—have taken similar approaches, but generally without much fanfare. It’s a clever strategy for preventing confirmation bias, a phenomenon that causes users to perceive and interact with an app differently when informed of its web nature.

Facebook wrote an exceptional postmortem in 2012 after they transitioned from their hybrid web app to a native iOS client. Their experience not only highlights the role that web can play in a service’s timeline, but also when it’s time to move on (emphasis added):

By allowing us to write once and ship across multiple platforms, HTML5 … has been instrumental in getting us to where we are today. We chose to use HTML5 because … it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.

So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up…

Common Misunderstandings

“My app needs to have a perfect native UX/UI at launch, or it will irrevocably flop.” Will an imperfect UX/UI kill your app? Unless you are a well-established service like LinkedIn, no, not at all. Services like Craigslist and Reddit aren’t especially beautiful or polished, but they deliver critical value, which translates to revenue. Furthermore, if an app’s exceptional UX/UI isn’t bringing in revenue, then its beauty translates to wasted money. Apps whose sole innovation is UX/UI are unlikely to survive long-term.

“Hybrid web apps don’t perform well.” Well-written hybrid web apps perform well even at 60 fps, so performance should not be a deciding factor until user data indicates otherwise. And if your web app is suffering from poor network performance, check out our case study on performance metrics.

“Hybrid web apps can’t interact with hardware.” With Cordova, web apps can access many hardware and OS integrations, in addition to those already supported in the browser (e.g. accelerometer, GPS, battery).

Creating a Delightful Hybrid Web App

Many popular services start out as hybrid web apps, not because they are superior replacements for native apps, but because they cater well to building an MVP. Instead of reliving the native vs. web debate, consider creating a successful service with a web app, then pivot on that success to build an exceptional native app.

If you feel that the hybrid approach will fit your needs, feel free to contact us. We focus on understanding your company’s goals and obejctives, and we will work with you to quickly determine if a hybrid web app is the best fit for you.