I am planning to test an idea in the area of classifieds/aggregation. I want to develop features fast - so that feedback from users can be used to direct the product improvements & features.
In that context, I am leaning towards a hybrid application (Using Ionic/Framework7/OneSen UI or similar). I would like to understand the impact of having an hybrid app on user experience. Also as of 2015 - can you not still use Camera & GPS using Hybrid apps? Camera and GPS are features I would like to have in my app for some of the functions.
Native is not much of a choice as in the past I have had challenges finding the right people and turning around features fast. Also, we might have a website but most of the features will be driven from mobile only.
I come across this question daily with my clients. From experience, it's usually best to go Hybrid on your first iteration.
It all boils down to validating your product and getting traction. Your quickest way to do that is to put a product out in the market quick.
Most frameworks for Hybrid apps (Phonegap, Angular, Ionic..) are really mature at this point and allow you to build an app at a significant fraction of both cost and time than going fully native.
Once you've validated your idea, if it makes sense to go native (and if it will provide ROI), by all means go native.
I would suggest you to go with ngAngular (http://ngcordova.com/) as it is a fast way to get things done quick. There are a lot of plugins that are good to go out of the box, including Camera and GPS.
This is a really common and interesting question. I run a team of native and hybrid developers, so it's very close to my heart. It doesn't have a black and white answer, even in 2015, but I'll try and help you move forward.
1. Camera and GPS functionality is now readily available to hybrid apps.
2. ionic (based on Angular and Cordova) is a good choice of framework to work with
3. In general, a hybrid approach is most viable for fairly standard content-driven apps with limited interactivity. If you are dealing with video, large images, endless lists, large data storage or complex interactivity, I would recommend native.
4. Performance issues often only become apparent on lower spec handsets and may be be masked during development by testing solely on new high-end phones.
5. Developers. Going hybrid will not magically solve your developer problems for you. If you have a great hybrid developer and you decide your app is viable, then by all means go ahead. But choosing hybrid simply to achieve faster turnaround is not going work. It's arguably harder to find a good hybrid developer, as they need to understand mobile performance and development on 2 platforms. Furthermore there is nothing inherently faster in the development process, where it saves time and money is in porting an app to a second platform. Since you are at an early stage of product development, I would consider a single platform launch while you finalise your business model, so the perceived advantage of hybrid is reduced even further.
To summarise - first and foremost, find a reliable mobile developer that you feel you can work with well. Provided your app passes points 3 and 4 above, at this early stage of development the technological implications of hybrid vs. native are less important than who you pick to join your team.
I'd be happy to discuss specifics of your app on call in more detail, please get in touch.
Best of luck,
My team delivers both native and non-native applications - generally the answer to this question is dictated by three separate considerations 1) what are the core pieces of functionality required for the user? 2) what are the resource realities you are facing (i.e. budget and timeline)? and 3) what is your access to recruiting native mobile developers.
You are correct that the first and most important impact a non-native application has is on user experience. pagination, the swiping feature and all of that other rich mobile UX cannot be replicated on a non-native system. UX driven mobile applications are by nature of their layout more inclined to be better supported on a native platform.
The second point you bring up is the consideration of utilizing native device functionality (Bluetooth, Camera/Library, Contacts, GPS etc) - as of right now there are ways to integrate with several of the native hardware features in an non-native environment, however their actual working integration can be a little jerky and in most cases does not fully replicate the actual phone functionality you would get in a standard native mobile app.
Importantly there is another consideration to make for dictating the native vs non-native app decision: that is the need for any level of offline functionality of caching. Being a browser-driven experience, a user not having wifi access or reliable cell network connectivity makes accessing your application either time consuming due to delay on loading content, or impossible if truly offline. So caching content and offline access a lot of times become a major factor as to whether non-native is even possible for an application.
One other bonus point to consider: analytics - going native gives you a fairly usable and ready-made dashboard for base-level analytics on your app (just log into your developer account and start consuming download and utilization data) - your options for non-native analytics are more limited, at least for what you got out of the box (usually Google Analytics is the best bet there.)
Overall there is a fairly quick checklist of items you can walk through and get a quick indication to what extent (or not) non-native is a solution or option. My general preference is to lean towards native (look at Facebook and LinkedIn as good case studies - both launched non-native first and quickly realized they had to go native to be relevant and get the MAU they wanted); but i would do a quick analysis and put some thought behind detailing scope/options from there.
Happy to carve out time for a call and walk through details of your functional requirements and see if/how native or non-native solutions would be the best path forward. Just request a call time and we can touch base from there!