When creating a digital product, making the right decisions at the right time is key. Sure, things change but certain decisions, such as what operating system you’re building for, should not. Deciding whether to build your app native or hybrid is a decision to make up front.
My name is Thiago and I’m a front end web developer at Mobiddiction. Here’s my point of view on things to consider when making such a decision. To go hybrid or native, that is the question. I hope the following will help you to make a more informed decision.
What’s The Difference?
- Native Applications are written in programming languages specific to their platform. Most Android applications are built using Java. Most iOS applications are built using Swift. From a build point of view each requires different expertise from the other. As such, you’ll need two dev teams, one for IOS, the other Android;
- Unlike Native, Hybrid Applications are not written specific to platform. They are more like web sites that scale and optimise to requirement. Again, unlike native that need two types of development expertise, hybrid requires one.
So, at first glance it seems like a no brainer. Why go native and build twice when you can do it once with hybrid?
Your Consideration Set
What’s best for you depends on many things. Time, budget and capability are a big factor but ultimately what (should) matter most is your customer. Here are some of the pros and cons of native versus hybrid applications.
To Go Native
- PRO – Speed of user experience: Native apps are designed specifically for the system on which they operate (Android/IOS). They are designed and built to work harmoniously with the technology to deliver quick, fluid and seamless interactions and experiences;
- PRO – Access to API’s: All the APIs and functionalities that the platform offers can be easily accessed in the native development environment. There is no layer translating the functionalities to the hardware and no restrictions or dependencies besides the ones of the native environment;
- PRO – Long-term specs: Over time there will be updates and changes in the APIs (API stands for Application Programming Interface, are a set of subroutine definitions, protocols, and tools for building application software) or even your operating languages like when Apple switched from Objective-C to Swift.
Objective-C and Swift are programming languages used by Apple for the OSX and iOS but these changes often offer a backward compatible and usually it comes with guides for how to port between these changes.
- CON – Specific Build Requirements: Native apps need to be built using code and software specific to their operating system. For example, we build for IOS using SWIFT and for Android using JAVA. As you can imagine when you’re building for both, things can get complex. At Mobiddiction we split into teams, one for each operating system but work collaboratively;
- CON – App Updates: Because native apps, especially Android are built to many different screens, sizes and specification, any change or updates required must be applied across the board. It’s definitely not a one size fits all approach and this could potentially take time and your budget away;
- CON – Framework Own Rules: Native platforms define their own rules and frameworks and many businesses with existing development (ie. web, desktop app, etc) personnel, they would be unable to utilise these existing resources.
To go Hybrid
- PRO – Unified Development: The code is written once and once only. Unlike Android and IOS there’s no complexity or variation to account for. As such hybrid apps are at times easier to manage and maintain;
- PRO – Native Feel: Great framework projects like Ionic or React provide tools and abstraction layers that facilitate to make a web view act and feel like a native application and they can be distributed on the App Store’s;
- CON – Limitation of Choice: Unlike native applications there is a greater limitation as to what can and cannot be done in hybrid. A hybrid build must select the best from available functionalities to deliver a desired outcome:
- CON – Fluidity of Experience: Hybrid applications (at most times) will not deliver as fluid an experience as native. Motion graphics may feel more forced, touch interactions less responsive. So, if customer experience needs to be considered very carefully before you make your choice:
- CON – Debugging: The layer that sits between the chosen framework and the native functionality makes debugging a potential nightmare. Developers have to rely on the frameworks to play nicely with the targeted operational system.
The pros and cons speak for themselves. Sure, native looks and feels better but it could cost more and may take longer to build. Hybrid works across all platforms but this can be at a cost to the end user. We recommend you experience for yourself apps developed both natively and as hybrid before making your choice.
These are but some of the things that will no doubt shape your decision making and next steps. With the speed at which technology continues to advance I think hybrid is going to become much more comparable to native. Already I’m seeing new and exciting open source frameworks like React native, Cordova, NativeScript, and Ionic being built, making it possible for hybrid solutions to use more native features and this is only going to progress.
The mobile ecosystem changes faster than we’d like to believe and if this sound like a lot of information, it’s best to get an expert to review what is it that you are looking to achieve. So, if you are stuck between a rock and a hard place and need to make a call between going hybrid or native, give us a shout and we’ll be sure to direct you in the right direction. We have a some passionate people and often have this debate at work.