The Problem: Too many handsets, environments, and differences across platforms
The Solution: A single environment/platform for mobile apps
There you go, problem solved, no more fragmentation!
Google at MobileBeat 2009
Now that the “noise” level has dropped, it is my turn to comment on Google’s (Mr. Vic Gundotra) comment at MobileBeat2009 about mobile apps and the future:
“What we clearly see happening is a move to incredibly powerful browsers,” Gundotra said. “Many, many applications can be delivered through the browser and what that does for our costs is stunning. We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.” Gundotra added that Apple CEO Steve Jobs proclaimed “Build for the web” with the initial launch of the iPhone, a statement that met with resistance from developers: “I think Steve really did understand that, over the long term, it would be the web, and I think that’s how things will play out.”
Here Mr. Gundotra (Mr. G hereafter) emphasizes and reminds us that the main root problem with mobile applications is fragmentation and the consequences are higher cost of development and management of such mobile applications.
OK, fragmentation has slowed down mobile, and has resulted on higher development and management costs. But fragmentation will not go away any time soon. He said the Web has won, but on mobile it hasn’t. Because many applications can be delivered over mobile is not the same as it has won. The Web has won though from the perspective of “Services on the Web”. Mobile web run-time environments will, over time, continue to evolve, providing a rich development environment; I believe this will be the case, but this will take time, years, to happen. Now imagine a world where we have Google browsers and run-times and APIs — that would mean no fragmentation, right? Well, even with run-times from Google with its own APIs, yet another level of fragmentation will be introduced.
It is the way it is.
And not everyone will use Google tools and run-times and APIs. And not all developers want to develop their apps using Web technologies and models. And, mobile web apps are not sufficiently rich and transparent yet to replace local apps.
In any case, I will admit that I share Mr G’s vision on web run-times, as I’ve written many times before here in the weblog, but his message was so overloaded that I’m not really sure if that was Google’s official stand or just Mr. Gundotra’s point of view. For one, today Google is a large corporation, and I won’t be surprised if his comments caused some internal frenzy. You see, his view/solution to the issue of device fragmentation is “one platform”. But, that is exactly the goal of the Android team; reduce the number of mobile platforms out there.
Mr. G also implied that Google will continue to invest (greatly) on their (mobile) web platform with the goal of bringing it at the same level to local (non-web) platforms such as Android. This should translate to extending the browser/web run-times with the APIs and access to device functionality and HW that provides overall greater richness. That translates to investments in Chrome “OS” and the Google APIs including Gears, which are proprietary APIs. As a side-note, why Google didn’t participate on BONDI, which defined APIs for web run-times for application invocation, UI, location, camera and other, might reveal either “political” or proprietary mentality that should concern you (as it concerns me). BONDI and Gears are competing technologies, but they don’t have to be.
But all this push to web run-times and Chrome “OS” doesn’t mean that Google will stop investing on other. You see, Chrome “OS” will become a very strong brand. But Chrome “OS” is a misnomer, as it is not a real OS. And to be able to expose and offer the powerful browsers and rich user interfaces and experiences that the browser-based apps of the future will need, again, access to the functionality and HW underneath is needed – and for this a real underlying OS will exist and perhaps with it an application environment on top of that; in short OS = Linux, App environment = Android. In other words, Google’s investment on Linux and Android won’t go away. With this approach, Google has all the components, from the OS, to the app environment, the web-run-times and the applications to lead and keep it moving ahead, red-shifting from the competition.
App Stores are Dead, Not
Some folks have interpreted Mr. G’s comment as the end of App Stores; see Google forecasts browsers will beat out app stores (FierceMobileContent). But it is not; not sure why that conclusion. App Stores are nothing else than repository/catalog of applications, those being local or web or widget or whatever, for the purpose of discovery regardless of the application model. Thus, expect Google App Store to grow in the future to include widgets, web-based and other apps.
Mr. Jobs, Apple, The View of the Future, But Reality Strikes
Mr. G assumes Steve Jobs “saw the future” when at first the iPhone development was web-based only. Maybe he is right. But the iPhone had an SDK, perhaps primitive, since day one (used for the development of internal apps such as phone dialer, contacts, calendar, and so on). Why would Apple limit access to it? One reason could have been that the SDK was not ready for prime time. But Jobs is a coined operated individual, let’s not forget that. Maybe Mr. Jobs wanted to give access of the SDK (which allows for extremely rich and profitable applications such as games and music and video) to just a few privileged ones — the big power houses such as Sony and others, while the rest of applications by the developer community were to be done via simple Web (perhaps for free). Who knows. But that hypothetical plan didn’t work, and once Apple recognized the real power of the *developer community*, it reacted and offered the SDK; in the end, everyone won, you and me. And the unplanned succeeded. And this same exercise also showed the reality that today mobile web apps are not ready for prime time as compared to the richness and capabilities of local/native apps. There you have it. Native apps are kind today. 🙂
Today vs. Future
Let’s not confuse theory and practice. Let’s not forget why we are doing this. Today is about generating revenue while minimizing cost of development. Tomorrow is about the same, but lets learn and reduce such costs related to investment and operations, and part of this plan is reducing device and application fragmentation. This is important for Goggle as it is about applications and information (and the infrastructure that powers this). Google has two strategies on applications and fragmentation: one Web-based and one local/on-device (Android). Google has the whole SW stack including the OS. And on the top, it is about the information (and its meaning) w.r.t users/people. But it is IMHO that local apps are here to stay; because limiting apps to browser-based apps will be too limiting, in functionality and richness and in programming models and at times in speed. And because it is about the developer community (internal and external), “limiting” will translate to less innovation. And I will even predict that even Chrome OS will allow the user to “switch” to an advanced mode, the native/local apps mode (or a hack will exist for it).
And Mr. Gundotra’s comments are all about the future… So time will tell. And it should not be a too distant future (5 < years)... ceo Related to this:
- Browsers vs. native apps: Vic Gundotra’s comments – Ecosystems, HTML5 and Long tail (Open Gardens)
- Google Says Mobile Web Apps Will Win In The Long Haul (MobileCrunch)
- Mobile Web – It’s about the (mobile web) runtime
- The Future of Web Applications is “Local”
- Browser Swallows OS, Part 2 — the Real Thing