This post, I’m afraid, requires quite a bit of preamble to support the ridiculousness of its title.
First, let me define what I mean by “Mobile Apps”. I mean native applications for smart-devices. As you’ll see later, I’m not actually talking about all native apps, I’m talking mostly about Brand Apps, that is, applications that are organization specific rather than task/purpose specific. IE The Target App or the [Insert the name of your church] App.
Now what I mean when I refer to the “Death” of mobile apps is what every other tech blogger means when they hastily kill off a service or technology in their own highly-opinionated post. And that is: the slow, 10-15 year decline of the technology or service into irrelevance.
I guess the title of this post should actually read, “The Slow 10-15 Year Descent Into Irrelevance of Device-Specific Mobile Applications Associated with a Brand That Do Not Perform a Specific Task or Purpose.”
That doesn’t quite roll off the tongue, does it?
Now for the post:
The Death of Mobile Apps
“We need an app!”, declared my boss. At the time, I was a full-time church employee, WordPress tinkerer, and copy-paste coder who was in no way qualified to build a native iPhone application in Objective-C.
Even so, 3 months and a few sleepless nights later, I had deployed a church iPhone application complete with sermon video feed, blog and web links as well as a “Get Directions” button that opened in the Maps app (I was particularly proud of that one). Three months later, a new version of iOS was released that broke my precious application.
Almost no one noticed.
Throughout the year that followed and leading up to our church deciding to pay someone that knew what they were doing to develop a working iPhone app, I frequently asked myself:
Why do we need an App?
For that matter, why does any organization or brand need a native mobile application?
A huge amount of the time, these apps do nothing more than partition off a part of their website information or service. Paring down your website/web-service for mobile users isn’t a bad thing, in fact, it’s a great exercise in focusing your content. But the problem is cost. As this article on Mashable points out, deploying an iPhone app (just one platform) of sufficient “brand quality” will cost at least $30,000 (I know churches don’t pay this much). So we can assume that for the cost of reaching 80% of smart-phone users in a native applications, you could build several versions of your mobile site.
Imagine firing up an OSX Target app on your MacBook, just so you could browse their catalogue. It’s laughable to imagine Target executives investing hundreds of thousands of dollars for a desktop application that duplicated the information on their website. But that’s exactly what millions of organizations are doing on mobile devices.
The Mashable author goes on to point out (based on some fuzzy numbers):
In other words, you can reach nearly five times as many people per dollar invested with a mobile website rather than a native mobile app.
But still, apps abound. 37Signals founder David Heinemeier Hansson pointed out (via tweet rant)
Building apps is the new gold rush. Non-techie friends are constantly asking me how to get in on the action. I would short this market.
It’s like looking at the music billboards and asking anyone who knows how to play a guitar if they can help making one of those hits.
(also, it’s always iPhone apps they want to build. Never hear anyone talk about Android or even web)
So native apps are expensive and comparatively ineffective, but that doesn’t mean they are dying.
My totally unsupportable “Death” claim for device specific mobile applications comes mostly from this article on designmind. The vitriol of the comments section shows just how controversial this subject can be. It makes one point I thought was relevant especially to smaller organizations, like churches.
What is the value to pain ratio of a native application?
When you ask your users to download, install and manage a native application, will the value they receive from your app be worth the pain and inconvenience they went through to get it?
If all your app does is duplicate your web content, then I’m guessing it doesn’t provide your users with enough value.
Here’s an easy quiz you can use to evaluate whether or not your organization needs a native mobile application:
- Will our app provide our mobile users with some value that they cannot get from our website?
- Do we have extra money to spend on an investment that will reach one fifth of the people per dollar that a mobile website can?
If you answered “no” to either of the above questions, then join me in celebrating the demise of branded apps.
WAIT!
Before you rip me a new one in the comments of this post about how much higher conversion rates are on native apps and how crappy the web is as an application stack, let me say this:
I can think of several perfectly good reasons to build a native mobile app.
Here are just a few:
- You want to use the native hardware: camera, GPS, accelerometer, etc…
- You want to build a game or utility that has value outside of your organization.
- You want your organization to appear hip by being able to say you have an app.
- You want to perform complex operations or animations that require lots of processing.
I don’t work at a church anymore, so instead of hearing about one app idea, I get to hear about dozens of brilliant app ideas (usually iPhone) from clients. When I suggest building a web app instead, their reaction is always a mixture of disappointment and confusion.
In a vast majority of cases, a web application can provide all of the value of a native mobile app with no discernible difference in performance at a fraction of the cost. This is a fact more people need to understand. I believe that the fad will pass and, in time, we will witness the death of mobile apps.
Just give it ten years or so.
Ryan says
it seems like the branded apps that have the longest shelf life are those that have nothing to do with the brand itself – i.e. games. This is great for brand impressions and not subject to the ever changing business. The trick is convincing business to build (or really just stamp their brand name on) an app that is totally irrelevant to their brand. Good luck getting that one across your boss’ desk (unless you’re Starbucks) http://news.starbucks.com/article_display.cfm?article_id=590
rb
Brian Notess says
That’s true. I think a lot of brands, if they put some thought into it, could create an app that gave users value outside of their brand. Of course, as you point out, that’s a hard pitch to make.
Peter C. says
Thoughtful post, Brian! I believe Oodles Apps seeks to remedy this issue of a branded app looking like/doing exactly what the company website does. Check the website out and let me know what you think. Thanks!
http://oodlesapps.com/
ThatGuyKC says
Great thoughts, Brian.
I’ve been guilty of downloading branded apps and then never using them. I much prefer the mobile website experience on the iPhone versus branded apps (with the exception of Amazon)
Brian Notess says
Some brands have useful apps. Most don’t.
Raoul Snyman says
Absolutely spot on. This is almost exactly what I’ve been thinking, and saying to folks who ask me about mobile apps.
Brian Notess says
There’s a HUGE amount of buzz around iPhone apps. Part of the problem is a lack of understanding about what can be done on the mobile web.
Eric Dye says
If Raoul says this, Brian, you know you’ve hit the tech nail on the head!
Gabe Hoffman says
What about the opportunity to deliver subscription based content? A native app seems like possibly the best way to deliver that content, unless you want to stream everything with a web app I suppose. It will be interesting to see if content delivery apps based on reoccurring subscriptions become more prominent. Basically channels as apps.
Brian Notess says
That’s a fair point. But I’ve seen a lot of good solutions for aggregating mobile content. IE iTunes podcasts, RSS feed readers etc. Even YouTube and Vimeo.
It’s hard for me to think of content valuable enough to justify building a native app to deliver it.