This is a contentious issue. One group swears by mobile-capable web-applications while the other vehemently backs the Native Application as the ultimate answer. What we really need to do is take a step back and look at the overall situation. So, we bring you native vs web apps.
If we're being honest, most business owners don't know the first thing about developing an application for any mobile tool, whether it's a smartphone (of several different varieties and operating systems), a phablet (a large phone or a small tablet), an actual tablet, a netbook, a sophisticated E-reader, or even a plain old laptop. The temptation for owners is to simplify their problem by hiring someone to restyle their web applications so that they work from their website. Even then there are still two essential choices.
This technique uses .htaccess files (or other detection variations) that identifies the sort of device that is connecting to your website. If it's not a typical browser & computer combination with a typically-sized screen, there is an automatic redirect to a specially designed mobile site. They're often identified by a preceding "m." in front of your regular website address such as http://m.mysite.com. This type of website can accommodate all the oddities and particularities that are associated with non-desktop iterations of hardware. Need it tall & thin for a mobile phone? Done! Need it in landscape mode for a tablet or netbook? Done! Need it in black & white for a web capable E-reader? Done!
Seems like a pretty good solution, right? Did you notice the intrinsic problem? That's right—you're now maintaining two distinct web applications—one for your regular users and one for your mobile users. When you update your main one, you now have to go and replicate all that work in a grossly similar program. It makes sense if your offerings to mobile users are significantly different than the experience you deliver to a desktop user. If not, you're just making a lot more work for yourself and introducing the possibility of errors and inconsistencies between your two products.
This methodology allows you to use a single web-app which automatically adapts to the tools your visitor is using. It even resizes on-the-fly so that if someone rotates their phone or tablet all the content is redistributed in a logical and useful manner. So then this is the ultimate design, right? Aside from exclusive content delivered only to mobile users, this is a pretty good solution since it only needs a single, easily-maintained website that recognizes the hardware that is connected to it to respond appropriately. All the adaptation is automated. That is true as far as it goes, but let's consider the other possibility.
Before my personal bank had a native app for mobile devices, I would struggle with the browser on my smart phone to log into their desktop website. Of course all the text was positively minuscule. If you knew what the desktop website looked like you could navigate fairly quickly to where you wanted to go. Then you could log-in, and insert your password, and then spend minutes zooming and zooming out, trying to identify the information you needed. That was definitely not user-friendly! If you never had to do that, you're lucky! Nowadays, of course, you tap an icon, see nice, big, friendly entry-fields, log-in (possibly even with a fingerprint reader - so nice), and quickly navigate to precisely where you need to be via easily-read screens and interfaces. Comparatively the whole process is a pleasure. If you've ever been to an "App Store", you know what I'm talking about.
Native applications are built targeted towards specific mobile operating systems. By doing so, you can create a very tailored and integrated experience. While advancements in cross platform development have progressed significantly, you still will have to consider additional testing, and potential user experience modifications to support (each!) of the various platforms. They also offer functions that were completely unimagined just a couple of years ago. For example, I may need to a deposit check, but going to the bank is such an inconvenience. Now all I have to do is use my smartphone's built-in HD camera to take a photo of the front and back of the check, and it is credited to my account. The bank asks that you hold onto the check for a few days in case there are any problems, but you don't have to worry about mistakenly re-depositing the check because the MIC information on the check protects you from accidental fraud. It's a great system.
So the answer is quite clearly: it depends. Your needs will determine which system, or combination of systems, will be most effective in your circumstances. If a native app will enhance your customers' experiences, simplify your life, and bring in new revenue streams, then by all means, speak to a consultant and develop one. If a mobile app has no obvious benefit other than "because other companies have them", it might not be the best thing for you. They're not free—they need updates on a regular basis and maintenance for compatibility with older and newer phones—so there will be a continuing cost. And you have to ask yourself "How useful are they going to be?" Does your business model warrant having a native-app?
Once you can answer that question, you'll know what to do.
Read our article on what to expect from the custom build process.