Will Native Apps For Ecommerce Go the Way of the Dinosaur?

Recently, I traveled with my Ongo Works team to San Francisco for the Meteor Dev Shop meetup where we spoke about two products we’re building on the Meteor framework, Reaction Commerce and Launch Dock. The first is an ambitious rethinking of the entire ecommerce industry, and the second is a community-driven ecosystem for launching apps.

Meteor lets us do more with less. Among the many things we like about Meteor is that it’s ultra light (less code, less work, fewer errors) and it’s real time by default (which is part of what will change the ecommerce industry).

Even though we’re using Meteor in decidedly grand and visionary ways, most developers and even Meteor itself think of the framework as "a better way to build native mobile apps." In fact, the focus of the meetup was about app building.

Having new mobile capabilities is all the rage. The presentation after ours, given by three developers from Meteor’s core development group, was about new mobile capabilities within Meteor. Using Apache’s Cordova, their new functionality lets any Meteor developer easily and seamlessly turn any Meteor web app (JavaScript, HTML, and CSS) into a native app. Sure, the functionality was already possible before this update, but now it’s as simple as running a couple commands, then submitting the app to the Android and/or Apple app stores, and, voila, you have a native app that can even run the same exact codebase as your web app if you want.

Even better, it’s not just any app; it’s an app that can automatically update via hot code pushes without having to submit an update to the app store. Pretty cool stuff. Someone in the crowd even said his "mind was blown" by the demo.

But just because it’s cool doesn’t mean it will actually be useful. Developers and entrepreneurs need to think beyond what’s possible and think about what’s practical. Native apps may be the whiz-bang thing on the block right now, but I think Steve Jobs was right when he was originally dead-set against third-party apps for the iPhone. He said:

The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.

And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.

If Steve Jobs was against it, why do we have so many native apps? A big reason for the proliferation of native apps has been about speed. Native apps respond and perform more quickly than web apps due to limitations on mobile networks. Nowadays this isn’t as much of a limitation. A web application can mimic so much of native functionality:

It’s only a matter of time before the technologies behind web apps are able to compete directly with the aesthetic capabilities of native apps.

And, even better, web apps can provide for a better user and developer experience:

Web apps mean that users [and developers] will never have to worry about updates.

The bigger question, in my mind, is why are we developers and entrepreneurs spending so much time and money developing on closed, proprietary platforms controlled by massive tech companies to then join app stores that have such limited visibility? The answer is, of course, because that’s where the users are.

Here’s what we think about web apps: If you build it, they will come. We think we can change where users go to find cool content. We think that users will shift behaviors to follow the content they desire. And we think open frameworks are the way to get us there. If we start to build awesome web apps that work natively, and we collectively work to train consumers how and where to find them, they will come. Andy Baio couldn’t have said it better in his Friending the App Store post:

How we discover games and apps is broken, hitting indie developers hardest.

He goes on to suggest a solution of Social Discovery and using our Social Graphs to find interesting and relevant apps. We couldn’t agree more. We’d even take it a step further and suggest that we create these social discovery, open, democratic marketplaces outside of the App Store.

That’s why we’re building our shops to work natively without native apps. Reaction Commerce is a next generation, open source ecommerce platform. We think we’re the wave of the future. Not everyone agrees with our approach though. I recently exchanged emails with a potential investor who suggested that in addition to giving everyone an ecommerce shop, we also give them "1-click" ability to have an Android and iOS app as a way to differentiate our offering. We don’t think this is the answer. In fact, we think this is noise. Are consumers really going to install an app for each of their favorite online storefronts? Ugh. Can you imagine 100,000 apps in the App Store for every single store on our platform?

Web technology has caught up. Because the web wasn’t ready to support native functionality universally, native apps were allowed to really take off in the first place. But web technology is now close, if not equal. It may be another 3-5 years before we start to see a meaningful shift, but the writing is on the wall. The same writing was on the wall with Flash and so famously called out in the brilliant letter by Steve Jobs. We may be ahead of the curve on this, but we believe native apps could be the next Flash, particularly in ecommerce.

There’s no doubt that we are in the midst of a massive shift in ecommerce. With so much of ecommerce being driven by search and social in both web and mobile browsers, we believe online storefronts need to just work natively. For ecommerce in particular, it’s critical to have an awesome experience across all devices in all browsers. Not only are the majority of visits to retail websites done via mobile devices, but purchasing on mobile devices is increasing. The Branding Brand report shows that mobile ordering and mobile revenue is increasing at higher percentages, nearly doubling year-over-year. Industry experts are stating that "mobile optimized web sites should be the first priority when trying to appeal to mobile-centric audiences."

What about Facebook’s famously failed attempt to build their app in HTML5? Whenever we broach this topic, everyone brings that up. Mark Zuckerberg even said:

I think the biggest mistake we made as a company is betting too much on HTML5 as opposed to native.

That was two years ago. In technology, two years might as well be one hundred years. Look back at why Facebook originally chose HTML5:

We chose to use HTML5 because not only did it let us leverage much of the same code for iOS, Android, and the mobile web, but it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.

After Facebook switched gears, some developers took matters into their own hands to try to prove that HTML5 was ready for the challenge:

We thought to ourselves: HTML5 can't really be the reason that Facebook's mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices—running at least iOS 5 or Android 4.1—push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we'd seen what our customers were building and the amazing things they were creating using HTML5.

Even LinkedIn recognizes the future that the mobile web holds. While they’re another example of a company shifting away from their original HTML5 strategy to go to native in early 2013, their senior director of mobile engineering says the technology is ready, but the developer community isn’t behind it yet:

Prasad said performance issues weren’t causing crashes or making the app run slowly. What he did say shows that HTML5 for the mobile web still has a bright future—but only if developers are willing to build the tools to support it.

...people are falling back to native. It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. There are tools, but they’re at the beginning. People are just figuring out the basics.

So what will be the tipping point? It’s obvious that developers will be the change. Maybe the shift won’t happen full sail. Maybe certain categories, like games, make more sense for native applications. Maybe not. I’m no expert, but I’ll go ahead and call it on the impending downturn in native apps, at the very least for single retailers and likely beyond. I don’t know what will take their place, but I do believe that mobile browsers and mobile operating systems will look and function very differently in the future. My gut is that "apps" of the future will be more of a seamless experience of the operating systems. We’ll see.

I’m extremely proud to say that we at Reaction Commerce are going to be part of the shift. Of course, if anyone using Reaction has a shop and they want it to be in the App Store, our code is open source and entirely extendable and customizable. The Meteor framework now lets you build native mobile apps with a single command. For example, you can use the command "meteor run ios" and have a native application bundle created. We admit to the coolness of the "one step" capability to having a native app alongside a Reaction web shop, but we hope Reaction developers and others will join us and focus on building better universal web experiences. Starting now.

(Originally published on Reaction thoughts.)