The moment you consider Developing / Investingin a mobile app, you’re immediately faced with a barrage of terminology. What’s the difference between iOS and Android? What are web, hybrid and native apps? More importantly, which is most appropriate for you and your app?
One of the first decisions you will face is which type of app to build. And there is no definitive answer. Your choice will depend on a bunch of competing factors, including your budget and your deadline.
The aim of this article is to give you a sound understanding of the different types of apps available and to aid your decision as to what technology you should use to build your app.
The Basics
When talking about app development, we are usually talking about developing for mobile devices. This includes smartphones, phablets, and tablets. There are also apps for the web and wearables like smartwatches, but for the purposes of this article, we’ll stay within the bounds of mobile devices like phones and tablets.
iOS and Android
For the most part, mobile devices run one of two operating systems: iOS and Android. As of Q3 2016, Android controls about 88% of the mobile device market worldwide, and Apple owns most of the rest. But that doesn’t mean you should develop for Android first. We will discuss this later in the article.
iOS is developed and supported by Apple and is used only on their own iPhones and iPads. In other words, in the Apple universe, they control both the hardware and the software.
Android is developed and supported by Google, often considered a more open platform compared to Apple. In fact, Android is an open source operating system, which means that anyone can use their code to run a device. Google sells a few devices of its own, but Android normally runs on devices built by other companies like Samsung, Huawei, LG, HTC, etc.
There isn’t any overlap between the apps of each of these devices, that is, native iPhone apps won’t run on Android phones and vice versa. Even though you see Snapchat, for example, running on both phones and looking very similar, they were actually built entirely separately.
First, let’s define web, native, and mobile apps.
Web Apps
According to Wikipedia, a web app “is an application that is accessed via a web browser over a network such as the Internet.” So how is this different to a web site?
The difference is subjective, but most would agree that a web site will generally just be informational and a web app provides functionality. For example, Wikipedia is a website; it provides information. Facebook is a web app.
Don’t let the word “app” confuse you, though. Web apps don’t need to be downloaded like mobile apps do. Web apps load in browsers like Chrome, Safari, or Firefox and they don’t take up any memory or storage on the user’s device.
How are they built?
The vast majority are built in JavaScript, CSS, and HTML5. Unlike an iOS or Android app, there is no software development kit (SDK) for a developer to work with. There are templates and frameworks like Angular, React, and Vue.js you can use to get a quick start. As opposed to mobile apps, developing a web app can be simple and quick. However, their simplicity is also their downside. It’s often a good way to test out an idea before investing in a mobile app.
Progressive web apps
Until recently, web apps lacked the functionality of native apps, like the ability to send push notifications, work offline, and load on the homescreen. However, there have been a few improvements to browsers and web apps that offer these features. Apps that take advantage of these features are called progressive web apps.
There are a few steps you need to take in order to make your web app into a progressive web app. They go beyond the scope of this article, but you can find a comprehensive guide here.
Are progressive web apps the way to go? It depends what your goal is. They only work on Google Chrome which is fairly limiting. If your goal is to cover an audience on Android and iOS, then progressive web apps are probably not for you. In that sense, they are not a substitute for a mobile app but they can be a way to quickly get a mobile-app-like web app into people’s hands. If you were considering converting your web app into a progressive web app, consider instead using a solution like Canvas to make your web app into a mobile app. It’s really easy!
Mobile Apps
There are two kinds of mobile apps: native and hybrid. When we talk about mobile apps in this article, we’re talking about apps you download from an app store. We’ll go into native and hybrid in more detail below.
Why build an app vs a web app?
The simple answer to this question is that an app store presence is really important for your company. People search for new apps frequently and you want yours to be there. With a mobile app in the app store, you’re encouraging potential customers to install it and put your icon on their coveted home screen.
Push notifications
Getting users to your product the first time is easy. Getting them to return can be a challenge. Only mobile apps give you the opportunity to send well timed push notifications to re-engage users. Push notifications will be extremely important for any serious app. According to data from Localytics, when a user opts in to receive push notifications, they will launch your app 88% more than a user who doesn’t receive them.
Sharing
Another key to growing your app is getting people to share the app itself or content within it to their friends. This can be done on a web app, but it’s best done on a mobile app. As an app user, you can quickly share to any app (Email, WhatsApp, Messenger, Facebook, etc) in a much easier way compared to a browser.
Time
Users spend a lot more on apps than they do on the web. The popularity of apps has increased enormously and is continuing to rise. According to eMarketer, the average user “will spend 3 hours 15 minutes per day using apps. Time spent on mobile browser activities will hold steady at 51 minutes”.
Ad Revenue
One more advantage to building a mobile app over a web app is ad revenue. CPM for ads in mobile apps are generally higher than in web apps. Many people also use ad blockers for their web browsers which can lower your revenue. This isn’t possible in mobile apps.
Does this mean you should always build an app vs a web app or simply a mobile site? Not really! As a good rule of thumb, if you can imagine a good portion of your users accessing your service or content once daily, then an app will probably make sense. If what you provide is generally used once and never again, then don’t invest in an app and focus instead on a good mobile optimised web presence.
Now let’s go through the two kinds of mobile apps: native and hybrid.
Native Apps
Native apps are what you would normally think about when you think about apps. The majority of the apps on your mobile device are native apps. Unlike web apps that are written primarily in Javascript, native apps are written in languages that the platform accepts. For example, Swift or Objective-C is used to write native iOS apps, Java is used to write native Android apps, and C# for the most part for Windows Phone apps.
Apple and Google offer app developers their own development tools, interface elements and standardised SDK; Xcode and Android Studio. This allows any professional developer to develop a native app relatively easily.
Advantages of native apps
So why are most apps native? The reason is that native apps have a number of significant advantages over the alternatives:
- They offer the fastest, most reliable and most responsive experience to users. This is unlikely to change in favor of web apps.
- It is easier to tap into the wider functionality of the device including the camera, microphone, compass, accelerometer and swipe gestures. It’s still possible using the alternatives, but it’s easiest on native.
- Native apps can make use of push-notifications, alerting users when their attention is required in the app. You get the opportunity to continually bring your audience back for more which is key to a successful app.
- You’re more likely to please your users due to the way you can match each app’s UI/UX to the platform conventions. There are dozens of UI/UX differences that make users feel at home. By building native, you don’t have to compromise with UI/UX that you hope will be user-friendly for all platforms.
Disadvantages of native mobile apps
- You’ll have to manage a codebase for each platform you launch on.
- iOS apps will not run on Android and vice versa.
- Most developers specialize in one platform ( Android or iOS), so to create an app on both platforms will require two separate developers (or teams).
- Native apps generally cost more to make than hybrid apps.
Examples of Native Apps
A large number of the most popular apps out there like Pokemon Go, Twitter, and Waze, are fully native. It’s become trickier, however, to distinguish who’s using purely native code on Swift, Objective C and Java and who’s relying on hybrid solutions or cross-platform SDKs.
Building Cross-platform Native Apps
As we said, the main disadvantage of native apps is having to develop apps separately for each platform you want to cover. That’s still true if you want to stick to the native SDKs provided by Apple and Google, but in the last few years, several alternatives have become available to reap the benefits of cross-platform development without sacrificing the user experience or access to native APIs. Two of such platforms are Xamarin and React Native, both worth a look.
Xamarin
Made by Microsoft, Xamarin is a platform that lets developers build one app that works on multiple platforms in C#. They also provide free tools to build, test, distribute, and learn from your apps. Xamarin seems like a more complete development environment than PhoneGap and Titanium, even offering a test environment where you can test your app on thousands of virtual devices before launching (this is crucial for cross-platform apps). Xamarin also offers a few prebuilt apps you can use to get a quick start. Some companies that have built apps with Xamarin include Slack, Pinterest, and Honeywell.
React Native
Not wanting to be left out of the fight, Facebook recently open-sourced a project of theirs called React Native which lets you build real, native iOS and Android apps with one codebase. It’s not a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. You just use JavaScript and React to put it together. Check out these stats from Instagram. They show that for the features they built with React Native the amount of code shared between iOS and Android was over 90%!
While React Native doesn’t give you access to all the device’s functionality, you can weave in native code if you need to. There are some pretty heavy-hitters using React Native, including Facebook, Walmart, Tesla, and Airbnb. You can check out some React Native apps here.
Titanium
Titanium, in its latest version, is similar to React Native in that apps are written in Javascript but produce a native app, bridging native APIs to Javascript with its own set of APIs. It no longer relies on webviews and this results in a more “native” look and feel for your app. Titanium has a great showcase of apps built with their technology on their website. Some of the more well-known apps are: eBay, ZipCar, PayPal, Khan Academy
Hybrid Apps
If a native app and a web app got married and had a kid, it would be a hybrid app. You install it like a native app, but it’s actually a web app on the inside. Hybrid apps, like web apps, are built with Javascript, HTML, and CSS and run in something called Webview, a simplified browser within your app.
Why Hybrid?
Say you have an idea for an app and you don’t know if people will like it or not. Your goal is to put something usable into their hands as quickly as possible. In the startup world, this is called an MVP, or minimum viable product. You’re short on resources so you need to create a simple version of your product that still provides value. Building a web app might be the truly minimal option, but won’t really allow you to test whether people will download and use an app on their device.
Advantages of Hybrid Apps
All the advantages of hybrid apps stem from the fact that instead of building two apps, you’re building one app and tweaking it a bit so it works on both platforms. Now you only have one codebase to manage. This will probably require half the number of developers two native apps would have required. Or, with the same number of developers, a hybrid app could be published in half the time.
- Developers for hybrid apps are often less expensive than native developers.
- Hybrid apps are easier to scale to another platform. Once you’ve built for one platform, you can launch on another like Windows Mobile.
- You retain the same ability to access device features as with native apps, thanks to solutions like Phonegap that act like a bridge between the native SDK and the webview in which the app runs.
Bottom line: Hybrid apps save you time and money.
Disadvantages of Hybrid Apps
- Performance is probably the biggest disadvantage of hybrid apps. Because hybrid apps load in a browser-like component called webview, they are only as good as the webview. Webview is responsible for displaying the UI and for running Javascript code. In the early days of mobile, Google and Apple didn’t give webview the same engines used by their mobile browsers, Chrome and Safari. Since then, webview has vastly improved but it hasn’t reached native performance yet. We will get deeper into different aspects of performance later in the article.
- Getting your hybrid app to run appropriately on each platform generally takes substantial work. In some situations, the total cost might become comparable to that of fully native apps, rendering the cost benefits negligible. It all depends on how close you want to get to the “native user experience” or how simple your app is.
- The UX of the app will suffer. iOS and Android users tend to be very loyal to their platforms, and since they’ve been using them for years, they’re used to how things work in native apps. The differences are subtle but can be frustrating for your users. By building a hybrid app, you won’t be able to please both camps. Try too hard to customize the app based on the platform and it may end up costing the same as two native apps. There are some ways you can do this which we will discuss shortly.
Hybrid App Platforms
PhoneGap/Cordova
PhoneGap is probably the most well known among hybrid app platforms and probably the easiest to begin with for a web developer. Cordova is the open source foundation and engine of PhoneGap. It’s backed by Adobe and is completely open source. It lets you create cross-browser mobile applications with Javascript, HTML, and CSS. These apps run in a WebView and are then wrapped in native code. PhoneGap then offers native plugins that allow you to use all of the device’s functionality including accelerometer, camera, compass, file system, microphone, media, networks, notifications, geolocation, and storage. Apps need to be packaged into binary files which will include a webview wrapper and your app’s HTML files, normally loaded locally on the device. Check out these examples: Tripcase, Untappd.
Canvas
Our own take on the hybrid app, Canvas is a service offering anyone with a mobile web app or responsive site the ability to build a mobile app for it, with no development work. As with our News solution, it’s offered as a service, meaning we will build, publish and maintain your apps for you. Technically, Canvas relies on our own native codebase for iOS and Android, including native elements for navigation such as a tab bar, a push notifications inbox, content preloading for your pages, caching, and offline support. The app is designed to rely on a remote web app or mobile site which you control – any change on your mobile site is immediately reflected in the app.
Can you convert a web app into a hybrid app?
If you’re building an app for an existing site or you have a mobile web app ready that does exactly what your app should do, but only misses what a native app generally provides (app store presence, push notifications, home screen icon, offline use), then turning your site or web app into a native app can be both quick and economical.
You won’t have to manage two platforms (iOS/Android) separately. You’ll have a single web app that covers the mobile web and the two major mobile platforms with your apps. This is what we built our latest Canvas platform for!
How to make a web or hybrid app feel native
The ultimate goal of a hybrid app is to feel native. Here’s what you can do to make your hybrid app look and feel like it’s coded in native.
- Use a splash screen, so that the app loads to a fully loaded app.
- Add a back button to the UI, to make sure users can navigate intuitively. Android already includes a back button in the system interface or in the device, but iOS needs your app to allow users to navigate back as they move around.
- If you’re building an app from scratch, use a UI library like Onsen UI. It will not only speed up development time, it will make design decisions much easier. UX and design is based on conventions or what the user is used to. A library like Onsen UI has already made all the mobile components according to conventions.
- Get rid of the 300ms delay. All browsers, including webviews would normally add a 300ms delay when users tap on an element. Why? It’s because it’s waiting for a second tap. 300ms may not seem long, but it’s enough to make an interface feel sluggish.
- Where possible, follow the style guides. If you’re designing your app from scratch, have your developer and designer read the guidelines created by Apple and Google.
- Make wait times seem shorter. If you can’t avoid having a screen delay, show a loading icon or progress bar. Any delays longer than 0.1s are significant enough to warrant a loader, in order to warn a user the app is alive and loading.
Canvas already does most of this for you, so if you’re looking for a quicker way, give it a try!
How to choose?
We’ve given you a list of pros and cons for web, native and hybrid apps. But how do you decide which one is best for you? The following is a list of factors that should help you decide what kind of app to build.
User Experience
UX is the overall experience a user has when using your product, especially in terms of how easy or pleasing it is. A user interface is like a joke. If you have to explain it, it’s not that good. And if your app has bad UX, people will stop using it.
Needless to say, you need to invest in UX. The best possible thing you can do for UX is to write two separate native apps. Like we mentioned earlier, there are differences between the two operating systems and people have gotten used to them. If you hand an Android phone to a loyal iPhone user, chances are they’ll stumble a bit.
Time to market and cost
How much does building an app cost? There’s obviously a large range here. Prices will vary based on complexity, features, and platforms.
A quick way to get an estimate is to use this tool created by the fine people at Crew. It asks a number of questions and gives you an estimate of how much your app will cost.
But essentially, your app development cost can be determined by just 2 factors: hours required and hourly cost. The hourly cost will stay mostly the same and is easy to determine, but the number of hours the app requires depends on what you need the app to do. Some of the major features you might need are covered in the tool created by Crew.
The best data about app development costs comes, unsurprisingly, from app development agencies. One such agency is The Nine Hertz. In 2016, they released this handy inforgraphic.
There are a few important data points here so let’s go through them.
The cost of hiring native app developers
If you’re building two (or more) native apps, you’re going to be paying an iOS and Android (and possibly Windows) developers. You might think that because Android is the more popular operating system it would be cheaper to develop for. That’s actually not the case, at least according to this article by Infinum. They found that Android apps contained 40% more code and took 30% more time to develop.
According to the infographic, mobile developers in North America cost an average of about $150 per hour. This price decreases drastically if you hire developers in India or Eastern Europe where average costs are about $30-50 an hour.
Time required to build a native app
According to the same infographic, it takes an average of 18 weeks to build a standard native mobile app; 10 weeks for the back-end and 8 for the front end. Keep in mind though that not all apps have a backend and some may use a back-end as a service to reduce development time and complexity. Your actual timeframe will vary widely from this average, but this is still a good reference if you’re new to the world of app development.
For more information on the breakdown of these and other steps, check out this link.
App Type | Time in hours | iOS Cost ($150 per hour) | Android Cost ($168 per hour) |
Simple Apps | 300 | $45 000 | $50 400 |
Moderate Apps | 500 | $75 000 | $84 000 |
Multifaceted Apps | 750 | $112 500 | $126 000 |
Highly Multifaceted Apps | 900+ | $135 000 | $151 200 |
- This table is based on North American developers
- App type is somewhat arbitrary
How should time to market affect your decision?
If your app seems like it would be a good fit for hybrid, this can considerably reduce your time to market. However, by doing this, you may be sacrificing something that will be hard to gain in the future. There’s an important term “technical debt” that applies here. Assuming your app does really well, you will eventually have to face some of the technology decisions you made earlier. In general, technical debt is costlier in the future than it is now.
On the other hand, your job isn’t to write great code, it’s to ship products, so technical debt is okay! As Joel Spolsky says in his blog post The Duct Tape Programmer, “A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing.” And he would know. Joel Spolsky is the CEO and co-founder of Stack Overflow and also founded Trello, FogBugz, and Gomix.
The cost of hiring hybrid app developers
Since most hybrid apps are built in Javascript, hybrid app developers are essentially web developers with a more specific skill set. The average hourly rate for web developers is about $50 in the US, but hybrid app developers might be able to charge a bit more due to their mobile expertise.
The cost of building a hybrid app that can run on both Android and iOS is generally lower than building one native app. However, there are a few caveats:
- Because these aren’t native apps, you will have to invest a considerable amount of money into making it feel native. There are ways to do this, but it’s not as easy as if it was native. This could bring the cost up to the equivalent of 2 native apps.
- Apple has a fairly strict app submission process where real people use your app to check that it fits their guidelines. If hybrid apps don’t feel like iOS apps, they might be rejected which could delay the launch (costing more money to fix the app).
Using Device Features
Depending on the complexity of your app, you may want to tap into the various features the device itself has like the accelerometer or camera. Once again, the best way to get access to these things is by building fully native apps . But, if you build your app in PhoneGap, you can use PhoneGap plugins to access those features. You can search for anything you need here. Using plugins means relying on someone else’s code or possibly writing your own plugin if you can’t find something that fits your needs.
Performance
If there’s one word that sums up what your user cares about, it’s performance. If they don’t like the performance of your app, they will simply find another one.
Native apps have the best overall performance, period. In the early days of the Facebook mobile app, the company took a bet on HTML5 apps. Later, Mark Zuckerberg said that was one of the biggest mistakes the company ever made, as the technology was way too young at the time to provide the experience users expected.
Let’s dive into the various areas of app performance.
Since hybrid apps are basically just browsers, they’re good at showing apps that mimic the experience you would get in a browser on a computer, namely pages. If you app is just a series of pages and doesn’t have impressive graphics, a hybrid app may be just fine for you. However, building a game or an app with lots of animation would not be a good fit for a hybrid app.
Gestures
Apps are supposed to “feel” right. If you swipe an element in a certain direction, you expect it to react immediately and according to your wishes. This is easy in native apps. Not so much in hybrid apps. Though developers could try an external library like Hammer.js to get native-like gestures.
Data processing needs
Many of the most popular apps today are very CPU (processor) heavy. Think about Snapchat which applies filters to video. Things of this nature would simply not be possible in hybrid apps. The app has an extra step in Javascript it has to step through before executing the native code. You’ll be much better off building a native app if this seems like it will be a problem.
Finding Developers
You have a few options for finding the right developer. The classic options are hiring someone full-time to work with you, hiring a freelancer, or hiring an agency. In an extreme case, you might find yourself learning to code in order to build an app.
The process for finding developers for native and hybrid apps is more or less the same except for one major difference. If you decide to build two native apps, you will likely need 2 developers as most specialize in only one platform.
Having said that, finding a quality developer to hire as a freelance or employ, is really, really hard.
So you might find the option of hiring a single developer who can build your app for two or even more platforms; a much more feasible endeavour than building a small team of native app developers. Trust me, costs will add up pretty quickly if you’re building natively and hiring different people for it.
So, how do you find developers?
Finding decent iOS developers can actually be really difficult because they’re in high demand. Android developers, however, can be a bit easier to find.
Here are a few things you can do to try and find a developer:
Search freelance websites
Freelance sites like Upwork have a very wide range of developers in terms of quality. You’ll have to vet their skills for yourself – expect to pay $35-$100/hour for a good mobile developer. Sites like Crew or Toptal have pre-vetted developers available for hire, though generally more expensive ($50-$200 per hour).
Attend meetups
To find developers, you have to hang out where they hang out. Often, that’s in-person at meetups. They go to hear about the latest technologies and how to use them. The most popular site for tech meetups is meetup.com. The added benefit of meeting developers at these meetups is that you know they’re keeping up with the latest development methods and technologies.
Approach app agencies
There are thousands of digital agencies worldwide that build websites and mobile apps for other companies. The advantage with hiring an app agency is that you will get a lot more than if you just hire a freelance developer. An app agency will have in-house designers and marketers who can help develop your app.
Case Study – Building a News app
Say you want to build a news app. How would you go about it? We made a list earlier of some of the considerations that go into the hybrid vs. native decision so let’s go through each one as it applies to a news app.
Overall Complexity
News apps don’t seem very complex. For the most part, they deliver information in text or video form. Your news app will probably be very similar to other news apps from major publishers, like the BBC, Huffington Post, Reuters, The Times.
For example, a news app would simply consist of sections, articles, pages and comments. Once you add push notifications, options for users to select what alerts they want to receive, comments and sharing, you’ve done it.
Sounds simple? It may be, but once you consider you’ll need to integrate it with your CMS of choice (where the content comes from), you’re still looking at several weeks of work for each platform if you’re building native. And how about triggering notifications for new content? Well, now you need a backend too.
UX
The best experience you can give a user for a text-based app is an uncluttered page with text that is easy to read. Navigation is important, but most users will spend their time reading articles- not flipping between different sections.
Since you won’t have to invest a lot of time in the UX, it’s worth going native.
Performance
Poor app performance is one of the biggest attributors to people leaving an app. But in the case of a news app, that’s unlikely to be the case unless it’s really bad. It shouldn’t be hard to create a news app that performs just as well in hybrid form as it does in native. It’s just pages of text.
Time to Market
For a news app, the fastest time to market is a week, and that’s for a native app! How is this possible?
As we’ve established, native apps can be expensive, especially if you’re looking to build a custom app from scratch, not to mention time-consuming (when you have to build for multiple platforms). What if you could get an affordable native app?
Unlike other “app builders”, we focus on doing one thing and doing it well. Publishers and bloggers get plenty of customisation options — including colour scheme, style and branding. Plus all of the advantages of native apps, on both iOS and Android. We provide these features at a fraction of the price a developer would charge.
If you’re using WordPress,
MobiLoud is a simple, effective and professional way to launch your own mobile apps.
Summary
You need a spectacular app, and can get there by building it native from scratch, but it will cost you. You can build it hybrid and save time and money, but you won’t get the native experience. The timeframe for both of these solutions is months.
Or you can get native apps in a week using MobiLoud News. It gives you a fully native app, with all the UX and design details you’d expect from a professional news app, without the cost and time required to build. How? By focusing on the WordPress publishers niche we can provide a great product that offers a professional result at a fraction of the cost. And your app is live in a week, not months.
Case Study – Building a Social Network App
Overall Complexity
Although social networks seem complex due to their size, the complexity of the app for each individual user isn’t off the charts.
This shouldn’t require a native app. Hybrid apps can handle this with relative ease.
UX
The user’s experience in a social network app is quite important. Social networks work because they form a “network effect”, which means the app gets more valuable the more people are on it. Would having Facebook be fun if you were the only one using it? No, so in a social network app, you need to encourage people to invite their friends. This is no easy task. It can be scary to invite people to a new app. What if they don’t like it? A great UX and UI can often be the thing that makes it easier to sending out invitations. You can absolutely achieve great UX in a hybrid app, but because the goal of a social network is to keep growing, you may find yourself needing to build a native app in the future. Maybe it’s worth building it from the start?
Performance
While social networks used to be mostly profiles and photos, today they’re using more live video, recorded video, and messaging. For complex features like live video, native is best, but hybrid can cope with everything else.
Time to Market
Building a new social network app from scratch is a lot of work and you’ll only find out if it’s successful months after launching it. As an owner/CEO, your job is to minimize the time and cost for you to test whether your idea can be successful. Therefore, a sacrifice of going hybrid in favor of a quicker time to market may be useful. You also have the option of turning your Buddypress theme directly into a native app using Canvas.
Summary
Social networks need to wow users in order to get them to invite all their friends. If the app isn’t impressive or better than apps they’ve used before, there’s simply a lower chance that they will share the app. Keep that in mind when choosing your app technology.
What’s Best?
There are many different directions in which you can take your app, all of which have their pros and cons. There will always be some kind of limitation of time or money that will push you to make a certain decision about your app.
What’s important is to spend enough time thinking and calculating before you start building. Apps are expensive enough that you may only have one go at getting it right. Read as much as you can about the different kinds of apps and the development stages. If you can, get in touch with people that have gone through the process of building each of these kinds of apps. They will be able to give you the best opinions.What is clear, though, is that commercial success of smartphones and tablets isn’t showing any signs of slowing down. While it may seem like everyone around you has a smartphone, there are only
about 2 billion smartphone users worldwide. So in the next few years, you can expect billions of people around the world to be getting their first smartphone. The opportunity to get your app into the app store and into the hands of millions (or even billions) of people is still growing.
THE PROS AND CONS OF NATIVE VS HYBRID MOBILE APP DEVELOPMENT
Native:
Ever since there was even an App store to begin with, Native application development has been the standard in mobile. Native applications are written specifically for mobile operating systems such as iOS and Android.
Pros:
- Due to all of the app’s elements being included in a single native package, native applications tend to have fast graphics with fluid animations built in.
- Native applications can access exclusive native APIs in the phone’s operating system such as push notifications, camera, and in-app purchases, which would otherwise be prohibited, or provided in a cumbersome manner on a mobile web application.
- If you’re developing a native application for iPhone, they have many resources, development tools, and reading material to help you out.
- Apple definitely wants to push their brand whenever possible, so they have provided UI components from their UI libraries to make development a little less painful.
Cons:
- If you intend to also publish your app to a different app store, your application will need to be rewritten in order to be a native app on another mobile OS. This usually delays features for the next platform in development. For example Snapchat implemented features such as reverse video a lot later on Android than on the Snapchat app for iOS. This is not to do with any one platform being better than another. However, Snapchat was released on iOS first, so it usually receives new features first.
- It is a time consuming process to create a native app for both iOS and Android, so it will cost you.
- Native platforms define their own rules and frameworks and inherit little from other disciplines, requiring more investment. For many businesses with existing development (ie. web, desktop app, etc) personnel, they would be unable to utilize these existing resources towards a native mobile application.
- Native applications typically require you to define phones and tablets separately, or define individual layouts. While this step is available and repeated on the web with CSS media queries, it’s usually a single layout and multiple stylesheets. The effort for native is non-transferable between iOS, Android and others since each operating system is locked into proprietary tooling.
Hybrid:
Hybrid application development can do everything HTML5 does except it also has some features of Native applications. They do this by deploying a native harness or wrapper to act as a bridge between platforms and access native features. This wrapper can either be created manually or generated by a program.
Pros:
- Hybrid mobile apps don’t have that “mobile web” browser look because they can include native hardware features.
- The content of a hybrid app is portable and just requires a native harness to run it.
- Since software like Ionic or React provides frameworks to make a webpage act like a native application, they can be distributed on the App Store.
- Developers have the option to package the app locally or through a server, which provides access both online and offline.
Cons:
- Since hybrid applications are relatively new in the mobile development space, automatic generation may not work on all devices, which can get especially complicated when trying to accommodate to different Android phones.
- Since hybrid app development is still new there is not as much support for any troubleshooting for unprecedented problems that may occur.
- Several vendors have started offering build-platforms for hybrid frameworks, simplifying the build knowledge that was previously required for multi-platform. Just be prepared to pay for it.
- If the App Store is able to recognize that your application is not truly native, it may be denied from the App Store.
- If your app can’t be published on the App Store, then that would reduce your monetization and distribution potential since purchase price or in-app purchases are native features.
- Since most hybrid apps are written in HTML5, they rely on the system’s browser to support the wrapper for running the application, which presents a supplantable resource that external parties could exploit beyond the normal security afforded to a native application. This heavily hitches behavior to a system component that could be replaced on customized/rooted devices, creating very difficult situations to isolate and support for errors or exploits.
- When a new iOS version is released, hybrid developers would have to rely on a third party before they are able to design hybrid applications on the new OS.
- Lack of the pure UI assets of iOS or Android may result in a slower performance of the app in general. It may not look like a mobile website, but it may feel like it at certain points.
- Phonegap, Cordova and others generate native by-products, meaning you still have to support and manage the individual packages in the app-stores. Keeping versions in sync across platforms while addressing individual bugs can be more difficult than a pure native approach.
So which one is better?
There is no absolute better, it depends on what is best for you and your company and venture. Weighing this with the pros and cons, native development sounds like the right choice. But you’re smarter than that, and you realize that a method that works for one app may not apply to another. Some may remain skeptical about hybrid development summed up by Java’s “Write once, debug everywhere” phrase.
It all depends on what type of app you’re trying to build.
the choice varies from client to client. We make sure that the client uses the app development method that’s best for them and their budget. With Twilio’s Owl Air app, they use a variety of native features such as Voiceover IP and touch identification as you can see above, which is more difficult to translate to hybrid development.
MOBILE GAMES – If you’re building a mobile game, native development usually works best. If you REALLY want to make it a cross platform release you can use game engine programs like Unity or Buildbox to build your games.
ENTERPRISE APPLICATIONS – For enterprise applications where having one codebase is critical and where sexy interfaces are not as important, then cross-platform apps may be the right choice because you want to make the app accessible to ALL platforms.
Takeaways
Most of the flaws in hybrid are usually due to its adolescence in the mobile development space. With the large room for growth in hybrid mobile development, its critics may eventually view it as the better choice in the future. Perhaps a developer wanted iOS App Store distribution to be guaranteed, so they opt for native app development. And that’s perfectly fine. Just remember, if you plan to have your app on both platforms, it will take more resources to make a version for iOS and Android since they both require separate builds.
if you like/share our post !