Web First for Mobile
My mobile performance research focuses on mobile web. I don’t analyze native apps. Why? I believe in the openness of the Web. I don’t like being forced to use a proprietary technology stack. I don’t like signing legal documents. I don’t like having to be approved by someone. Although I don’t write commercial apps, I don’t want the people who follow my work to have to pay a share of their revenue to a gatekeeper.
I also understand that it’s important for many people to build native apps, especially if they’re doing something like games that require the performance and device APIs that might only be available to native apps (right now). This is not a blog post about whether you should build a mobile web app OR a native app. This blog post is about building your web app first. You might eventually end up with both a web app AND a native app. Regardless, your mobile web presence is the place to start.
This prioritization of mobile web presence before native apps crystalized for me last week at Mobilism. Three speakers, James Pearce, Jason Grigsby, and Scott Jenson highlighted factors for why building for the mobile web should come before native apps.
First off is this slide from James Pearce’s talk. It shows that Facebook’s unique users from mobile web browsers is more than those from their native apps combined. This might not hold true for all companies, but it does show that the web browser can be, and in some cases is, the preferred client on mobile, and certainly lowers the barriers allowing access to a wider audience.
This leads to the second point, this time from Jason Grigsby. Jason actually spoke about TVs at Mobilism (huh?), but I recalled him saying “URLs don’t open apps” when I hosted Jason at Google for a tech talk. People frequently communicate using URLs – in their tweets, emails, bookmarks, etc. And these URLs don’t open apps. So it’s critical that companies ensure they have a web presence that works on mobile.
Jason highlights the need for a mobile web presence with examples including this one from Chanel. This first screen shot shows Chanel’s native app. It’s a good looking UI and we can be assured that Chanel devoted significant resources to build and ship this.
I’m not big on perfume, so I might be biased, but it strikes me that people interested in Chanel might not start by searching the app store. I can see Chanel fans searching Google Maps on their phone for the nearest Chanel store. Or doing a web search for “Chanel” to find a list of store locations on the main website. But when the mobile user navigates to the Chanel site they’ll be sorely disappointed with what they find:
To be fair, that was Chanel’s old website that relied on Flash. Here’s their website today:
The current website is better than a broken Flash object, but this mobile web page falls far short when compared to Chanel’s native app. This is where I see Jason’s point: Many if not most mobile users engage with a company through their website, and URLs don’t open apps. So it’s important to provide an engaging web presence for mobile users.
The third point is from Scott Jenson’s talk at Mobilism where he discusses “just-in-time interaction” – a world where my mobile device allows me to interact with the environment around me: stores, bus stops, and even movie posters.
But this highly interactive experience doesn’t work with native apps. Here’s an excerpt from his related blog post that explains why:
There is no way that I’m going to be able to or even desire to try this type of just-in-time interaction with our current application model today. The energy involved in finding, downloading, using, and most importantly, throwing away an app is just far too great.
While native apps present too much of a hurdle for easy interaction on mobile devices to ubiquitous services, the Web is perfect for that.
My final data point is from the article Why Publishers Don’t Like Apps lamenting the trials and tribulations of building native apps in the world of publishing. Besides the technological challenges, publishers run a business trying to sell articles and issues for money. But after entering the native app market they found the margins were too small:
Apple demanded a 30 percent vigorish on all single-copy sales through its iTunes store. Profit margins in single-copy sales are thinner than 30 percent; publishers were thus paying Apple to move issues.
I’m not saying you shouldn’t build native apps. And I don’t want to have yet-another-debate about web vs. native. I simply want to suggest that you start creating your mobile presence as a web presence. That’s where users are most likely to find you, and you want to give them a good experience when they do.
Michael Mahemoff | 16-May-12 at 5:27 pm | Permalink |
“I don’t want to have yet-another-debate about web vs. native.”
But aren’t you engaging in the debate here, except only stating the argument in one direction?
I’m in general agreement with these arguments, but there are also major arguments in favour of native apps which the web development ignores, dismisses, or shrugs off at its peril. When it comes to features like background processing and system alarms (interrupts), they’re hardly even mentioned as a concern. And yet, for many native apps, these features are crucial elements of their success.
John Allsopp | 16-May-12 at 5:51 pm | Permalink |
I think Steve is referring to the binary x is better “debates” we’ve sen now for years.
Far better, as he has doen here, is put forward arguments, evidence and case studies for when a web first approach is most appropriate.
I don’t think Steve or any of us who advocate more web centric approach from a position of evidence and experience would argue things don’t need to be fixed. But to date so often we’ve seen x is missing from web (camera, performance, payment system, appstore, whatever) therefore native is the only approach.
What I think we really need to do is indentify in detail these shortcomings, and work toward fixing them, or getting them fixed.
And also to identify use cases where a native approach is most appropriate, to help folks make the best decision in their particular circumstance.
john
Michael Mahemoff | 16-May-12 at 6:19 pm | Permalink |
John, this article does begin with the distinct argument that you should build for web first, whether or not you build for native later. I don’t think that’s the case for everyone and I don’t think it’s fair to make the argument unless you weigh things up against the native capabilities.
The best thing for developers is to help them through the decision process, as you say, so I think we ought to be identifying *when* web-first is the right model. And increasingly it’s not just the bleeding-edge outliers like games.
Steve Souders | 16-May-12 at 6:24 pm | Permalink |
@Michael: Instead of debating which is better, I want to focus on which to start with first. It seems to me that most people won’t start both projects simultaneously, and I’m just saying it’s better to start with a mobile web presence first. But I acknowledge there are exceptions (“it’s important for many people to build native apps, especially if they’re doing something like games that require the performance and device APIs that might only be available to native apps (right now)”). While it might be true that too many people dismiss the advantages of native apps, I think a bigger population jump on building native apps without analyzing the alternatives because it’s cool or popular.
@John: And I think you conclude it well with an awesome suggestion for gathering more case studies and data that identify when native is better to help folks make an informed decision.
Michael Mahemoff | 16-May-12 at 6:41 pm | Permalink |
Steve – definltely. I think one thing most people now agree on is you need to pick one platform to launch on, especially when people are (quite rightly) focused on the lean, fail-fast, model. There’s no point spreading yourself thin. The question then becomes which is the one platform, and that question is open to debate.
Jonathan Kelly | 16-May-12 at 8:19 pm | Permalink |
Q.E.D. I had to link out of the reader app to comment :)
I would like to see a bar on that graph for goobs who use their browser because they do not realize, as they say, “there’s an app for that.”
P.S. Your SPAM protection asked me what “77 minus for equals.” We can’t, in this universe, subtract words from numbers.
Chris Joel | 16-May-12 at 10:21 pm | Permalink |
One property that impressed me a lot, recently: LinkedIn. LinkedIn’s mobile site stands as a great example of how well-suited mobile browsers have become to providing a like-native application platform for web developers. If I go to LinkedIn on my Android phone’s browser, I am treated to a website that looks, feels and behaves exactly like the native application on the same phone.
Rimantas | 17-May-12 at 12:34 am | Permalink |
Sad to see App stores reduced to some mystical “gatekeeper” ignoring that they are also hosters, promoters, card processors.
If you want to share free web app with the world, then fine, but if you want to make money, then native app is one of easiest way to get all organized — getting the same with web app will require a lot more hassle and paper signing. To some avoiding it is worth 30%.
Paul St.. Amant | 17-May-12 at 5:38 am | Permalink |
Hi Steve,
Great points. Starting with the mobile web is a great way to get your info onto mobile devices. I agree that if a company is into gaming or if the app is the company, then sure, why bother with the web, but most companies don’t need apps, they just need to be on mobile devices, whatever info they are serving up.
Paul
Aldo_MX | 17-May-12 at 10:44 am | Permalink |
“URLs don’t open apps”, unfortunately Youtube is the exception for this rule :/, many apps launch the Youtube App if they find a Youtube URL (which I think is a bad practice).
Steve Souders | 17-May-12 at 10:48 am | Permalink |
@Aldo MX: For brevity I said “URLs” but you’re right, it would be more accurate to say “HTTP URLs don’t open apps”. It is true that developers can define custom URL schemes to launch their app, but those URLs are much less shared in email, tweets, etc. than normal HTTP scheme URLs, hence my point that companies should make sure to have a mobile web presence at the end of an HTTP URL.
Mark Bolitho | 19-May-12 at 1:08 am | Permalink |
I think the starting point should be data-driven, although I think emotion often wins the day. Steve makes a good point about where the customer journey begins, but with many retailers and brands being primarily focused on brand awareness and retention in tough economic times I think a significant number will be drawn to the native app first.
Jamie Lemon | 20-May-12 at 4:29 am | Permalink |
Nice article, which naturally leads us on to the need for more responsive design on the web. That Chanel example could have probably very easily emulated the App experience ( at least in terms of visual layout ) very easily.
Peter O'Shaughnessy | 05-Jun-12 at 5:17 am | Permalink |
I enjoyed this article and the way it pulls together other examples and articles. I definitely concur with the “Web First” approach.
In case it complements your article, or just to read a similar proposition written in a different way, I also wrote a post advocating “Web First” a little while back. It’s more of a step-through of the decision process. I’d love to hear what you think:
http://www.peteroshaughnessy.com/post/16025696697/web-first-hybrid-second-native-third
Vijay Agrawal | 15-Jul-12 at 12:18 pm | Permalink |
Great article, Steve. We are seriously evaluating a web-first approach to building mobile apps and I want to hear your valuable thoughts/perspective on 1) performance impact of using mobile-web libraries such as sencha touch, jquery mobile etc. Given that HTML5+CSS3 enables us to create a mobile-like experience with some sprinkling of JS, I wonder if using libraries is worth the performance penalty? Do you know of any apps that use these (or are done without these) and are there any benchmarks available on them? I know linkedin.com has a very good web-mobile app – they seem to be built without any mobile-web widget l iibraries ()
2) benchmarking tools – Are there any good benchmarking tools to measure mobile web-app performance on iphone and android devices? Is chrome timeline tool sufficient?
Steve Souders | 16-Jul-12 at 11:57 am | Permalink |
@Vijay: 1) A library itself doesn’t determine whether the app is fast or not. It’s how the library is used. Do you load it async? How much code do you add yourself? How well is that code written? Many folks use these libraries and build amazing apps. 2) I recommend getting real user data from Google Analytics, Boomerang, LogNormal, Torbit, or other such services.
makale | 12-Aug-12 at 6:52 am | Permalink |
Nice article, which naturally leads us on to the need for more responsive design on the web. That Chanel example could have probably very easily emulated the App experience ( at least in terms of visual layout ) very easily.