This article was originally posted on my companies blog site found here
When we are talking to customers, either new or existing, we often get asked about the best way to develop mobile apps for both Android and iOS. For many years the options were native versus hybrid. More recently these options have become more complex. The typical reason we get asked this question is that companies are looking to reduce the price of mobile app development. We feel that there is much more to consider in this decision than just the price of development, it’s the true cost that needs to be understood.
At Chariot Solutions, our Mobile Practice focuses on native application development. We didn’t start out with that approach. We worked on native and hybrid apps for our clients. What we have learned over the years is that native simply works best. Sure, for very simple, basic mobile apps it might be worth considering an alternative approach. But we have consistently found that apps that start as hybrid end up suffering from shortcomings that result in sub-optimal user experience or require significant work arounds and even potentially complete re-writes. Based on these experiences, we prefer to focus our efforts on native development resulting in a highly performant, beautifully designed mobile application for our client’s users.
What is Native, Cross Platform, and Hybrid
In order to understand all the aspects of deciding what direction to go with your mobile app development approach, it is important to understand each option and the advantages and trade-offs each has to offer.
At a very high level, native applications are written in a programming language supported by the platform provided SDKs (Software Development Kits). Hybrid and cross platform applications are written in essentially a single programming language and use framework provided software layers to allow developers to generate a user interface and provide access to underlying device features. While this sounds good on paper, the diagram below demonstrates the additional complexity that comes along for the ride.
The following sections provide more detail around the different mobile application development approaches.
Native Mobile Approach
Native mobile apps are written with platform specific languages to directly access the manufacturer provided SDKs. For iOS, this means writing in either Objective-C or Swift, and for Android the language options are either Java or Kotlin. Within iOS and Android, each of their supported languages interoperate with the other.
- It is not possible to exceed the performance of a natively developed application.
- Immediate access to all platform features via native SDKs (e.g. bluetooth, AR, machine learning, etc.).
- The similarities between Apple’s Swift and Android’s Kotlin languages make it much easier to cross-train developers and to port the application code between the two platforms
- More mature tooling in terms of UI development, debugging, and profiling
- Easier to support multiple device sizes and orientations through the use of provided tooling
- Built in support for non-phone device types (wearables, TV, Car, etc.)
- Developers need to be familiar with different tool sets
- Two languages to learn when cross training developers
- Maintaining two code bases
- One programming language to learn
- Shared code for business logic
- The same developers and code modules could be re-used for web development. This is a comment we hear often, but rarely works in practice.
- Sub-optimal UI performance
- Reliance on frameworks and the support they will have moving forward
- Frameworks are so numerous and evolve so quickly that code written 2-3 years ago can become obsolete and riddled with security and performance issues
- Difficulty in integrating new versions of the frameworks
- There are more layers of software in the application, which makes debugging and troubleshooting more difficult
- Tooling is less sophisticated
- UI/UX tends to blur between iOS and Android, or forces code branching (i.e. if android do this, else do that) throughout the code base in order to differentiate each of the user experiences
- User Experience can suffer if you decide to stick with common design patterns from one platform; Android users sometimes get offended if your app looks like an iOS app or vice versa.
- Plugins required to access native OS/device features, which might require a native developer to implement
- Delayed availability of new platform SDK features
Native Cross Platform Approach
- One programming language to learn
- Shared code for business logic
- Near native UI performance
- The same cons as hybrid, plus the following
- Steep framework learning curve. While there is a learning curve for native, that skill will still be required when using a cross platform approach. More on that later.
- Reliance on the framework providers to continue to exist and evolve along with the native platforms
Mobile App Development Considerations
Now that we understand what each option actually represents, we need to look at the various considerations that go into choosing a mobile app development approach. Most of these considerations go beyond the “development cost” that people speak about. These include things such as the importance of mobile to the overall business strategy and goals, what platforms are really required by your user base, how complex the app is for both business logic and user experience, and the developers you have on staff. Below is a high level comparison of each approach, with the underlying details following the table.
If your mobile applications are core to your business, then the only real option to consider is native. The user experience quality and performance obtained when developing a fully native app simply isn’t achievable with the other options. How is mobile core to your business when you don’t have a mobile product? As an example, one of our clients is in the home security space. Their main focus is the security system and its sensors and cameras. But the mobile applications provide the user the ability to control the system as well as providing a view into its current state. This makes mobile core to their business. Maximizing UI performance is critical to the user’s happiness and therefore the success of their product.
One of the first questions businesses need to ask about their mobile apps is “Who are the users?” In some cases the answer is “90% of the user’s have iOS devices”. One of our clients came to us with a hybrid application that was suffering with significant performance and usability issues. Their clients all used iOS devices (iPads). For their initial version, they chose hybrid “in case they need to support Android someday.” Our recommendation to them was to develop an iOS app optimized for the platform and taking full advantage of what it has to offer. If an Android app is needed somewhere down the road, given the similarities between Apple’s Swift and Android’s Kotlin, it’s pretty straightforward to port the app over.
Another consideration with respect to platform support is access to device specific features. A good example of this is augmented reality (AR). Apple introduced AR to their SDK with the release of iOS 11. Native apps that want to take advantage of this capability could access it immediately, while hybrid or cross platform apps needed either native plugins written or would need to wait for the capability to be added to the relevant framework.
When it comes to application complexity, there are really two levels: UI/UX complexity and business logic complexity. UI/UX complexity can include things like compound views, custom controls, complicated transitions, the need to support non-phone device types (e.g. wearables, TV, car, etc.). The more of these types of complexity in the application, the higher the need is to take a native approach. UI/UX performance is one of the most important attributes of a mobile app. It directly impacts the user’s perception of the app and therefore the overall success of the app.
If the business logic for an app is complex, we will typically recommend moving that logic out of the app and into the cloud or some other server that can be accessed via an API for all clients, mobile or otherwise. If this cannot be done, this doesn’t mean hybrid or native cross platform is your only option. There are cross platform tools like KotlinNative, ElectrodeNative, J2ObjC, C/C++, etc. that can allow complex business logic to be written once and shared across native apps. Also, with the similarities between Kotlin and Swift, porting complex business logic from one platform to another isn’t as difficult as it once was.
The type of developers you have, or want to have, on staff is extremely important. While native cross platform and hybrid may require developers to know only one language, the reality is that platform experts are going to be required for each platform on which your app is released. There are numerous differences between the platforms in terms of what device features and functionality is available or unavailable on each. Unless you go with a full native approach, plugins will be needed to access some features. And during development, bugs and build/distribution issues will creep up. Any of these things can happen and will require deep platform specific knowledge. For good developers, language is mainly about syntax, but good platform knowledge is much more than just syntax. It’s understanding the various capabilities of each platform, their restrictions or limitations, and their UX paradigms.
In the End, We Choose Native
There are multiple options when it comes to building mobile applications. Deciding on the proper path for your application is about more than just the line item cost of development. Many considerations need to be assessed when determining the actual cost of development. Ultimately you need a highly performant, beautifully designed mobile application for your users. My goal is to make sure your users have exactly that. Contact me to help you determine the right path.