Sorry Google, ‘There’s A URL For That’ Doesn’t Have The Same Ring


At yesterday’s MobileBeat conference in San Francisco, Google (NSDQ: GOOG) Engineering VP Vic Gundotra said the app store trend is just a fad and at some point powerful browsers will take over as the main mechanism for delivering services to the phone, reports

While that may be true, the biggest problem facing Google will not be convincing developers, but consumers. Apple’s steroid-enhanced marketing machine has drilled into the public thinking that “there’s an app for that,” not that there’s a URL. Clearly after logging 1.5 billion downloads within a year, Apple (NSDQ: AAPL) is on to something and vigorously training the mobile users of tomorrow. Even if Google is correct for all the right technical reasons, they may face an uphill battle when it comes to perceptions.

It’s not that Gundotra didn’t make a strong case about using mobile browsers. He argued: “What we clearly see happening is a move to incredibly powerful browsers. Many, many applications can be delivered through the browser and what that does for our costs is stunning.” Already, there’s some evidence that this could work. The latest technology will let web applications tap features on the phone, including the accelerometer, and already Google has integrated location information.

And mostly, users don’t care what technology they are using as long as it works. When people in the mobile industry talk about browser-based technology, they aren’t saying that icons — or shortcuts — on the phone will go away. In actuality, there might be a light-weight widget sitting on your phone’s homescreen, much like an icon today — however, it’s actively pulling info from the web. For instance, Google’s Android operating system is already supporting widgets. The WeatherBug widget displays the current temperature and the expected hi and low for the day — based on your location — right in the icon.

But it’s not just marketing hype…Google will have to prove browsers are the best way to go, and some of the challenges of creating a browser environment may be out of Google’s hands. It’s up to the carrier to provide a strong signal, and without a native experience on the phone, losing a cellular connection or having a weak signal would severely hamper the user experience. In addition, it’s not realistic to believe that the browser will eliminate fragmentation (unless Google intends on dominating the mobile browser market). Developers will have to tailor their services to meet all of them, much like they do today for the iPhone’s Safari browser. Another complication, which could be an entirely separate post, is distribution. How will you find new services in a browser? Likely, Google’s answer is Google search.

To be sure, there’s still a ton of kinks to be worked out in Google’s plan. But you have to wonder why Steve Jobs, Apple’s CEO, caved on the matter himself over a year ago. If you remember, Jobs originally had the same idea for the iPhone. “Build for the web,” he said. But as we know, applications were launched just a year later, now there’s more than 65,000. That’s a lot of momentum.


Shachar Oren

I find it interesting that Jail Break apps are not discussed. While in the USA the Apple marketing machine controls iPhone installs to X% extent (JB is still in play), overseas it's totally JB in many countries. iPhone is already popular in countries where iPhone is not even officially available thru any carrier, for example users have been using video on iPhone for over a year before iPhone started supporting it or before iPhone actually had an apps store even.

What many succesful apps see is a surge in revenue when they launch but it quickly slopes down. Sustaining such revenue is not easy and takes constant innovation, which depending on the nature of the app, may or may not be easily doable.

Both camps are here to stay, open source vs. commercial, free vs. paid, just as it is on the web. We all still update Office and Windows at a Microsoft site, but we get plug-ins for both from third parties too. Similarly, consumers will buy some stuff at the iPhone Apps store but may also get other things elsewhere, or opt to crack the OS and go solo on it. The competition would continue to be driven by the inherent value and usability of the app, not where it's downloaded from.

The carriers face the same dillema AOL faced for years w/ their closed system: How do you promote the World Wide Web on one hand for what it inherently is, while sensoring it and controlling the pipelines at the same time? Long term it's a losing battle. The only remaining question is how long can you sustain the current system to max revenues before it's dead.

ed dunn


the apps versus mobile web battle was decided a while ago.
The most important factor is not client-side scripting versus compiled OO or marketing component. The most important factor was the monetization.

It is easier, way easier to get paid from apps. Developers can receive revenue upon launch. The market is clearly define of millions of consumers who pay their iPhone bills.

All I hear about when it comes to web is some VC poured in $XX millions of dollars and people jump around for joy, speculating if it will be a success.

At least with apps, developers can see revenue almost immediately.


What do you all think of this new attention grabbing headline from the BBC: "Apps 'to be as big as internet.'?" I'm not sure if you can silo those two things and file them separately. Many apps run off the internet.

However, the headline brings me back to my original point. While most of you are talking about bits — and debating the pros and cons of each technology — I'm trying to understand the marketing component. If consumers believe apps are better, will apps win over the technology debate, which show the mobile web is better?


IMO its natural the browser will take over in the same way has occurred online. where there are relatively few apps compared with web sites


Joe – I guess that's true (that JavaScript is costly to develop) – but I'm not sure anyone does write JavaScript, frameworks remove the need (Ruby on Rails, or even Google's trick of compiling Java to Javascript). But the iPhone is not a true OO language, and is essentially leveraged off the traditional Mac developer (who knows Apple's way of thinking). Maybe the iPhone is just a way of making developers buy Macs…

If Microsoft were to convincingly offer a way for their developer base to hit the mobile application area I'd say that Apple would be dead in the water. Strangely they are staying quiet on the whole. That Google is trying to step up to that position is interesting as they have virtually no developer base!

I'm not sure I agree with your view on standards. I'm a bit of a standards historian. Typically a standard is introduced for a specific reason. Adoption makes economic sense and it fills the intended niche. Then because of broad adoption it is extended into areas it (perhaps) wasn't intended for, but the network effect makes this compelling – as the existing users can see the benefits of the extension. After a while the purists are left saying "there's a better way to do this", but in truth the path was really defined as a random walk through adoption and the pruned paths of non-adoption.

The best example is HTTP.


Nic – large JavaScript apps are much more costly to maintain that applications written in modern, type safe OO languages like Java or C#.
We need a web reset, rather than pushing the same old standards to do things that they were never designed to do.


This all feels like AOL Keywords from the 90's. Marketing spend to convince people to ignore URLs. What's more is that iPhone apps require C programming (or close enough) and there's not so big a pool of that talent. It's fashionable right now to do iPhone apps, but maintaining app code is generally more work that web-based, so the economics would point to Google's argument in the long run. Especially since most of the iPhone apps are hanging off web service, which is a whisker away from BEING web-apps.

erik graf

I do not think it is an either or question. To me it makes perfect sense to download apps on the client. Even if you have a fast connection downloading larger sizes of code to your phone seems to make more sense to me. Just because the bandwidth is there does not mean one has to waste it. Additionally security and privacy might be an issue. If browser based apps get more access to the phone OS then automatically security becomes a big issue. Finally and that in my opinion is the biggest issue: In order to use all these shiny cloud based applications you need constant network coverage and that is not given yet for mobile devices and probably wont be for a while. It is just very difficult and prohibitively expensive to provide high speed network coverage in an urban environment (deflection, interference, etc …).

lucas dickey

"To be sure, there’s still a ton of kinks to be worked out in Google’s plan. But you have to wonder why Steve Jobs, Apple’s CEO, caved on the matter himself over a year ago. If you remember, Jobs originally had the same idea for the iPhone. “Build for the web,” he said. But as we know, applications were launched just a year later, now there’s more than 65,000. That’s a lot of momentum."

It's pretty simple to figure out why Steve "caved" on web apps vs native apps…this way Apple controls the distribution in a way that they couldn't with web apps.

Tom Limongello

Ok rafat, to get serious we need to split the field into publisher apps and games. The 'richness' of publisher apps can be handled by hmtl 5 but games do need more than the current evolution. Not making that distinction keeps the space confused.


Leigh – the foundation is still weak. the entire VM needs an overhaul – and I don't think the current standards process of evolution will ever address this.

We need standards and cross platform support. We also need a good technical platform for very rich, complex applications. This isn't about canvas and video, this is about the runtime platform itself.


"Technically, writing all applications in a single threaded scripting language based on an outdated document format is not a good choice. "

html is evolving. or something similar will solve the single-threaded problem. and html5 is hardly outdated. the canvas tag and etc. allow developers to be almost as expressive as they can be with flash/silverlight.


I don't think Google are right technically, I think they are right politically – backing an open standard for client side technology.
Technically, writing all applications in a single threaded scripting language based on an outdated document format is not a good choice. The new features are nice, but the foundation still leaves a lot lacking.

Rafat Ali

C'mon guys, grow up. Read the actual argument Tricia's making.

Comments are closed.