BlackBerry vs. iPhone: What If There Is No Winner?

There has been a lot of excitement in the mobile space lately. The release of the 3G iPhone has made many mark July 11th on their calendars and got many an Apple fan buzzing. BlackBerry is making headlines too with the upcoming BlackBerry Bold. And of course not to be forgotten are the ‘Google phones’, the release of which is said to be on target though likely to arrive a bit later than previously rumoured.

All this has got people wondering who will be the winner in the mobile space. Is Apple going to dominate the space with the slick iPhone design and even slicker marketing, or is the headstart enjoyed by BlackBerry devices combined with their strong grip on the enterprise market enough for them to clinch the top spot? Or could Google come out of left field with whatever it is going to come out of left field with and crush both RIM and Apple into oblivion?

But lets pause here for a second and ask ourselves, what if there is no clear winner at the end of the day? In other words, what if the smartphone market is simply not a winner-take-all industry?

For one, customer needs in the space may be too diverse for a single player to successfully satisfy them all. Early signs are starting to develop that this might be the case. Both the iPhone and the BlackBerry have successfully captured a core market, and users in either ‘core’ have little reason to switch at present. The 300-emails-a-day corporate user who wants mobile access to his company’s CRM system will probably continue being a BlackBerry customer, and the cool kid with voracious appetite for web content and YouTube videos will likely stick to his iPhone.  When I was thinking of which platform to launch my startup on, BlackBerry was the natural choice just because my app requires certain amount of typing and BlackBerries are considered to be more typing-friendly.

Another argument against the winner-take-all scenario is that the smartphone market may be growing too fast for any single company to be able to successfully dominate. BlackBerries are selling at a blistering rate: Research in Motion sold 9.4mln devices so far in FY 2008 compared with 4.4mln in the same period FY 2007 for an annualized growth rate of 114% (link to quarterly financial statement here). And judging from all the excitement around the 3G iPhone, it will probably sell many millions in less the time it takes to say “I’ll have the chicken, please”. Over at Sprint, the new Samsung Instinct touchscreen smartphones are flying off the shelves like crazy too.

Dominating an industry that is growing at a break-neck speed may be tough to achieve, even for great companies like RIM and Apple.

So the BlackBerry is popular in the segment that it targets, and the iPhone is popular in the segment that it targets. In fact, it is easy to imagine a few more segments developing in the smartphone space over the next little while as the industry expands and evolves. This will give the opportunity for new players to step in and make a lasting impression or for the existing ones to capture more market share.

Here are a few segments that will likely develop:

1.The smart phone under $50 (but without a plan). Smart phones are currently too pricey for mass adoption, especially in emerging markets. Fifty dollars sounds on the low side these days, but just like a lot of other things in technology, if it looks impossible now, just give it a couple of years. Intel is already stacking its chips accordingly and making a heavy investment in a super-small and cheap mobile processors. Nokia has done well in the lower price points in the cellphone market for years and they are making their move in this space too with the release of the E71 (Boy Genius Report on the E71 here). Price is not there yet, but just give it time, just give it time…

2. The smartphone - extension to the user’s computer(s). The ability for users to have transparent and seamless access to the same information at home or at work as they have on their mobile devices without having to initiate some sort of a manual sync would be killer feature. And the rapid emergence of clouds can be a major catalyst here - mobile syncs to cloud, cloud syncs to PC, etc. MobileMe looks like the first crack at this, but at $99/year it will likely not be massively adopted overnight.

Humm, can anyone think of a large company with massive cloud infrastructure and growing mobile aspirations?

Honorable mentions in this category here goes to Windows Mobile devices for enabling users to view their MS Office files on the go. While viewing spreadsheets on your mobile device may not overly excite many, Microsoft has recently unveiled their Mesh project, which aims to give users the ability to sync files across devices. Could it be that MS Mesh evolves into a MobileMe for the enterprise?

3. The app phone. No, it ain’t going to be the iPhone. A large amount of software is bought by companies and they are going to choke at Steve Job’s 30% cut. Do you see Microsoft giving 30% to Apple for each download of Word Mobile? I don’t think so either.

The BlackBerry’s platform is developer-friendly (kind of), but the absence of an App Marketplace is a set-back. The title in this category is pretty much out for grabs. A glimpse of an Android demo showed an icon labeled “Market” which got people speculating.

Oh it looks like it is going to be an interesting year in the mobile space!

Why Certification was useful for me

The topic of developer certification has stirred a lot of debate recently. Is it good, is it bad, is it just downright evil? Raganwald recently jumped ship on the certification debate with his Certification? Bring it On!. An excellent rebuttal over at Enfranchised Mind was quick to follow and made some excellent points as well.

But I as a developer found certification useful for reasons somewhat different than what these guys are talking about. Certification worked well for me because going through the actual process (I did the Sun Certified Java Programmer about a year ago) made me brush up on areas of the Java platform that, for one reason or another, I hadn’t had much exposure to in my professional life up until that point.

The companies that I have worked for in the past few years are pretty established and by the time I joined them, certain parts of their code base like handling times, formatting dates, threading or doing I/O etc. were pretty mature, stable and bug-free and had been so for a long time. Not much work was needed there. So after a couple of years of Java development out in the industry I found myself not completely satisfied with my knowledge in some of those areas.

Going through the certification process not only gave me a structured and focused way of covering areas that my professional experience didn’t touch on or just touched on fairly lightly. It was also a good segway (or an excuse for a segway) into digging out more information on some of the topics that the certification book just mentioned but didn’t elaborate to the extent that I would have liked.

Was there sufficient material on these topics in the SCJP to achieve what I personally would consider reasonable proficiency? Sometimes yes, sometimes not. Certain topics like generics are covered in a much more enlightened way in articles like Gilad Braha’s Generics in the Java Programming Language than they are treated in the SCJP. But hey, the certification curriculum was a good starting point.

Now, is getting certified the only way to brush up those “dusty corners”? Absolutely not. Developers can achieve the same result in a myriad of other ways without having to pay the $200 for taking the exam (shame on you Sun for upping the fees again!). Do an interesting project on the side, launch a cool site or just regularly scan the various posts on dzone. There is plenty of good stuff out there to keep you well-informed and your skill set current.

Certification is just something that worked for me. And if you are a junior to intermediate developer, it may work for you for the same reasons, especially if you work in larger company where the projects last for many months and responsibilities usually cover a small part of the end product and require skills that mostly fall in a narrow subset of the languages/technologies used.