02.25.21Kotlin (Android) Swift (iOS) React Native (iOS and Android)
IS NATIVE WORTH IT?
While there are plenty of benefits to building your next mobile application natively, there are several alternatives worth considering. Depending on your budget, timeline, or other considerations, it may make sense to move forward with a more “hybrid” approach.
There are many different ways to build a mobile application, and depending on your overall needs, a natively built app might be overkill. Let’s break down the pros and cons of native app development and examine what types of apps you’d definitely want to consider building natively.
FIRST THINGS FIRST, WHAT IS NATIVE DEVELOPMENT?
For those unfamiliar with mobile application development, let’s first define what native truly means. We refer to native mobile apps as any app developed with a specific programming language for a specific operating system. Examples would include the language of Objective-C and/or Swift written for iOS or the language of Java and/or Kotlin for Android. The languages are written specifically to interact with native OS APIs and provide direct access to the latest and greatest features provided by each platform.
Native mobile apps feature several advantages, but let’s focus on the big three:
Let’s start with performance. Being so tightly integrated with the OS, native apps are the most stable and fastest performing applications on the market. Development tooling provides greater details and access to the smallest of issues within your codebase. Also, being written for an OS provides direct access to native APIs providing the fastest possible performance during the most complex tasks.
With better performance, comes better scalability. As your user base grows, that’s when your app will be tested the most. The smallest of bugs can suddenly become massive and the need to address issues at an OS level become greater and greater. Native development tooling, again, provides the greatest access to what is truly causing issues in your code.
Finally, let’s not forget the user experience of each platform. Small differences in the way buttons press, text boxes are rendered, or navigation is executed provide users with a unique but yet familiar experience when interacting with your app. Native applications give users direct access to the latest and greatest experiences that may take months to be supported on a cross platform solution.
With native comes a few drawbacks however. The top 3 negatives here include:
- Multiple codebases
- Development effort
- Specialized development
Native development is fantastic, but it leads to the maintenance of two separate code bases. The mobile apps are capable of being built in parallel, which could lead to a quick build time, but the app does need to be built twice! In maintenance, if you need a change made to the app, it will likely need to be made twice.
Without sharing any code, the development effort and cost of native development is inherently higher. If you wish for features to be built/released at the same time, they would need to be built in parallel with two separate development teams. The alternative is sequential development which can draw out a development timeline to be twice that of a single, shared-codebase application.
ALTERNATIVES TO NATIVE
While there are plenty of benefits to building your next mobile application natively, there are several alternatives worth considering. Depending on your budget, timeline, or other considerations, it may make sense to move forward with a more “hybrid” approach. Hybrid mobile applications are built using a single, shared codebase for both iOS and Android. This shared codebase approach drastically cuts the time and effort required to build two versions of the same app which, in turn, can lead to a much less expensive product to build.
What about quality, you may ask? Hybrid applications have the luxury of compiling into truly native, mobile components. This means that though the code isn’t necessarily native, you still get the performance and usability as though it were. iOS buttons will still look and feel like iOS buttons and likewise, Android buttons will look and feel like Android buttons.
Quicker, cheaper, and quality! What’s the catch? While there are a lot of positives to building hybrid apps, they do start to fall down when dealing with more complex native OS APIs. Remember, our definition of native, “developed with a specific programming language for a specific operating system.” When an app is sharing code, that code inherently isn’t written for a specific operating system. This leads to specific OS features being left out of the hybrid framework. In order to combat the framework not including specific features, developers will need to create custom APIs to bridge the gap of the framework. This could potentially lead to higher development costs than if you were to have simply built natively.
When approaching a new mobile app, we like to look ahead and examine the complexity of the application. If we foresee the app needing complex, OS-level features, then we will likely steer you the native route to alleviate any future pains when implementing those specific features. Generally the more complex the application, the more you’ll want native for the long haul.
Here at Shift, we ultimately approach each product brought to us on a case by case basis. It may be difficult to identify when a hybrid or native approach is best, but that’s what we are here for. We'll recommend the ideal solution for your unique product so that you can be confident you are putting forward the best mobile app possible!
Let us help you with your latest mobile application needs here. We can’t wait to help you improve your mobile presence!
This article was written by Clayton Brady, Director of Innovation at Shift.