I've been blogging about mobile for six years. Including things like whether native would beat HTML5, why Facebook switched back to native from HTML5, Native vs. Web, the rise of apps, the evolving definition of ‘app’, how Fortune 1000 CEOs are going to be fired for missing the Mobile Crush, how apps have a strong distribution channel, about NPR, Nat Geo, USA Today, Washington Post & others talking about mobile strategy back in 2010, how mobile is way more than a 2nd screen, how mobile data connections will replace wifi, the future of media on mobile, the mobile engagement challenge that nobody's talking about (yet) and how there are two types of engagement to optimize for, the basics of mobile, the future of mobile advertising, mobile events like WWDC 2010, a 45 min screencast back in 2010 with some big thinking about small phones, how mobile influences social strategies, what the iPad means for media, Sprint vs. AT&T speed comparison (spoiler alert: AT&T wins by a landslide), using mobile to lifehack a check deposit from 2000 miles away, mini apps, how mobile enables the interest graph, why we founded + sold AppMakr and Socialize (and the infrastructure required to run it), Android’s growth, SDK adoption tips (and tricks), as well as what mobile might look like in the future, including a review on Google Glass, hacking Glass, Tile, the Internet of Things, and what APIs mean for mobile. So needless to say, I’m deep into mobile.
But what I just read in the First Round Review (I talk more about FRR here) just blew my mind. They write:
"MYTH #1: Building apps natively per platform is a waste of time and money.
REALITY: If you want a five-star app, build natively. Period.”
Bam. Mind blown. Just like that. Native wins. At least for now.
You can read the entire article here. It’s specifically about the five mistakes startups make around mobile.
The other four myths busted are just as good, as well. What a great article. First Round is killing it.
Love your recap! I did think the First Round post is very self-serving (i.e. promoting Pivotal's consulting practice). While I have always been a big native fan, I am doing more and more hybrid apps for products that have NOT found product/market fit. I can iterate 10x faster by publishing to iPhone shell, android shell, and web. Once It's working I would go 100% native.
Barg the prototyping angle is an interesting point. However that begs the question of how much bias you're introducing. By definition, what the article is arguing is that you simply can't create the same experience across devices as you can natively, which would mean that you can't truly prototype what you're trying to do via a hybrid approach.
In fact, it may be the case that just creating static mockups is a better approach to prototyping than a hybrid app (to take your argument to a further extreme).
We can only hope this information filters out to the various brands and, more importantly the creative/engineering agencies who seem to have a predilection with building HTML5 apps in an effort (presumably) to save on building "real" apps using native libraries.
A non-native app for a major brand is really just a broadcast that they don't take their mobile strategy seriously.
Well, I think there is a lot of confusion around native vs. non-native. We (Appcelerator) tend to think of native being natively compiled application with native features / APIs, etc vs. a hybrid application (i.e. an application that runs inside a web browser and packaged as a "native" app a la phonegap/cordova).
Of course, you don't have to just take our word for it. We have over 60,000 native applications built with Appcelerator in the app stores and hundreds of millions of end users using our applications - including major global brands.
There's long been a raging debate going over HTML vs. Native Apps. Just Googling the debate returns over 3.7 million results.
I'm here to tell you, that's the wrong way of thinking of things.
It's like debating whether oil or water will win when mixed. You can't get the right answer if you're asking the wrong question. While oil and water don't mix well, they can co-exist in the same bottle, and there are valid times you might want to use each.
Let's dive into the right way to think about mobile, and specifically about the role native apps will play. A better analogy of the mobile landscape is from the point of view of a car manufacturer like Honda. Honda makes a lot of Honda Accords -- they're its bread & butter. But for years, Honda had a Formula One team. A Honda Accord will never compete at the Formula One level, nor was it meant to. And conversely, if Honda only had a Formula One team, it wouldn't have the massive market share in the auto market that the Accord and other bread & butter models provide it, but Honda did learn a lot about how to make really great engines from its Formula One program.
In the same way, mobile apps are the "Formula One" of mobile, and HTML is the Honda Accord. You can get wide distribution across many phones by having a mobile HTML presence, but you can't do the sexy, progressive types of things that you can do with apps, because an app is typically compiled software which can leverage the specific hardware functionality of the phone (the camera, the address book, geolocation, the microphone, and many other things).
DO a search to investigate Windows RT 8 and you'd be presented with a common opinion amongst most quarters of the tech press when you see popular news sites presenting headlines like these
Headlines like these and reading this particularly scathing review of the device from Paul Thurrott amongst others where Windows RT is described as "(Windows RT) is simply too underpowered to provide a satisfactory experience." and "Windows RT does everything slowly. Everything. The day-to-day experience is terrible." anyone doing research about Windows RT would be forgiven for thinking Microsoft has released a bit of a dud here.
Well the truth is far from it, far from it if your expectations of what you are buying are set correctly and you have an understanding if what Windows RT is and is not...