Part of what attracts developers to hybrid apps is the freedom of choice we get from building on open standards supported by the community of our fellow developers but this very freedom can also be intimidating at times!
To help make sense of the wild and wooly landscape out there we’d like to introduce our new monthly blog series: “Shipping Code”
Our “Shipping Code” series will be running over the next year and will cover the entire hybrid app development cycle from beginning to end.
The process of shipping a new mobile app from scratch is complex and you’ll run into many different questions on your journey.
What we will try and do is to fit those questions (and some answers!) into a cohesive picture which, we hope, will assist both new hybrid developers and even old hands to locate themselves in the happy chaos of modern mobile app development.
Introduction: The Three Mobile App Strategies
As a developer you have three broad strategies available to you if you want to develop an app which runs on a mobile device:
- Mobile Web App
- Native App
- Hybrid App
We’ll be kicking off our series on hybrid app development by examining some of the pros and cons of each approach.
Strategy 1: Mobile Web App
The easiest solution for getting your application onto a mobile device is to simply develop it as a web application.
The primary difference is that it will be accessed via mobile device’s built-in web browser which may require you to apply responsive web design principles to ensure that the user experience is not degraded by the limited screen size on mobile.
There are a number of limitations to this approach but the biggest is that you will only have limited access to device API’s, features and integration with other apps on the user’s device.
- Few, if any, technological differences from any other web site or web application.
- Maintain a single version of your app for both mobile and desktop versions.
- You can easily ship new versions of your app by updating the remote server.
- The cost of applying responsive design principles to an existing website may be a significant fraction of developing a mobile app.
- Your app will not be available on mobile app stores which may make it hard for users to find it.
- Mobile device browsers have historically lagged behind their desktop counterparts, this can create compatibility issues on mobile devices with parts of your app not behaving as required.
- Limited access to device features.
Strategy 2: Native App
Native Apps exist on the other extreme of the scale. They are developed using the device’s native SDK’s.
On Android this usually means writing your code in Java using Google’s Android SDK libraries. On iOS you’d be working in Objective-C or Swift using Apple’s iOS SDK libraries.
This is unquestionably the most powerful approach as you are able to access all features of the device and make use of the native UI components of the device.
The biggest downside is that you’re going to need engineers with the skills required to maintain two separate platform versions of your app, one for each device you want to support.
- Access to all device API’s, features and inter-app integration.
- Full control over the user experience allowing for complex experiences such as gaming or content creation.
- Your app will match the native look & feel of the device without requiring a 3rd-party UI library.
- Your app will be available on App stores.
- Development costs are high and can take orders of magnitude longer to ship due to the low-level nature of the device SDK’s.
- You need to write and maintain a separate version of your app for each device you want to support.
- Developers need to learn multiple different programming languages and API’s with steep learning curves for each version of the same app.
- Slower development time.
- Bugs are more likely to crash your app (or even the device!)
- Harder to debug errors & crashes
- Shipping updates can be slow due to the app store approval processes.
Strategy 3: Hybrid App
Hybrid apps occupy the space in the middle of the previous two extremes. They enable you to use standard web technologies to develop your app whilst, simultaneously, having access to the native API’s and features of the device.
While they have somewhat of a reputation for not being competitive against their native counterparts the present reality is that we continue to see more and more world-class apps that shipped with a Hybrid App strategy.
There are many more good reasons to choose a Hybrid App for your project but there’s one factor which stands out above all else:
Shipping and maintaining a Native App on both Android & iOS is going to cost you, at the very least, twice as much as a Hybrid App.
…and this is assuming that you and/or your team are already well versed in Java, Objective-C, Swift and the Android & iOS SDK’s!
- You can use most of the same technologies and tools used for web development to create a mobile app.
- Maintain a single codebase for both iOS and Android versions of your app.
- You can re-use many components of any existing web apps you may have.
- Your app will be available on App stores.
- Easily ship updates to your app without requiring App Store approval with Trigger.io Reload.
- Access to device API’s, features and application integrations via native modules.
- Modern web-technologies such as CSS Transitions and WebGL allow you to achieve near-native UI performance even for complex user interactions.
- Excellent development tools courtesy of Chrome & Safari remote debugging.
- Achieving a native look&feel depends on 3rd party frameworks which may vary in quality.
- There are many different ways of doing things and it can be hard to know which approach to follow up front.
- App performance can suffer if you are not conscientious.
- Accessing some native device features may still require you to write portions of your app in native code.
In this, the first instalment of our “Shipping Code” series, we looked at the pros & cons of the three strategies for mobile app development: Mobile Web App, Native App and Hybrid App.
In the next instalment of this series we’ll be taking a look at the different architectural choices you need to make when developing your Hybrid App.
Until then, if you have any questions about the material we’ve covered so far or suggestions for future instalments, we’d love to hear from you at firstname.lastname@example.org.