I recently stumbled onto a forum discussing the pros and cons of both Native and Hybrid apps at that point i didn't even know hybrids were a thing, i only knew the existence of web and native apps
I have an app idea that i plan to develop and build a business around. I hear that Hybrid apps are generally cheaper to develop which is a plus as i don't have a large budget. Would it be wise for me to pursue developing my MVP as a hybrid app thus it would allow both Android and iOS users to use the app or should i focus on building a native app?
The area i plan to start the business has predominantly iOS users so if i were to go the native route i would develop iOS first
Another thing has anyone had the chance to experience Hybrid apps? The app itself would be rather simple involving sign up,login, Main function on user/customer end
I would love to hear your thoughts on this
Hi Roman, that's one of the questions that people keeps asking all time now. And guess what, it has nothing to do with the app functionality at all :D .. strange right, ok let me explain more.
The keyword is the system structure itself, whether you're using native or hybrid will face the same issue if you're not doing the right architect. Native development will expire sooner that anyone thought and Hybrid development is evolving with new technologies that matches if not exceeding the native one (React Native, Flutter) Uber is developed using Hybrid by the way. I've been designing and developing mobile applications since 2010 started with Native and then in 2013 moved to Hybrid passing by Titanium, Ionic 1,2,3 and 4 React Native, and nowadays we're moving to Flutter.
We're developing mobile applications that cannot be differentiated from Native and using all the mentioned techniques, Location Based, Video Playing, Navigation and also running in the Background. We've even used a mix between Flutter and Machine Learning (ai) in one of our applications can send you a link if you want it's available now on google stores. We've also developed an Uber like app to one of our customers using Ionic and NodeJs as backend development.
So back to your question, the answer is the right architecture to your system from the cost wise it will be much cheaper to be Hybrid as it requires 1 developer for the mobile not 2 and off course the cost of maintenance and enhancement will be less.
Hope my answer gives you a clear answer to your question and I'll be more than happy to go for a bet proofing my words :D
I have experience using both hybrid (ionic, xamarin) as well as native apps.
What is better depends on what your app should do (I will go for native for anything that uses location, needs to run in background, requires highly interactive UI, plays music, or has complex communication with server or lot of data in the screen).
The hybrid apps will be good for apps with simple menu, more data reading / displaying than user interaction, similar to web app but faster and smoother). No background run, minimum notifications, etc)
feel free to dm for more details
In case it's MVP stage only why even bother for 2 platforms? You can establish the product idea with one platform itself and if you think it's most apt for iOS users than go for the iOS native from the beginning and scale up later. In later stages when you need to scale up, you would have iOS already covered with the native app.
Theoretically, hybrid saves on coding time with 70-80% common codebase but in practical experience, I didn't got any significant advantage due to the tweakings required to achieve that last mile compatibility for 30-20% balance part of the project. This balance compatibility will become more cumbersome to achieve with rising complexity.
In case, user experience is your priority (which ideally should be unless its some government app) and you want to try the MVP first than go for native with any of the chosen platforms from the word go.
Hey Roman, I see you already got a few answers. I’d like to add that, if you do go the Hybrid route, be prepared to create certain modules that are native. For instance, let’s say you want to access Health data and you are building your app on React Native; then you’ll need to integrate some native code.
I don’t mean to discourage you at all, I use React Native for prototypes (and production apps) all the time, but be mindful that in order to deliver a good quality app, it’s likely you’ll need to get close to the platform you develop for.
I would back up even further with your question. Why a (mobile) app at all? Does the thing you're developing really require direct access to device functions? Could it be a web application/site?
Before you decide on a plan of attack, best to understand why you're choosing a certain route, whether customers are willing to download anything to perform this task in the first place, does it require the user to choose a mobile device instead of a desktop? Test your marketing strategy, test your other assumptions, and determine whether it should make any difference what operating system your customers choose at all as to how much the tool appeals to them.
Who the heck cares what you write it in if it is something people actually want and can't get another way, it works well, and they're willing to pay money to use it? Sure you have to consider the development costs, but also consider the maintenance costs. The farther you are away from OS/Device specific programming, the less it is going to cost you in the long term. If your tool will still work as web-based, go that route.
This is a question a lot of entrepreneurs agonize over with and in 95% of the cases the answer is not to build an app at all, but build a responsive and reactive website. In fact, you should start with website as the default option and build an app only if absolutely necessary. For most cases, an app is not necessary, yet adds extra friction for the user as they have to find and install the app.
In the early days of mobile devices, people built apps at the drop of a hat, with the (in)famous slogan "there is an app for it." This was needed because of the form factor difference between computers and mobile devices.
Responsiveness - i.e., websites that change their dimension based on the device - made a large number of these apps irrelevant and obsolete. Apps built by every only newspaper and newsletter are a good example. All that these apps did was reformat the html for a different size screen. Today, building a responsive website is trivial with CSS frameworks, Wordpress themes and so forth.
95% - if not more - of today's application can be built simply as a browser application and provide the same user experience as an app without the extra friction of finding and installing an app.
Realizing this, both iOS and Android have been good at slowly opening up "native" functions for use by browsers. For example, 4 years back, QR code recognition required a local app, but now it's available for browser-based apps in both iOS and Android. Apple has already opened up Apple Pay for browser-based apps. GPS location is available to browser-based apps. 'WebAuthn" - a new standard - will, in a matter or months, open up even face and fingerprint authentication APIs for browsers on Android.
Does that mean apps are dead? Not quite, but their scope is dramatically narrowing. If you need access to the device hardware and need to do a lot of local computation (like image processing) or GPS location tracking in real time, or fast responsive games, apps are the only way to do these at this point.
Now, hybrid vs native. This decision must be made from three different perspectives: business, technical and operational. If your app is dealing with media from iTunes Store for Apple users or you are developing a high end game specifically targeted and optimized for iPhone XR, there is no point developing a hybrid. The operational consideration is maintenance and upgrades. If you develop native apps, then you have to manage two different code bases, release cycles, versions and so forth.
My advise will be to avoid the app route as much as possible and stick to a website. If you have to build an app, go the hybrid route as building a hybrid is no more difficult than a native app.
As some have already said, which route you take really depends on what you want to do. Also, keep in mind the cost of developers down the road. Whichever has the most available developers will be cheaper. My money is on hybrid developers. But as others have pointed out, you'll still wind up needing to make some native components depending on what your app does. Another thing to consider is bugs, release cycles, performance, and speed in which new OS features are added to hybrid frameworks. Good luck, and do update us with how things turn out for you.
I would say that you should really think what your app is about, the functionality/features it needs, & if going after both markets *simultaneously* is important enough. For 90% of the cases, I've found that the best approach is to build the iOS version first, get a good grounding in that market, and then focus on transferring that to Android and then web. This allows you to focus on building an audience, marketing, & scaling as your market grows. Hybrid apps are typically for simple "form" type apps which are really "extensions" to a web app. The biggest drawback is the lack of flexibility since you are limited by the hybrid framework you choose. It also is something you know you have to replace in the future because at some point it stops sustaining the level of growth needed.
In any event, make sure to build a clickable prototype first because it helps pre-sell/pre-test your market and gives a good framework to build your app from.
I really appreciate everyone's answer, they are really helpful and informative!
i dont know if its just me but i cant seem to respond to answers
Responses are in a linear document format, there are no nested replies. If you need to address someone specifically, you can copy/paste @name to point at them in your remarks.