One of the big takeaways from the Web 2.0 Expo is Google's belief that the mobile phone is gaining momentum as the defacto platform for applications. Vic Gundotra, Google's VP Engineering emphasized this point in his keynote and also in an interview with Tim O'Reilly.
Here's some of what he said -
"The mobile phone is the most personal of personal computers"
I don't think anyone would dispute that statement today but that shows how far our thinking as an industry has evolved over the past 3-4 years. Five years ago, few viewed the mobile phone as a platform for applications. Now, thanks to the iPhone, running apps on a phone is commonplace.
"This year, in 2009, we'll sell more Internet-connected phones as an industry than the entire notebook market."
Of course, just because phones are Internet enabled, doesn't mean that everyone is actively leveraging that capability.
According to Jason Grigsby from Cloud Four, when it comes to the notion of "mobile phone as a new PC", it's the iPhone that's king -
- 95% of iPhone users regularly surf the Internet
- Google sees 50 times greater number of searches from iPhones than from any other device (especially remarkable since iPhone has something like 1% of mobile phone market)
- AppStore is a huge success with 10,000 apps and 300 million downloads in 2008
Despite the success of iPhone, here's the looming issue for mobile applications raised by Grigsby - should they be developed as native, platform proprietary applications or web enabled applications? While native applications have possible advantages in performance optimization and user experience, I see two issues with regard to native applications -
First, the economic impact of non-portability. This means that when an app developer writes a native application for the iPhone, he cannot fully monetize the true value of the application across all mobile platforms. In essence, he's limited his addresseable market.
He can, of course, choose to port his application to other platforms but it's going to cost him.
Second, the issue of "openness". Native applications allow mobile platform providers to exert control over what applications are permitted and which are not. Take the case of Newber - the iPhone application that would provide functionality similar to Google Voice. Approval for Newber has been pending for over 186 days (check out the counter on their website), leading the CEO of FreedomVoice Systems, the developer of Newber to suspend development and issue an open letter to Apple. That, my friends, is what exerting control looks like and it can stifle both innovation and competition.
I do love my iPhone but I'm hoping the future of mobile applications are web-based and not native. What do you think?
I agree everything is moving to the cloud. I am impressed with Google Voice. If you are interested in seeing it in action I just posted a walkthrough / review to my blog at techietalker.com
Keep up the good posts!
Matt - thanks for stopping by. I plan to check out the Google Voice review at your blog too.
Cloud computing is the way to go thereby keeping companies on their toes as to what apps to create as the market dictates not as exampled in your article of companies hoding leverage over the technological advancements. I am OK with say Google hosting my files. I must say I have had trouble with Amazon with all the different logins and security checks (albeit needed). The prcess needs to be simple yet robust in terms of security. Over to the techies :)
Mike - I'm with you on keeping apps in the cloud, using open standards and setting the stage for innovation and constructive competition. You said you're ok with google - presumably you're aware of the flak google has received over security/privacy breach recently -
http://www.techcrunch.com/2009/03/07/huge-google-privacy-blunder-shares-your-docs-without-permission/
Andre Great post. I agree with you on non-portability issues with Mobile applications but I don't think Web based application for mobile computing is the answer. Two basic issues which tells us that we are at a early stage for web based apps for Mobile devices
1.Push or Pull technology how does a mobile device receive information it can be a email or text message or any other activity for that mobile user. I'm not sure web based solution will have a answer for this.
2.Bandwidth, the more smarter the application is the more mobile bandwidth it takes to deliver it's functionality.
Prakash - I hear you on this but consider that mobile broadband is here and is getting better.
Also, I did forget to mention in my post about PhoneGap, a company that allows developers to develop to one framework but is portable across mobile platforms
I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.
Sarah
Sarah - thanks for your kind comments. Please stop by again
Andre,
If "native" simply means "code on the phone that's crunched by the phone's CPU," then "web-based vs. native" may be a false dichotomy. AJAX-heavy web sites make the lines between these rather blurry. Tools such as Google Gears would cross boundaries even more so. And it's possible to have a "web application" that resides on and is run within the phone and never makes a network call! (Example: I have WordPress installed on my laptop for logging my personal notes; it's firewalled from the rest of the known universe.)
The way I would put it -- which, I suspect, is in keeping with your view -- is to hope for the following:
1) Future mobile phones have usable web browsers; support for CSS, RSS, JS, Flash, Java, and an open-source SQL database (e.g. SQLite); a readily-accessible cache with standard calls for transient or persistent data storage; and can also serve web content to the device itself.
2) Future apps are written to use those standard capabilities.
This makes for rich apps that are handset-independent. It allows apps to be offline, online, or both, with whatever mix of cloud processing and client processing that makes the most sense. And it lets developers hit the ground running.
There's a third element as well: policies by carriers and handset manufacturers that don't choke app deployment. It's both in carriers' interests and users' interests to guard against malicious apps, or apps that are unnecessarily greedy in their use of bandwidth. All too often, however, restrictions on apps are designed in the financial interest of the carrier (e.g., they force use of a carrier's own subscription services), rather than for the users' interests.
Maybe the carriers could agree on a reasonable set of rules/security standards that apps would have to meet, and a third party could certify apps for meeting that standard, and then the apps would be available for installation on the mobile device. (Maybe pigs will fly.)
Having a decent web browser is a big sticking point! And this includes the user interface, not just the ability to render HTML. If navigation or I/O is a hassle, a high-res screen is just a pretty picture.
And I do hope that relational databases are part of the package! That's particularly important for apps used in business.
For the moment I'm stuck with Verizon and a Samsung Alias (QWERTY keyboard). Nominally it supports web browsing, but that's a joke. I pay $5/month for Verizon's POP-based ("pull") email service; it's tolerable if a bit clumsy, and does link to the phone's built-in address book, but that plus SMS plus IM is the extent of what I can do besides make phone calls. :(
Pete Farmer
Pete - thanks for your comments which are rich with compelling points. To clarify, what I mean by native apps is more about the platform proprietary API rather than whether it works in disconnected mode. I view the inability to work in disconnected mode as an issue of an older style web interface - Google Gears and RIA type frameworks will take care of this issue.
I believe browser based, RIA style applications with adherence to open standards as the future of mobile apps.