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
-
Whats are some ways to beta test an iOS app?
Apple will allow a developer to register 100 UDID devices per 12 month cycle to test via TestFlight or HockeyApp. Having started with TestFlight, I would really encourage you NOT to use it, and go directly to HockeyApp. HockeyApp is a much better product. There is also enterprise distribution which allows you far more UDID's but whether you qualify for enterprise distribution is difficult to say. As part of your testing, I'd encourage to explicitly ask your testers to only register one device. One of the things we experienced was some testers registering 3 devices but only used one, essentially wasting those UDID's where we could have given to other testers. Who you invite to be a tester should be selective as well. I think you should have no more than 10 non-user users. These people should be people who have either built successful mobile apps or who are just such huge consumers of similar mobile apps to what you're building, that they can give you great product feedback even though they aren't your user. Specifically, they can help point out non obvious UI problems and better ways to implement particular features. The rest of your users should be highly qualified as actually wanting what you're building. If they can't articulate why they should be the first to use what you're building, they are likely the wrong tester. The more you can do to make them "beg" to be a tester, the higher the sign that the feedback you're getting from them can be considered "high-signal." In a limited beta test, you're really looking to understand the biggest UX pain-points. For example, are people not registering and providing you the additional permissions you are requiring? Are they not completing an action that could trigger virality? How far are they getting in their first user session? How much time are they spending per user session? Obviously, you'll be doing your fair share of bug squashing, but the core of it is around improving the core flows to minimize friction as much as possible. Lastly, keep in mind that even with highly motivated users, their attention spans and patience for early builds is limited, so make sure that each of your builds really make significant improvements. Happy to talk through any of this and more about mobile app testing.TW
-
Pre-seed / seed funding for a community app... valuation and how much to take from investors?
To answer your questions: 1) Mobile companies at your stage usually raise angel funding at a valuation equivalent of $5,000,000 for US based companies and $4,000,000 to $4,500,000 for Canadian companies. 2) The valuation is a function of how much you raise against that valuation. For instance, selling $50,000 at $5,000,000 means you are selling debt that will convert into shares equal to roughly 1% of your company. 3) I would encourage you to check out my other answers that I've recently written that talk in detail about what to raise and when to raise. Given that you've now launched and your launch is "quiet", most seed investors are going to want to see substantial traction before investing. It's best for you to raise this money on a convertible note instead of actually selling equity, especially if you are intending on raising $50,000 - $100,000. Happy to schedule a call with you to provide more specifics and encourage you to read through the answers I've provided re fundraising advice to early-stage companies as well.TW
-
If I am planning to launch a mobile app, do I need to register as a company before the launch?
I developed and published mobile apps as an individual for several years, and only formed a corporation later as things grew and it made sense. As far as Apple's App Store and Google Play are concerned, you can register as an individual developer without having a corporation. I'd be happy to help further over a call if you have any additional questions. Best of luck with your mobile app!AM
-
iOS App: Beta vs Launch Quietly?
I would suggest launching in a foreign app store only (ex: Canada). That will allow you to get more organic users to continue iterating without a big push. I got this idea from Matt Brezina (Founder of Sincerely, previously Xobni) https://clarity.fm/brezina - he's the man when it comes to testing & iterating mobile apps.DM
-
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
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.