Remember the debate a few years back about whether apps should be native to each platform or made universally available through a single Web app? Well, the native app has won that debate. (Sorry, Jon Udell!) Thank goodness! But Web apps still have a place, albeit not as the main solution you should use.
The silly arguments in favor of Web apps
The pro-Web app argument is that a single app ensures both consistency and universal access, with less development effort. That can be true, though variances in Web browsers make it harder to accomplish -- especially on Microsoft browsers -- than the Web app purists would have you believe.
Oh, and Web apps are often not very capable, and they don't work at all when you don't have a reliable Internet connection. A native app that uses information from the Internet, such as an airline app or navigation app, is typically still useful when you're disconnected.
That's not to say native apps are always better than Web apps. The Adobe Analytics app is both unreadable and limited on a tablet or smartphone, whereas its Web app is readable and uncrippled. JetBlue's Web app is more reliable than the native app for checking into flights, though the native app remembers your details even when you're offline.
And many mobile banking apps -- even on tablets -- present fewer capabilities than their Web apps (still on those same tablets). How dumb is that?
Arguing in favor of Web apps because of such poor products is like arguing against vehicle infotainment systems because Ford's Microsoft Sync is so bad -- or against Southern cuisine because of what Waffle House sells.
These bad native apps reflect failures in design and execution by developers and UI designers, not in the fundamental concept of a native app. There are plenty of Web apps that work poorly on some or all devices (Ariett Xpense everywhere and Google Apps on mobile, I'm talking to you) that could be used to "prove" that Web apps should not exist.
Where native apps should rule
Why and when are native apps better? There are some attributes you can check to make that decision, both as a developer and as a user:
Information should be persistent. That means information up until the last sync or download should remain until no longer needed. Although Internet access is more available, it's not universally or persistently available.
Plus, constant refreshing and polling uses bandwidth, which is typically metered in mobile connections and increasingly metered in desktop connections (such as by home broadband providers).
For example, I want my airline boarding pass locally stored on my smartwatch or smartphone, not available only on demand via the Web. There's a good reason Google has been making more of its voice recognition intelligence and extensive maps data native in Android, rather than online-only. (Are you listening, Apple?)
Native capabilities are useful or necessary. Our computers and mobile devices do much more than a browser knows about. Whether it's the native camera, microphone, mobile payment validation, access to helper apps, gestures, or notifications, you need to be native to get them. Although the need for native functionality is acute in mobile, it also is true on the desktop.
What a waste it is to not take advantage of the local processor and storage as well.
Notifications is a simple but powerful example. If you use Slack, for example, you can take advantage of the native notifications features in OS X, Windows, Android, iOS, Windows Phone, and Linux, so you can stay active in the conversation -- not so much with the Web app. The lack of native apps for Windows and OS X was one reason my colleagues ditched Yammer -- they never knew when there was something they might need to participate in.
Microsoft Office is a more subtle example. The Web app is very good and should be a poster child for the rich Internet. But, for example, you can't see comments or have automatic spell-checking, as you can on the native apps, nor can you control your presentation playback from another device.
The case for Web apps
There is still a place for Web apps, even if native apps should be the default assumption.
If your tablet or computer is broken, left behind, or out of juice, being able to use someone else's device to continue working is a good thing -- and that's why having a capable Web app as a backup to the native app is a welcome option.
Another use of Web apps is for occasional services, where a user isn't likely to have the app in the first place. A good example is a government transaction site, such as to pay for a business license or a car registration renewal. No one wants a thousand apps they use rarely. The Web, thanks to search and bookmarks, is a more sensible venue for such services.
But make sure those Web services work well on mobile devices and Macs, not only Windows PCs, which government agencies and telecom carriers in particular seem to forget. It amazes me how many of their sites require Flash or Internet Explorer (excluding mobile and often Mac, Linux, and Chrome OS users), use a deprecated version of Java (so Macs can't run them), or completely lack responsive design for small screens. Developing native apps forces you to deal with these issue, rather than be lazy.