A few weeks ago, I posted on the trade-offs between native, hybrid and responsive approaches to mobile development. A recent article by Roi Kraus in Techcrunch delves deeper into the subject. His conclusions are:
- Choose hybrid which is faster and cheaper to execute if you don’t need native functionality,
- Go native if you need to use extensive communication, access lots of data or use many of the phone’s onboard components (like graphics, GPS, etc.).
- If you go native focus on one platform first to avoid managing multiple developments simultaneously,
- Focus on user expectations rather than business needs in choosing which way to go.
See the whole article here: From Native To Hybrid App Development And Back
A number of startups I work with ask me about whether it still makes more sense to invest in a full-blown mobile app rather than focusing on a responsive website or a hybrid app.
- A responsive website is one that presents a specific layout for each width of screen (often called a “break-point”). The huge benefit of the responsive appraoch is that people can access your service without installing anything and you don’t have to develop different versions for each operating system.
- An application, often called a “native app”, runs software optimised for the device which optimises performance and reduces what needs to be downloaded from the net. Apps have access to device functionality that is unavailable to responsive websites (eg. location) and they are usually feel snappier. You do however have to develop for each operating system which can mean for a lot of work since there are four major mobile operating systems.
- A hybrid app is a mix of web and application. Some functions run locally on the phone, notably things that are not accessible from the web, while others are pulled from the net. A key benefit of this approach is that you can share a common development for web and hybrid app, deployment across multiple devices is much simpler and it is easy to update functionality without updating the app. The downside of this approach is that user experience is not as good as the “native” experience and performance can be slower due to the reliance on the network.
With the above in mind, deciding on what to do depends a lot on whether the primary usage of your service is to be on mobile devices or not and whether success depends on the sophistication of the user experience. Here are some questions you can ask yourself;
- Demographics: What is age and mobile usage of your target group?
- Installation: How would users find out about an app to download it? Are they more likely to look at a website?
- Updates: How often will you need to change the way the app works?
- UX: How much does the success of your service depend on the UX itself?
- Functionality: Do you need to acces functions on the terminal that require an app?
For example a game that requires fast response-time and really slick user interface will probably opt for native development. An information site which does not need to use the phones local features may be better off going with a responsive approach. A professional app that needs to track location, stores information locally and has frequent functionality changes to meet evolving business needs but which does not need a sophisticated user experience may go for a hybrid app. The following table may help;
|Responsive||Native App||Hybrid App|
|Update||Transparent||App install||Usually transparent|
|Access to local features||No||Yes||Yes|
|Multiple OS support||Yes||An ap per OS||Much can be reused|