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.
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!
Your mobile device is with you, quite literally, every minute of the day. And if the device is with you constantly, it needs to be responsive and reliable, giving you the answers, you need as soon as possible. These are the expectations of all mobile users. Nobody has time for bad user experiences, your customers and employees included. While there are a lot of advantages to using hybrid, customer experience for mobile should be a primary consideration. By looking at the key differences between the two development frameworks, we argue that despite the original higher investment, most companies will be better off choosing native instead of hybrid in the long run. Your users will EXPECT a great experience. Even the most vocal advocates of hybrid applications are forced to admit that native applications win the war in performance. A native app is faster and more reliable by its very design. As users navigate a native mobile app, the contents, structure, and visual elements are already on their phone, available for instant loading, and thereby providing a seamless experience. This is akin to downloading most of a website’s static content to a user’s phone at once which is then available for instant loading regardless of their phone’s internet speed. In contrast, a hybrid app has only a wrapper that is downloaded to the user’s phone with most of the data being loaded from the server. Experts agree that, despite all efforts, hybrid applications take a hit in the performance war. There is no indication the DOM will ever be fast enough, and if it does happen its light years away on mobile. More than experts, users also agree with this assessment with 84% of users considering performance to be an important or especially important factor. User experience is the key to an application’s success. At that time, most websites had a poor user experience, so it was not a differentiator. In contrast, today’s software development is all about the user experience. Once users learn how to use their devices, they do not want to have to absorb new features specific to other apps. Users just want to keep using their phone in the way they believe all apps on their phone will operate from a navigational and interactive point of view. This means that the application’s controls, interactions, visual cues, and gestures must be seamlessly integrated with your platform’s extensive style guide. All this background is needed to understand the user experience trade-off when choosing between native and hybrid options. As a company embarks on the task to build a new app, the user experience specific for that OS becomes of critical importance to the mobile presence on the market. When launching a hybrid application, that app is platform agnostic. That means hybrid apps are easier to build, take less time to market and need only one code base. With a hybrid application, the user does not usually need to update the app in the app store. Additionally, when you are deciding whether to go native or hybrid, you need to bear in mind that native has certain advantages which simply are not currently supported by the hybrid mode of development. Single code base across multiple platforms. Do not need to do any API development since it is all handled via the web. Today, Mark Zuckerberg revealed that Facebook’s mobile strategy relied too much on HTML5, rather than native applications. If you have less than four months to develop an app, and you want to test a limited private market on the viability of your app, then use Hybrid. If the test works, then move to native as soon as you can and show it to the world. Speed to market, one source code, cross-compatible web technologies, easy updates, availability of resources, and lower budget costs make hybrid applications very appealing. Additionally, native apps have the added advantage of functions that are specific to the OS on which the app is built. Furthermore, a native approach offers the best in class security for a mobile application, the best performance, a highly responsive user interface, and access to all native APIs.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath