Nearly two years ago, as the market for mobile apps was just hitting its stride, I came to the hallowed pages of Doc4 to encourage prospective app builders to pause to consider whether their goals might be better served by a mobile website than a native app. Given the changes in technology, the market, and user expectations since early 2011, it seems an appropriate time to reflect on the question “Do you really need an app for that?”

At the dawn of 2013, a common and reasonable answer seems to be: “Maybe you really do need an app for that!”

So what has changed in two years that might lead you to choose a native app over a cross platform mobile website?

One important factor is the ongoing improvements in technology. First, browsers in general, and mobile browsers, in particular, have continued to make enormous strides as application platforms. Most current mobile browsers provide at least some support for the HTML Media Capture specification for camera and microphone access. Adding that capability to accelerometer and location access leaves very few common mobile device features that aren’t available to browser-based web apps. That access is still constrained by what particular browsers offer, though, and the interface they provide may not always be what you want to present to your users.

Take bar code scanning, for instance. When using the Media Capture spec through mobile Safari, your users will be taken out of your app to the iOS Camera app. They will be returned to your app after taking their photo, but you’ll have little control over their view or experience until they return. At this point, it may be possible to process the photo on the client side using Javascript, but if not, you will have to upload the photo to the server before you can even determine if it’s an adequate image of a bar code.

At the same time, mobile hardware has made dramatic improvements over the past two years, as have Javascript engines and libraries, so that more can be done on the client side than has previously been possible. This opens new opportunities for mobile apps, since in most cases anything that can be done to minimize roundtrips to the server counts as a win.

However, to paraphrase William Gibson, the future isn’t evenly distributed yet. While the newest, most advanced phones and operating systems may support all the features you want to use, older ones probably do not. Mobile app stores and SDKs have done a very good job of providing tools for identifying and filtering out under-capable devices, but identifying clients on the web and adjusting to them accordingly is still as fraught as ever. App store users whose devices fail to meet your minimum requirements will either be informed of the fact, or never exposed to your app at all, but everyone can reach a website, so it will be entirely up to you to make sure they’re let down gently.

All of that is technically possible and, depending on the user’s connection speed, may be fast and fluid enough for your needs. You are ceding a great deal of control over your application and your users’ experience, though, which may well be a price you do not want to pay.

Another factor to consider is the increasing popularity of online storage and synchronization services like iCloud and Dropbox. While many of these have been around for years, the rise of mobile computing has made them more popular and ubiquitous than ever. Sharable, accessible, secure online storage has always been one of the major benefits of using web apps. If something is already “in the cloud,” then there’s no need to upload it. While it is true that offline data and app storage in modern browsers can give apps offline capabilities, it is something that developers will have to manage for themselves, with less aid than they’d receive from the types of libraries and SDKs provided by services like Dropbox.

As it is increasingly reasonable to expect your users to already have online storage, or at least be familiar with it, then using that with a native app may be a more attractive option than a purely web-based app.

The next factor to reconsider since 2011 is the market for apps. The idea of platform-specific app stores as become increasingly ingrained in users’ minds. For many users, perhaps a majority, the first and only place they’ll search for an app is their device’s store. Being absent from that store may mean that your app or service is never even visible to your target users. Web apps suffer a great deal from not having that kind of cohesive, unified market. It is always possible that such a cross-platform web app store could rise to prominence, but it hasn’t happened thus far, and Apple’s experience with the Mobile Safari Web App directory seems to argue against it.

So even if your native app is a web-native hybrid or little more than a native frame for a web app, being present in an app store may be the best way for users to find you.

Platform consolidation is another factor that may make native apps more attractive to you than they would have been in 2011. Around 2010, if you wanted to be accessible to nearly all mobile smartphone users, you needed to target not only iOS and Android, but also Windows Phone and Blackberry, and maybe even Symbian and a few others for full coverage. Now it’s 2013, and targeting iOS and Android will give you access to 90% of smartphone users, and practically 100% of the smartphone users who actually buy and use apps. Windows Phone 8 may become an important platform, but it isn’t currently, and if it begins to take off you’ll have time to respond. Blackberry (née RIM) has just released Blackberry 10, but let’s be honest: people barely would have cared about that two years ago, and Blackberry will soon be following Palm into the sunset.

You still shouldn’t underestimate the challenge of dealing with the plethora of iOS and Android device/OS variants, but the targets are dwindling. Simply limiting yourself to iPhones and Samsung Android phones limit your native development complexity significantly, while still reaching 80% of native app users.

The tablet market is even starker. It is still practically limited to the iPad and Android, and even more specifically to the Apple iPad, the Amazon Kindle Fire, and the Barnes & Noble Nook. Other Android tablets remain a small sliver of the pie thus far.

This has also lead to consolidation in the app stores, meaning that publishing to the iTunes App Store, Amazon’s AppStore for Android, the Nook Apps store, and Google Play will cover nearly all devices and users.

Granted, three to five devices or stores is still more than “one mobile website,” but if you and your developers and designers are really being frank and honest with yourselves, you’ll have to admit that by the time you account for all the browser, device, and screen variations, you may be dealing with far more than five different websites. Plus, if you’re not careful, those five sites will be tangled and intermingled together in difficult, confusing ways, whereas five separate native apps are more likely to be distinct and separate, if only by necessity.

Finally, the most important considerations, the ones that in most cases should trump all others, are user experience and user expectation. What are modern users’ expectations, and how can your app’s user experience best meet those?

First and foremost, users expect apps to Just Work All The Time. This is a change from earlier mobile app days when Just Working was usually sufficient. People understood that their devices might not be online all the time, and they accepted that sometimes apps wouldn’t completely work. That era is long gone, though. Mobile devices and apps have been deeply integrated into users’ lives, and they want them to work in at least some way in all places and times. Native apps can give you more power and flexibility in that regard than web apps.

Second, the aforementioned advancements in browser abilities are a double-edged sword. When they’re using something that is obviously a website or web app, most people today understand that they’re not “on the web” and they can’t use it. As browsers have become more capable of reproducing local, native apps, that line has been blurred. If your users can’t tell that they’re using a web app, then their disappointment and frustration at not being able to use it offline will be magnified.

Finally, users’ expectations for responsiveness have advanced along with their hardware and software. This goes beyond simple UI responsiveness and extends to such things as playback and streaming. If your app is going to play large video files, for example, your users need to be able to start viewing within just a few seconds, whether the download is finished or not. Furthermore, if they leave that video and come back later, they’ll expect not only to start where they left off but also to be able to start without re-downloading.

Generally speaking, many users today are simply not as forgiving of slow, glitchy web apps as they once were simply because they often don’t understand the difference. Your app either works they way they have come to expect — meaning that it looks and feels like whatever a native app is on their device — or it doesn’t. True, it is entirely possible to reproduce the local, native app experience with web-only apps, but doing so (even cross-platform) may not be cheaper, faster, or easier than creating native apps, especially if your goal is to satisfy the expectations of all your users.

The bottom line is still, as always, to carefully examine your users’ needs, the capabilities required by your app, and your market qualifications, then make your own judgment about the best approach for each particular project. After several years of mobile web app triumphalism, it may be that the tide is turning, or at least slowing, and that native apps may be ascendant. In any case, it is unlikely in the extreme that either solution will become The One Way To Do It in the current generation of devices. Both approaches have their advantages and disadvantages, and it falls to us as developers and designers to help our companies, colleagues, and clients understand the choices.

So don’t automatically assume that a mobile web app should be your default choice. After all:

Maybe you really do need an app for that!