Native: Part 11 of How to Commission a Software Project

Author Image

This article about native software is part of the “How to Commission a Software Project” series.

In the web-oriented world we live in, native apps have waned in popularity (at least a little). Businesses are building platforms that live primarily (at least at first) on the web. Why? Because they’re expensive. And not simply in direct development costs. Here’s what I mean:

Native Web App
5x dev costs 1x dev costs
1 codebase per platform 1 codebase to rule them all
New code must be downloaded New code deployed instantly
Subject to lengthy reviews Just release it!

Native vs. Web Applications

Take a step back, though. What does native even mean? And what does it mean for your case?

At the core, a native application is written to run on a particular platform or device. The application is normally compiled to a binary executable format. Compilation allows the application to perform at a much faster level and prevents many reverse engineering methods, which helps protect intellectual property. Native applications require a build-and-deploy process for users to install or update the applications. This means a developer makes changes to the source code, compiles (or builds) the application, delivers the application (via hard media, the internet, or app store, and the user installs the application).

Web applications, while they still run on a platform, frequently use interpreted instead of compiled languages. With an interpreted language like javascript or PHP, some piece of software is required to parse (or interpret) the source code and do what the instructions tell it. This does have a performance impact, but that is typically more than made up for by the ability to rapidly develop and deploy the applications. A web application also only needs to be deployed to systems under your control. When you build your application on the web, deployment is agnostic of hardware – other than modern browser compatibility. No need for downloads or updates or app store reviews.

So what you’re saying, Bryan, is… “web?”

That makes the web-based route seem pretty sweet, right? But obviously, the native market is still pretty hot – and not only for mobile. But why is that?

  • Performance: Things feel smoother and operate faster when using native vs. web-based. This is especially important if you’re doing something in real-time.
  • Capabilities: Doing multimedia progressing or editing typically calls for native – at least for now. And if you want to use hardware like Bluetooth, cameras, or GPS directly, native is probably a good fit.
  • Offline mode: If your application needs to perform reliably on a disconnected device, native is probably the best answer today. There are workarounds to this as browsers get better (Progressive Web Apps are a topic for a future article), but for now native is safer.
  • Tradition: Some software will long live natively. Likely due to some combination of the previous points.

I usually make a strong case for web-based. The rapid agility is hard to argue against. But if there is a good reason, let’s dive into native.

Interested in getting help determining which direction to go with your software project?

Get Fivable to Help