Which do you choose: native app or web app?

Native apps are the ones you download to a device and run as a discrete application (hence the name). So-called web-apps perform similar tasks, but run in your browser. But whether we can even consider a website to be an “app” is an altogether more contentious issue.

Despite what some people might say, I do think a “web-app” is a real thing. Not only that, I think web apps are one of the best things a startup (or anyone, for that matter) can invest their time in.

There's no denying that the boundaries between web-apps and web-sites are blurry. But so are most things we try to define. Arguing about it is nothing more than a distraction.

Why is the existence of web apps contentious?

It's easy to understand why people see websites and native apps as separate entities. They have different underlying technologies and usage patterns, after all. And it is the usage that I think sways the argument in favour of web apps. They are websites, but we use them as if they are apps.

Of course, the difference only matters when you're arguing about it. Everyone else just gets on with making things. Whether you call it an ‘app’ or a ‘site’ has no impact at all on what your creation actually does.

I find I just know which is which. Most websites don't have that instinctive "app feel". E-commerce sites often have complex user-login areas that feel app-like. But I would class those as web-sites. Post some new content using WordPress and you'll encounter many full-blown app characteristics. You need to login; you're accomplishing user-centric tasks; you have your own personalised dashboard. Despite all this, I'd still call the vast majority of WordPress installs web-sites.

I pleased to report that the web-apps I concern myself with don't lie in this grey-area. I'm not saying there isn't an issue here, I'm just kicking it down the path. The fuzziness is someone-else's problem; I've got work to do.

Why choose one over the other?

One main reason native apps are so popular on iPads and iPhones is the iOS browsing experience. It sucks, big-time. Want to switch back to a tab you were on seconds ago? Sorry, you're going to have to load the page again! Looked away for a nanosecond? Load the page again! Native apps don't have this problem. Build a native app and you have full control over your users' experience.

Native apps can also tap into device features with more ease than something running in a browser can. Want to access files, sync with the cloud, or authenticate using an external service? All much more straightforward (for the end user) in an app.

It's easy to see the appeal of a native app. But there are pitfalls and gotchas for a tech startup building their first product. When using a real browser on a real computer, the web wins hands-down every time.

Why not have both?

In most cases, an app will have a browser version and a native app version. This is a sign of a mature product: the users can do what they need to do wherever they feel most comfortable. Where the distinction comes into play is in the early stages of a new venture.

Resources are scarce early on. Budgets and deadlines will be tight. Your (small) team's technical skills will generally fall into a few key competencies. In these cases, you need to make hard decisions, if only for the sake of expediency.

Don't develop your minimum viable product for every platform available. That would be a staggering waste of resources. Maintaining two (or more) separate codebases will slow you down at the best of times. When you're still working on product/market fit, that slowness can be debilitating.

This is where web apps come into their own.

The web just works. Sure, there may be some technical challenges. Keeping a consistent user experience across platforms is hard, especially when using cutting-edge features. But get it right and your app will run anywhere that can open a website. And that's pretty much every device out there.

As soon as you choose a native platform you're closing off your app to a whole swathe of the market. Develop an iOS app, and now no-one on an Android device can use your product. Or anyone on a desktop, or anyone on Windows or Linux or whatever else they might be using.

Make your app as a website and it will run everywhere (if you've done it right).

How easy is it to publish updates?

It's all well and good releasing Version One of your app, but you'll always need to make updates. And if you're still working towards product/market fit, regular updates are essential. The ability to stay nimble is crucial if you're working in a Lean or Agile environment.

If you've made a native app, pushing updates is tedious at best. Every time you want to make a change you need to go through the rigmarole of submitting your new code to the App Store. And even once you've passed the App Store code review and approval, that's not the end of the story. You still need your users to download the update (and it's far from certain they'll actually do that at all).

If you're publishing your own web-app, deploying a new update or bugfix is much simpler. Just push your code repository live (and maybe wait for your caches to clear). No outside approval needed. You don't even need your users' permission. With a web-app, the power lies in your own hands.

Planning for the future and dealing with growth

At some point you will need to choose one path over another. When you do, you should think about the time when you'll be able to branch out again. If you only have the resources to build a web-app or a native app, don't forget to look ahead to when you can have both.

If your app is a success, you'll want to spread to as many platforms as possible. The ultimate aim is, of course, to give your customers as much flexibility and convenience as you can. Alas, bouncing from one platform to another is not a straightforward process. You can't just take code written for iOS and run it on an Android device, for instance.

One of the steps in the creation of any decent app is the creation of a decent API. The API will power the bulk of your app's functionality, and you can plug any front-end you like into it. When you expand to other platforms, having a good API means you need not rebuild the entire app from scratch. All you need to do is build a new endpoint.

The API approach helps whether your going native or web-based first. But it's not a silver bullet: building the endpoint will still take time and effort. But developing an API is always easier if your endpoint prototype is web-based. So when prototyping is over, why not reuse the code you've already written for Version One of your app?

Hiring

When it comes to hiring developers to work on your project, the ubiquity of the web is your friend. Talent and experience in web apps are far more common traits than native app skills. Sticking to the fundamental technologies of the web gives you more hiring options.

Web Apps are the best option for Getting Stuff Done™.

If you have validated your great idea and are ready to build your MVP, take a serious look at building a web app. It may well save you a lot of time and effort, and will be a strong step in your journey to greatness.