Mobile Web is Years Away from Competing with Native

Native mobile apps rule the mobile experience, no one in their right mind would deny that, but I’ve heard a lot of talk over the past year about the impending doom of native apps and how the mobile web is bound to replace them.

DeWitt Clinton:

we’ve been down this road before.

Who among us doesn’t remember the great debates in the late 90’s about how web sites wouldnever replace native applications on the desktop? That was just a decade ago, but now it seems laughable that people didn’t see clearly the upcoming dominance of webapps over native apps on the desktop.

Exhibit A: Google, Yahoo, Facebook, Twitter, YouTube, Amazon, Ebay, Gmail, MySpace, Craigslist, Wikipedia, Blogger, WordPress, etc., etc., etc.

The biggest successes of the past decade are all websites, not native apps.

His continues:

The mobile web browsers and mobile web toolkits of today just haven’t quite caught up yet with the native environments. But things are changing quickly.

I absolutely agree with DeWitt that mobile web apps will play a much larger role in the future, and generally crappy browsers are a big reason that web apps aren’t a larger part of the mobile landscape, but I completely disagree that the web vs native discussion we’re seeing today is a mirror of the web vs desktop of the 90s. Even with better browser technology, there is still plenty of room for native apps. I’ll argue that (1) mobile web vs native is not a direct parallel to the web vs desktop of the 90s, (2) even if we had amazing browsers, web standards lag too far behind native and (3) there is currently very little money in building a mobile web app.

Today’s Mobile is not the 90’s Desktop

As his evidence, DeWitt cites:

Exhibit A: Google, Yahoo, Facebook, Twitter, YouTube, Amazon, Ebay, Gmail, MySpace, Craigslist, Wikipedia, Blogger, WordPress, etc., etc., etc.

It’s true, these apps never would have made it on the desktop – but what happened in the 90s was only half about where the app was built – the second half was about where the data lived.

All of the data for these apps – every single one – puts the data in the cloud. This was a huge change from the 90s mentality of I-always-have-my-stuff-in-this-file-on-my-desktop-right-here. What made these web apps so successful was the change from data living siloed on the users desktop to finally living in the cloud. Having 100% of the data living in the cloud + the rapid iteration that these web clients could go through provided an overall better user experience. Web apps were revolutionary not only because they were web apps, but because the data lived in the web as well.

The 90s brought applications from the desktop to the web, and a the same time they brought data from the desktop to the web.

Continuing the evolution, the last decade has seen an explosion of REST APIs and OAuth, providing easy access to a web app’s data. The foundation of the Web 2.0 explosion was based on exactly this – Brad Feld even argues, “Today there is no excuse if you launch a consumer web service without an API.”

These APIs provide a huge difference between today’s mobile and the 90’s desktop. Moving data from the desktop to the web in the 90s, and the explosion of web services in the last decade have allowed native mobile apps to explode in growth. A developer with a free weekend can build an app based on any number of open web services, launch the app in the App Store, and charge $.99. This is with zero web service cost – the app is using 100% somebody else’s data + somebody else’s web services – yet he or she can still turn an easy profit.

Building a mobile web app may be equally easy from a development point of view, and it may even provide a similar user experience, and it may even be runnable on many more devices than the iPhone – but the developer has to pay to run the web site + maintenance + protect against security and hack attempts – done even modestly correctly this can be relatively expensive from a money and time perspective. What’s worse: there’s no easy way to actually charge for the web app to recoup costs. Higher cost to maintain and a harder sell to the customer – better mobile web browsers and faster development won’t solve this inherent problem with the mobile web.

Native Trumps Web Development

Exhibit B: The Twitter iPhone/iPad app. The twitter app supports seven image services, five video services, six URL shortening services, two read it later services, plus six additional twitter blocker / ego / stat services.

the twitter app uses over twenty different web services in its app – browser security prevents a developer from using even one different-domain web service. Since native apps aren’t bound by the cross-domain security issues in the browser – these apps can pull data from multiple different services in an easy to use unified interface.

HTML5 is the first major browser step forward in the past 10 years – and it bring developers only a fraction of the way toward offering native-like capability. Native apps are able to take advantage of multiple threads, whereas JavaScript is bound to just 1 thread. Native apps can provide better caching, better offline support, faster load times and performance, and hardware accelerated animations, access to the compass, accelerometer, altitude, camera, file system, and more. Hardware matters – HTML5 and related tech bring the web a much needed boost, but even the new hotness in web tech provides a lackluster experience compared to native.

Show Me the Money

As I mentioned earlier, it’s easier for a developer to make money with a native app than with a web app, and this won’t change anytime soon. The iTunes App Store provides a safe, consistent, and easy way to purchase apps directly from the mobile phone. There is no corrolary for the mobile web – the purchase experience is a clunky and inconsistent at best. Stand alone mobile web apps will never take off until there’s an easy and trusted way for customers to buy these apps directly from their phone.

Conclusion

Native mobile apps are fighting a different war than the desktop apps of the 90s. Open data, REST services, and OAuth allow for much richer native mobile apps than was possible on the desktop many years ago. Native apps can be developed to take advantage of these same web services with dramatically less cost than developing a web app.

What’s more, these native apps can be sold to end users much easier than selling mobile web apps. While frameworks like jQuery Mobile and Sencha Touch are helping to make mobile web development easier, it’s as difficult as ever to get users to pay for mobile web apps – and until this problem is solved, native will continue to dominate the mobile marketplace.

Native Mobile Apps vs. Web Mobile Apps is Not a Feature War

While reading my much-loved Flipboard today, I came across an article in the Wired section from Webmonkey called How Do Native Apps and Web Apps Compare? Having worked in both mobile native and web apps, this is a topic very near and dear to my heart. It’s slightly biased towards the mobile web, but the comments in the article keep the overall content as a fair comparison. Definitely worth a read.

Out of the over 15 feature vs feature comparisons, one point stuck out to me in particular:

The Issue Native Web
Can I sell it? Charge whatever you want. Most app distributors take a slice, up to 30% Advertising is tolerated, subscriptions and paywalls less so. No distribution costs beyond server fees

Can you name even 1 mobile web app that makes any sort of money with a subscription or paywall? I can’t think of any, but I’m willing to admit that there’s probably one out there somewhere. Compare that to thousands inside the iTunes app store that make very very good money – even small-time indy developers. If you want to charge for your app, there’s currently one option: native.

But native apps aren’t winning the war because they have the best user experience (they do), but because they are easy to buy, easy to install, and easy to update. The user gets a fantastic purchase experience, and most importantly, the developer gets paid per download. All of this works because Apple already has the user’s credit card info, and it’s literally a 1 click install from iTunes or the iPhone. What’s more, the purchase experience is also the exact same for every application. The combination of simplicity for purchase + consistency of purchase + trusted seller means much much higher trust and repeat rate from the user.

Contrast this with the web. Every web app developer has to solve the “how do we process payments” problem. They have to create their own unique purchase workflow. And most importantly, they have to independently gain the trust of the user before the purchase. I love Doodle Jump as much as the next guy, but does anything think that they’d fill out a 2 page credit card form on an indy developer website for a $0.99 app that runs in the browser? It wouldn’t be 3 million people, I promise you that much.

Users don’t have a simple, consistent, and trustworthy way to purchase mobile web apps. Similarly, developers don’t have a simple, trustworthy, unified market to sell their apps in. There is way too much friction for developers to go to market, and way too much friction for users to purchase from the market.

All features being equal, for the mobile web to ever be a serious contender, the problem of “how do I as a developer make money?” and “how do I as a consumer trust this developer w/ my $$ info” needs to be solved.

If my name was Amazon.com, I know what I’d be working on right about now. Amazon already has payment info for nearly 70 million users compared to the 40 million iPhones in the market, and they’re in a fantastic place to host the mobile web app marketplace. It’s trusted, it’s simple, and it sells just about everything except mobile apps. It’s a pefect fit.

Once this problem is solved, and it will eventually be solved, only then will mobile web apps be able to compete with their native counterparts.

Bug Fixes for wpSearchMu WordPress Plugin

Just a quick note that version 2.1.2 of the wpSearchMu plugin went live today. I’ve fixed a fairly common “Uncaught exception Zend_Search_Lucene_Exception” problem that would crop up and require an index rebuild. After you update, you shouldn’t see that error anymore.

I’ve also added a few checks to make sure that the plugin is installed in the correct location. Quite a few people aren’t installing to the mu-plugins folder, and that was causing some index inconsistencies and errors.

Head over to the wpSearchMu page to download the latest version!

Google Author link
Page 18 of 50« First...10...1617181920...304050...Last »