Understanding Native Apps for Non-Developers

A little while ago, Viget wrapped up an Android native mobile build for FiscalNote, a DC-based company that uses AI for predictive governmental legislation and regulations. It was a large-scale app with a high degree of complexity, and allowed us to stretch our native development wings.

I spoke about some tips and takeaways from that project during the 2019 Digital Project Manager Summit in Orlando. It had occurred to me that it’s beneficial for non-developers who work in this space to have the foundational knowledge for what a native app is, and what makes it different from other app technologies. That’s what I’ll be covering in this article.

If you’re interested in more specific project management tips on this topic, you can find them in one of my previous blogs. If you have a more technical role, my colleague’s article on picking mobile technology is very helpful.

But let’s get to it.

First, in order to understand what a native app is, it’s best to talk briefly about what it is not. There are two other types of apps that fall under this “app” label: web apps and mobile apps.

Web App

A web app is slightly different from just a website. It has interactivity and functionality, whereas a website can be just purely content.

Fast Facts:

• Still utilize a browser, and can work on both desktop and mobile
• Can be written entirely with traditional web languages like HTML, CSS, and JavaScript, or backend language like Ruby

Tools like Google Docs, Codepen, and Trello are considered web apps.

There’s a distinction to note between client-side web apps and server-side web apps. Client-side apps are used in cases where the animations are flashier and more interactive. Server-side apps are used when data needs to persist—things like user profiles, for example.

Hybrid App

Within the hybrid app label are two distinct models: hybrid web and hybrid native.

A hybrid web app is a combination of web technology and native device implementation. These apps run on a mobile device within a native container, using a web view. It’s essentially rendered as any normal app you’d see on your phone, but it doesn’t rely fully on the device itself.

A hybrid native app is often regarded as a mix of web and native technology because it renders components that are truly native to each platform, while still sharing the code that drives the app—there’s essentially a “bridge” that talks to each platform to render native UI. The definition of these apps is somewhat murky since they’re written in JavaScript, which is typically reserved for the web.

Fast Facts:

• Built to run on multiple operating systems (Android, iOS, Windows, etc.)
• Can utilize device features (camera, microphone, GPS, Touch ID, etc.)—although for hybrid web apps, it’s not as easy or intuitive to build for as you might think, whereas for hybrid native apps, it’s relatively straightforward

Popular recent frameworks have significantly leveled up hybrid apps. Two of the most prominent are Ionic for hybrid web and React Native for hybrid native. React Native is built by Facebook.

Some high-profile applications use React Native as their framework, including Facebook, Skype, and Uber Eats. Ionic was used to build apps for Marketwatch and Nationwide, among others.

Native app

As opposed to hybrid apps, native apps are built specifically for one operating system (iOS OR Android OR Windows phone, etc.). I’ll dive into the pros and cons of this approach in the next section.

Fast Facts

• Seamlessly incorporates device features
• Use specialized languages like Swift or Kotlin, with predecessors such as Objective-C and Java
• Have tools specific to platforms: Android Studio for Android, XCode for Apple, and more

The most important takeaway here is that native apps are built for a specific operating system and take advantage of all that has to offer.

Pokemon Go, Uber, and Waze are all native apps.

(You’ll notice these three examples do not appear on just one platform. In these cases, there are multiple native apps for each—one for iOS, one for Android, and more for other operating systems. That’s an important distinction to keep in mind.)

Native App Differentiators

You might be wondering why someone would ever want to build a native app if they could just build a hybrid app and have it work across platforms. There are, however, some very distinct advantages (and disadvantages) for native apps.

Pros

• Performance: When you swipe or tap on your app, you expect it to react right away. Features like this (swiping between screens, gestural interactions, etc.) are built directly into the platform, so achieving them requires little forethought on the developer’s part. They’re also hardware accelerated since they’re built into the operating system.
• Tooling: First-party tools like Xcode and Android Studio provide design previews, accessibility checks, and performance monitoring already built in. These tools are gold standards.
• Security: For native development, everything can be coded into the infrastructure of the app, and encrypted, whereas hybrid app containers are essentially a browser, which can expose features of the underlying platform. Native apps are also more conducive to two-factor authentication.
• System UI: Native app standards allow developers to match app UX and UI to platform conventions. Since iOS and Android users are loyal to their platforms, the subtle differences between those two can cause users to stumble if the app is a hybrid.
• Languages: While it takes a lot of time and effort to learn a new language, certain ones for native development like Kotlin or Swift provide features to help write higher quality software.

Cons

• Cost: This is a big one. A lot of the time, developers specialize only in one OS, so building natively for multiple platforms will require more resources.
• Timeline: Building a native app requires a lot of technical expertise, and it can be hard to find developers with the appropriate skill set. Add in the time it takes to recruit these people to the time they’ll need to actual code up the app, and you’re looking at a long production cycle.
• Distributed Codebase: Native apps built for iOS won’t work on Android, and apps built for Android won’t work on iOS; same concept with Windows Phones and others. Therefore, you’ll have two or more codebases to maintain. This is a big reason why native apps aren’t as flexible.
• Maintenance: Native app developers have to account for variability in device and components, known as device fragmentation, as well as older versions of operating systems.
• Languages (again?): Native apps are written in statically typed languages, which require a more formal way of expressing ideas. This helps to avoid bugs, but makes edge cases painfully clear. A viable solution in Kotlin might require thinking through 90 percent of a problem, whereas you can often get away with only 30-40 percent for a JavaScript project. This means the shelf life of native languages is longer, and the code is more performant.

There will undoubtedly be new technologies as the mobile world continues to expand and diversify. Not too long ago, Facebook was neck-deep in and a huge advocate for native technology. Now, they’ve pivoted away and are finding great success with their hybrid approach, and React Native is grabbing huge chunks of the market. But just as prevalent are the companies that swear by native development.

Choosing the mobile technology that’s right for you can be difficult, but understanding what each of them is shouldn’t be.