Building an app? Deciding whether or not to write “native” code will be the first technical choice you make. This single decision affects everything that follows, from whom you can hire to customer satisfaction to first-year revenue. It’s not always crystal-clear what tech teams mean when discussing native and since we often get asked to clarify this, we decided to break it down.
Developers use the word “native” and “non-native” to describe the tools used to build an application. Think of trying to hang a picture. You could tamp the nail in using a brick, a pick axe, or a hammer. All of these options might work, but the hammer is “native” to the task at hand and clearly the best suited for the job. It’ll also work the quickest. Meanwhile, if you need to prop open a door, you’ll definitely want the brick. As you can see, the “native” tool is better for the first task but, pardoning a little damage here and there, the brick is workable at both.
The same concept above applies to code. If you’ve got an elegant design in-hand and are looking for the fastest way to build a functional prototype for multiple platforms (e.g. iOS, Android, and web), you could well choose a non-native tool that lets you write code once and run it on all three platforms. However, like using a brick to hang a picture, you’ll eventually hit a wall. The question isn’t whether you’ll hit the wall, but when.
In the context of mobile app development, native tools are those provided by the platform vendors themselves, such as Apple, Google, and Microsoft. In an attempt to differentiate themselves, each operating system vendor imbues its system with unique features, designs, and modes of operation. Have you ever picked up a friend’s iPhone and instantly recognized it’s not your Android phone? These differences are why. Native tools have direct access to the operating system without any limitations. This allows your app to go at its maximum speed while reaching every sensor, pixel, feature, and nuance of the underlying operating system.
Often, certain features are only available on one platform. Consider the action button on Android. That’s specific to Android and it’s very easy to add an action button to your app using native tools that are specific to Android, but providing a native experience for your users is much harder using non-native tools.
Where’s the wall?
Sometimes, the wrong tool can be used to great effect, but there’s a reason that a house built from plywood is “engineering” while a house built from matchsticks is “art.” If your app is at all sophisticated, you’ll grow out of most non-native tools pretty quickly, presuming they ever served your needs to start.
If your app feels at home on the operating system, your users will feel comfortable using the app. The easiest path to users’ hearts is to adopt the operating system design. By using the system’s look and feel, your users will be more fluent with your app, effortlessly navigating through screens without requiring guidance. While it is possible to achieve the same designs using certain non-native technology, doing so requires the same expertise, and time, you’d need to implement them natively.
Sometimes, non-native tools hold you back. In an industry where the speed of your app directly impacts user retention and revenue, this can be a major obstacle to growth. Subtle differences in the time it takes your app to load can drive users away. Customers notice delays that are literally shorter than the blink of an eye. In other words, milliseconds matter. Non-native tools often have complex internals that set a ceiling on performance. Meanwhile, native tools specific to the platform can be tuned for optimal performance.
The promise of non-native tools is one of efficiency. Non-native tools are the brick of software development. They’re versatile and ubiquitous, but ultimately a carefully chosen tool will always perform better. For some tasks, however, the brick won’t work at all. You need a hammer. And if you don’t have one, well, you’re out of luck.
That’s the situation you face with functionality that’s highly specific to the platform, like sensors, location tracking, notifications, and other features that differ a lot between iOS and Android. Non-native tools simply can’t perform these functions out of the box. Someone needs to put in the effort to hone them for each specific task. This is time-intensive, error-prone work that often requires rework following system updates.
Some non-native tools, like Xamarin, React Native, and even Adobe AIR, may appeal to your team because they’re built atop technologies familiar to web developers. Using a well known language and shared codebase across platforms can often speed the development of early product iterations and help you get to market cheaper and faster. Indeed, choosing a non-native tool can work well provided you spot obstacles on your product roadmap early enough. Nonetheless, you will eventually, inevitably, need to train or hire the talent to bridge native functionality. In fact, the burden of maintaining old non-native code sometimes justifies rewriting the entire app using native tools.
It’s about picking the right tool for the job. Know your requirements and identify the potential benefits and pitfalls of native and non-native development. Both can be excellent choices, but there’s no avoiding the need for deep expertise designing and developing for iOS and Android, individually. Non-native tools have their place and can be invaluable during early development efforts, but it’s important to keep a watchful eye on where they don’t quite meet your needs and if they’ll provide the best user experience. As the saying goes, when all you’ve got is a brick, everything looks like either a door or a nail.