Loading...
Answers
MenuStarting a new business: Hybrid application or native application?
Answers
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,
Nils
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
Related Questions
-
What is the best technology for developing a new mobile app from scratch?
There are two sides to that question. One is the mobile app itself and the other is the backend. If I misunderstood in any way and you didn't mean "native" app I apologize in advance. On the backend, there is no clear cut answer to which is the "best". It depends solely on the developers you are able to get. We for example use Node.js , mongoDB, redis, elasticsearch and a couple of proprietary tools in the backend. But you have your pick of the litter now both on the backend api and the datastore with the myriad of options available and touted as the "best" currently on the market. Now on the app side again it solely depends on what you need your mobile app to do. Experiencing first-hand "develop once, run anywhere" I can say it's more like "develop once, debug everywhere" to quote a Java saying. We have tried Phonegap and Titanium Appcelerator and we have switched to native (ObjC and Java) after a couple of months of trying to go the hybrid route. The reasons behind the choice are as follows: - anything that breaks the pattern of how those frameworks NEED to operate is just a huge technical debt that keeps accruing a huge interest. - anything that uses css3 accelerated animations on Android is buggy at best and slow as hell at worst on any lower (< 4.1 I think) versions of Android I hope this gives you some insight. If you need/want to ask me anything feel free to contact me. MihaiMP
-
I've been working on an app concept for 6 months and built an MVP. Is it better to pay a development firm to build or hire a developer as a cofounder?
I have built two software companies by hiring out the development work. I sold one for a decent sum during the dot com era (circa 1999). I remain a shareholder in the other one. I currently work with amazing development company on behalf of one of my clients. Here are some things to consider. 1. Do you really want to give up equity? If not outsource. 2. How fast do you want to get to market? If sooner than later, outsource. 3. How capitalized are you? If undercapitalized, either outsource offshore (which runs about 20% of US rates), or bring on an equity development partner. I offer a free call to first time clients. Let's chat and I'll give you some great advice from three decades of experience. Just use this link to schedule the free call: https://clarity.fm/kevinmccarthy/FreeConsult Best regards, Kevin McCarthy Www.kevinmccarthy.comKM
-
What is the generally agreed upon "good" DAU/MAU for mobile apps?
You are right that the range is wide. You need to figure what are good values to have for your category. Also, you can focus on the trend (is your DAU/MAU increasing vs decreasing after you make changes) even if benchmarking is tough. Unless your app is adding a huge number of users every day (which can skew DAU/MAU), you can trust the ratio as a good indication of how engaged your users are. For games, DAU/MAU of ~20-30% is considered to be pretty good. For social apps, like a messenger app, a successful one would have a DAU/MAU closer to 50%. In general most apps struggle to get to DAU/MAU of 20% or more. Make sure you have the right definition of who is an active user for your app, and get a good sense of what % of users are actually using your app every day. Happy to discuss what is a good benchmark for your specific app depending on what it does.SG
-
What tools to use for mobile Prototyping ?
My 2 favourite are: - www.uxpin.com - www.flinto.com Flinto is by far my favorite for mobile. I also us www.balsamiq.com for anything wireframe. Sometimes I jump into Sketch http://www.bohemiancoding.com/sketch/ for more high fidelity mockups using their Mirror feature http://www.bohemiancoding.com/sketch/mirror/ Hope that helps. P.S. There's a tonne of Mobile UX experts on Clarity, many $1/min - call them, you'll learn so much. my2cents.DM
-
Any opinions on raising money on Indiegogo for an app?
Apps are difficult to fund on IndieGoGo as few are successful, and we rarely take them on as clients. Websites like http://appsfunder.com/ are made for that very reason, but again, difficult to build enough of a following willing to pay top dollar for an app that could very well be free, already existing in the marketplace. A site that is gaining more traction you may want to look into would be http://appsplit.com/. Again, Appsplit Is Crowdfunding For Apps specifically.RM
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.