Native: Part 11 of How to Commission a Software Project
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:
|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).
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?