At Dynamit, we create web and native mobile applications. We have teams dedicated to Android and iOS as well as several teams dedicated to creating web applications. Often these teams work together. We believe that both web and mobile have a place in the digital ecosystem. We don’t think it’s an “either or” choice, but there are reasons you should favor one over the other for certain types of projects.

The debate over web or native mobile has been around for a few years, but there’s plenty of gray-area and companies still approach us wondering whether their project is a better fit for the web or for a native app. There are reasons to build native applications and there are reasons to build web applications. Many companies need both, or could be successful with both. For some, only one really makes sense. How do you know which camp you fall into and when to build native or web?

Recently, a few members of our team—Front-end development lead Luke Askew, Mobile lead Steve Zeidner, and Strategist Josh Amer—weighed in with some of their thoughts on the “web v. mobile” debate in the hopes that we could shed some light on how the two can coexist and when you should be using one or the other, or both.

We covered a lot, so we broke things out into a series of posts. In part one, we look at where the web lags behind native (and vice versa) and explore the idea that the web is for information and native apps are better for tasks.

———

Who’s Winning the Arms Race?

Josh Amer: This is an old debate. Why don’t we start with a status? Where is the web still behind native and where does native lag behind the web.

Luke Askew: If you start with where the web is behind, I’d sum it up with one word: experience.

Experience is two pronged. The first prong being performance. Web applications running in the browser will be slower. Web applications have so many different layers of processing that you don’t get nearly as smooth or crisp of an experience, or as smooth or crisp of animations, etc. that you would with a native mobile experience. It’s just a different ecosystem that you are in. There’s a lot more happening in browser that inhibits performance.

The other side of the experience coin is the ergonomics or the heuristics of the experience itself. Native experiences tend to play much better into the design of the device and the metaphors of the operating system. You can create an app experience that really leverages the design and abilities of the device you are using. With a web experience, you are isolated into whatever the browser provides—the controls of the browser or the browser chrome. That limits your ability to come up with the best experience for your application.

JA: That’s interesting. When you’re building a native application for iOS or Android, you have interface guidelines that help you design something that’s great for a single ecosystem and device style. There’s no true interface guidelines for the web.

There’s also a reason that the Android guidelines and the iOS guidelines are different. The device ecosystems are different, the ergonomics are different. So you create different experiences with your app. When you design for the web you must design something that’s going to fit every scenario and device. So you probably won’t ever be able to make a web application where the experience is perfect across all ecosystems.

Steve Zeidner: Yeah, from a high-level, the interface or the design of a native app is going to be a single platform design, so you make some choices that enable it to work really great with that platform.

Until the hardware is to the point where that intermediary layer doesn't make any difference, there's going to be a performance lag for the web.

In addition to what Luke mentions, I’d also add onto the performance comment. When you look at the web, there’s a layer between the code that’s written and how that’s processed. So a web app is always running and being interpreted and processed by hardware. That additional layer, which you don’t really have with a native app, really changes the performance. Until the hardware is to the point where that intermediary layer doesn’t make any difference, there’s going to be a performance lag for the web.

On top of that, there’s the matter of what platforms provide access to on a hardware level. Hardware makers provide open APIs so a web application might be able to use some things—like basic camera access or GPS or location access—but you won’t have the fine tuned control over every piece of hardware that you have with a native app, and sometimes you simply can’t access parts of the hardware from a web application. If you were to implement 3D touch, for instance, there’s no web API for that, so you can’t tie into that.

JA: What are some other examples of things you can’t access from a web app?

SZ: Any of the sensors.

Let’s say you are building an exercise app. There are a number of sensors you might want to tie into for that app—the gyroscope, accelerometer, the GPS, etc. With a native app, you’d have fine-grained control over how frequently you want to sample those sensors and can really fine-tune how you use those sensors. If you were building that app for the web, you don’t have access to each of those individual sensors and you don’t have the same level of control. There might be a general “Find my location” API you could use, but not something where you can be sampling location on a millisecond basis.

JA: Offline is another app capability that we’ve seen drive someone to make a native app over a web app.

SZ: Yeah, an example of that is your maps application. You’re driving around and it has maps downloaded and cached—at least for the surrounding location. If you go into an area with no coverage, you can still get a GPS signal from a satellite and the app still works. There are certainly cases where offline comes into play.

JA: What about the other side? What’s the web better for?

If your primary goal with your application is to reach as many people as possible, and you aren’t as concerned with an immersive experience, than the web is a good fit.

LA: Probably the biggest strength is universality. If your primary goal with your application is to reach as many people as possible, and you aren’t as concerned with an immersive experience, than the web is a good fit. The web is universal. It runs across any device. iOS, Android, Windows, Mac, Linux… anything that can connect to the internet should be able to consume a web page.

JA: That’s an important point. There’s a lot more that apps can do, but we’ve definitely seen a big slowdown in adoption. The average number of apps someone downloads in a month is zero, and it has been for a while. People still use apps all the time, just the ones they’ve been using and have gotten used to using. So the reach point is a really good one for the web, because you don’t have to go out and download a new app.

Making the Right Choice

JA: So, we know a bit about where apps and websites are ahead of one another, let’s talk about when to build each.

There’s an idea out there that apps are really better at tasks and websites are better for information. If you’re going to have something that’s purely informational just do a website, but if you’re going to do something task heavy, maybe it’s a native app. There might be some middle ground, but generally what do you think?

LA: I think I would agree. In my experience, I’m more apt to use an app if it is focused on achieving a certain task. If it’s recording my run, if it’s routing me to directions somewhere, even if that task is looking at restaurant reviews. I usually immerse myself into an app experience when I’m highly focused on performing an action because I know the app is going to be designed around the task.

With a website, it’s harder to leverage the strengths of a device OS or hardware for the task. It’s really better for accessing information—a blog post or a menu—really quickly, rather than performing actions.

SZ: I generally agree. I think it depends on how much information is being given or what you are doing with the information. Using the example of a restaurant, if I wanted to see the menu, I don’t want to download an app just to see that small bit of information. If I want to order, if the restaurant provides online ordering, I’d rather use the app because of the experience. In that case you’re performing a task.

But then think about something like Facebook. It’s both informational and task-based. You want the information from Facebook to come in quickly, which is a pretty good reason to use the app. But, you could also look at Facebook’s news, where they are just loading a web page into a native view to get the content loaded quickly. From an openness of the web standpoint, that news content would be much better suited as a webpage, but to get around loading times, Facebook loads the content into an app.

From a high-level perspective, tasks and information are separated, and in general information is better suited for the web because of update-ability and maintenance, but then you have cases in the middle.

From a high-level perspective, tasks and information are separated, and in general information is better suited for the web because of update-ability and maintenance, but then you have cases in the middle. It’s interesting to see apps trying to make the information experience better from a native standpoint.

JA: How much does frequency play into your app use? You say you want to order from an app, but if it’s your first time ordering from the restaurant, are you really going to use the app?

SZ: That’s true. If it’s my favorite pizza place that I order from all the time, I am more likely to have the app and I want an app for that. I’d want to have my favorite order saved and quickly order from my watch, or any device.

LA: One additional thing to add in the mix of when to build a native app or a website is speed to market. If you are disciplined in the experience you are designing, you can have a much faster speed to market with a website. You can leverage the web as an open, universal platform—there is no app store approval process for the web. If you own a web server or pay for hosting, you can put whatever you want on the web whenever you want. If your concern is speed to market, the web can be the right way to go.

That comes with the caveat that you have to play down the experience in some ways. You have to design something that isn’t going to need a lot of memory or performance for animations and processing power. But if you can design around that, then the web is great.

SZ: Speed to market is important. I’d also consider maintainability. If you’ve got an app out there, and new versions of the hardware or the OS come out, you have to make sure that you have a team available to maintain your app. You need someone to make sure that your app will continue to run well on the latest version of Android or iOS.

Taking a Strategic Approach

JA: I see a lot of apps that seem like they could have been websites. If you already have a website and you want an app, does it make sense to just create an app that replicates the website?

SZ: If you’ve got a website that’s doing a lot for you—say a hotel chain website with booking built in, and you know users are mostly using desktops for booking, but you have a smaller number of mobile power users—think about why you need to duplicate the experience. Is there some reason you need to make the experience simpler, quicker, easier on a native app and you need to duplicate it? Or is there no reason and you should just create a responsive website?

More of your time should be spent exploring what else an app could do for you and your customers. Maybe you do more for the on-premise customer through your app, maybe something more like a concierge service that reduces friction while you are at the hotel.

JA: What do you think, Luke? If I had a great responsive website that allowed me to perform key tasks like booking, and I asked you to build an app to do the same thing, what would you tell me?

LA: I would say that your app should offer a very specialized experience that your website doesn’t. In the hotel example, I would strongly consider keeping the booking experience outside of the app. The opportunities that an app opens up for you should be more about the experience of the physical location. The booking process is covered and it’s universal through the web. It doesn’t need to be part of an app. It’s better to think about the digital experiences you can have that are unique because you are in a hotel.

SZ: But what about something like Hotel Tonight?

LA: Their whole UX is around the persona of someone on the go, someone needing something quick. Everything is image heavy, it’s easy to scan and find a hotel quickly, it’s one button press. It’s a different target persona.

JA: I think the key is the problem they are trying to solve. Mobile makes sense for that problem. If I’m a hotel chain, it’s probably more likely that people are doing more of their booking in advance from the desktop or a responsive mobile site.

LA: I wouldn’t put anything in an app that you want to be universally accessible to everyone everywhere. I wouldn’t create that barrier. You want people to be able to book a room without having to download an app.

SZ: I think Hotel Tonight’s position is that it’s actually more accessible by being in an app. They think they are reducing the friction to booking. More people have their phone with them, so more people have access to book.

Sliding down a slide is easy, but climbing to the top is hard. Downloading the app is like climbing to the top.

LA: Sliding down a slide is easy, but climbing to the top is hard. Downloading the app is like climbing to the top. Unless you’ve downloaded the app, it’s not easy. It doesn’t matter.

JA: Frequency is also worth considering here. If I’m someone who is pretty loyal to a hotel chain, and I’ve got their app because it enhances the experience while I’m there, I might want to book straight through the app if I can. It’s a different persona than the family vacationer who’s planning things out at home and doesn’t book hotels often. I think frequency is an important consideration in your web or native strategy.

SZ: Yeah, it is. You think about frequency as part of thinking about who you are really targeting with your strategy.

JA: I think that really gets to the core question here. If I’m a client and I’m not sure whether to go with a responsive website or a native app, what do you tell me to think about?

LA: Target audience, success indicators, project KPIs, how it will be supported, what can your team handle, SEO, discoverability.

SZ: Look at metrics of existing functionality

LA: Start by defining the problem you are trying to solve before you think about solutions. Web or native is the wrong question to ask first. You should really outline what you are trying to achieve and then let that answer shape your direction.

SZ: I’ve had someone define their goal as “we want people to open the app every day.” But that’s not the right problem to solve. You need to look at the problem, then find the solution.

JA: I think you just need to ask “Why?” in those situations and ask it until you get to the real problem you are trying to solve.

——

In part two, we’ll explore hybrid apps, using services-oriented architecture, AI, and the future of this debate.

The Secret Sauce: Interface Driven Development

Josh Amer
Josh Amer