Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
Smartphone OS market share in 2006
tote_b5 | 20 February, 2007 15:07
An article on smartphone OS market share by region (between 2004 and 2006) made me think. Since I'm an analytical mind and also interested in this topic I've automatically started to compare the two figures. And as the author of the aforementioned article has left the analysis part to us (or was he just too lazy?:), I've taken the effort to draw some conclusions from the figures.
So, let's take the regions one by one as shown on the figures!
- European, Middle-East and Africa (EMEA): Symbian still rules smartphone OS market here.
- In Japan almost the whole market was ruled by Symbian in 2004. This has significantly changed by 2006 since Linux has appeared on the horizon with its ~40%! I bet Symbian is not too happy about it, even if they have shipped lots of new phones in Japan recently.
- China: first, let's start with that Microsoft was present on the market in 2004. In contrast, their market share has dramatically shrunk almost to non-existent by 2006. Second, Linux is yet again an important factor that analysts and more importantly phone manufacturers must take into account in 2006. Its roughly 40% market share is very considerable. Third, the strange thing is that Symbian's market share has remained intact during these two years - it's still around 60%.
- North-America: one of the strangest markets - at least from our analysis' point of view! In 2004, Palm phones were dominating the smartphone market (~50%). Their market share, though, has dramatically shrunk to less than half of their previous share (now ~20%). The same pattern can be observed with regards to the popularity of Symbian OS - but with different numbers. In 2004, Symbian was the second smartphone OS vendor dominating 30% of the market - in contrast they're now the fourth with their ~10%! Who won then? Surprise-surprise: Microsoft! They were the third most popular OS vendor in 2004 (~10%) and now they're the #1 with ~30%! The last observation is that RIM has pretty much gained position - they're the second now.
- Finally, the rest of the world (ROW): well, similarly to EMEA market Symbian phones are in monopoly.
As a brief summary my findings are as follows. Symbian's hegemony is noticable all around the world. In most places more than half of the smartphone OS market is in their hand(held)s. :) With one exception, though: North-America. There are couple of interesting articles (on SymbianGuru, Darla Mack's and Tommi's blogs) as to why Symbian, most notably S60 phones are not present in North-America so it wasn't surprising for me to see the trend. It came as no surprise, either, that Microsoft is just there in North-America - what I found interesting, though, that basically this is the only market where they are taken into account at all. Finally, it's already a cliche that Linux phones are coming. LiMo, MontaVista's Mobilinux and TrollTech are just a few keywords everybody blessed with a little foresight might want to memorize. Japan and China are two countries where experiments are being made with mobile linux - and their success seems to be tangible. But let's not continue the debate on which mobile platform is the best and more importantly who will win in the long run. On the one hand, that's impossible to predict, on the other hand it's worth another article. :)
Anything to add?
Tote
So, let's take the regions one by one as shown on the figures!
- European, Middle-East and Africa (EMEA): Symbian still rules smartphone OS market here.
- In Japan almost the whole market was ruled by Symbian in 2004. This has significantly changed by 2006 since Linux has appeared on the horizon with its ~40%! I bet Symbian is not too happy about it, even if they have shipped lots of new phones in Japan recently.
- China: first, let's start with that Microsoft was present on the market in 2004. In contrast, their market share has dramatically shrunk almost to non-existent by 2006. Second, Linux is yet again an important factor that analysts and more importantly phone manufacturers must take into account in 2006. Its roughly 40% market share is very considerable. Third, the strange thing is that Symbian's market share has remained intact during these two years - it's still around 60%.
- North-America: one of the strangest markets - at least from our analysis' point of view! In 2004, Palm phones were dominating the smartphone market (~50%). Their market share, though, has dramatically shrunk to less than half of their previous share (now ~20%). The same pattern can be observed with regards to the popularity of Symbian OS - but with different numbers. In 2004, Symbian was the second smartphone OS vendor dominating 30% of the market - in contrast they're now the fourth with their ~10%! Who won then? Surprise-surprise: Microsoft! They were the third most popular OS vendor in 2004 (~10%) and now they're the #1 with ~30%! The last observation is that RIM has pretty much gained position - they're the second now.
- Finally, the rest of the world (ROW): well, similarly to EMEA market Symbian phones are in monopoly.
As a brief summary my findings are as follows. Symbian's hegemony is noticable all around the world. In most places more than half of the smartphone OS market is in their hand(held)s. :) With one exception, though: North-America. There are couple of interesting articles (on SymbianGuru, Darla Mack's and Tommi's blogs) as to why Symbian, most notably S60 phones are not present in North-America so it wasn't surprising for me to see the trend. It came as no surprise, either, that Microsoft is just there in North-America - what I found interesting, though, that basically this is the only market where they are taken into account at all. Finally, it's already a cliche that Linux phones are coming. LiMo, MontaVista's Mobilinux and TrollTech are just a few keywords everybody blessed with a little foresight might want to memorize. Japan and China are two countries where experiments are being made with mobile linux - and their success seems to be tangible. But let's not continue the debate on which mobile platform is the best and more importantly who will win in the long run. On the one hand, that's impossible to predict, on the other hand it's worth another article. :)
Anything to add?
Tote
General |
Permalink |
Comments (7) |
Trackbacks (0)
Symbian vs iPhone
tote_b5 | 08 February, 2007 15:45
I've found a link (thanks, Peter, for sharing) to an interesting article that details why iPhone's (and Apple's) OSX is better than Symbian OS and how it's going to beat it. I have some thoughts about the author's arguments, let me share them.
In most regards, Symbian's reputation as a modern, robust, stable and advanced OS for smartphones is not well deserved. Sure, Symbian works, it has a very long feature list, and it's probably even the best smartphone OS available today. But it's mostly because the competition is pathetic than anything else.
I must disagree with this statement. You might argue that the OS is not modern as lots of "not-so-new" features, such as STL, is not included, but this does not necessarily mean that it's not modern at all. How can you claim that the system is not robust, stable or advanced? How do you measure it? I don't think Symbian OS is worse in general than its competitors. On the contrary, I believe it's very robust and stable. Just an evidence: it can run for days, weeks without having to reboot it. Just show me another (preferably open) mobile OS that can do the same. And you mentioned that it had a very long feature list and the OS was the best today. Based upon all of this why do you say that the OS has not deserved to be the #1 OS for mobile phones?
The Three Symbians
From one point of view, there are no ‘Symbian’ phones in the market, but rather three incompatible and diverging OSs: NTT DoCoMo's Symbian MOAP for Asia, Nokia’s Symbian S60, and Sony Ericsson’s Symbian UIQ.
You're right and wrong. You're right that there is a very thick layer (S60, UIQ and MOAP) on top of the core Symbian OS that makes the three platforms incompatible at some extent. But you're wrong, because you can minimize the difference between these variants with some clever effort. For example, most engine components can be written with a common codebase. Which is not true if you compare different OSes like Windows, Palm, etc.
On the other hand, there's no better solution, I'm afraid. Neither Java nor Linux brings us the *ultimate solution*. And I'm sure it's clear for everyone why I'm not talking about WinCE here. Unfortunately, mobile OS market seems to be heading to divergence rather than convergence.
Finally, variation for iPhone and OSX is not an issue here as there is nothing to variate yet.
To make it even worse from a third party developer's point of view, Nokia and Symbian made the new S60 version 3 binary incompatible to previous versions of S60. So none of your old Symbian apps will work on any new phones (i.e. if you actually bought any :-).
You shouldn't be so cynical. Actually lots of phones have already been sold that are based on S60 3rd Edition. It's just one thing that you do not know it.
Symbian Signed
So much for independently third-party software development on Symbian compared to the ‘closed’ model used on iPhone. In practice the difference is not that big. Apple will, of course, allow close partners to develop apps like they do with iPod Games today.
"In practice", the difference is HUGE imho. In case you have not noticed, Symbian phones are not closed as opposed to (the almost) closed iPhone. I presume that to be a close partner of Apple will be much more difficult than to have your application Symbian Signed. And in lots of cases your application doesn't even have to be Symbian Signed - it all depends on what you want to use on the phone. You know, most applications are able to run smoothly with the most basic capabilities (or even without them) that do not require your application to be signed. I suggest you to take some lessons on how Symbian Signed works before judging it.
And you know, this is the price phone manufacturers have to pay to operators in order for their device to be sold. I believe it's still better than not being chosen as a 'close partner'.
Symbian Design Issues
... entire section ...
While I agree with you with regards to most of the technical issues you listed, I have one question: what do you expect from Symbian to do? Do you expect them to withdraw all those design decisions that they've made during those days when it was reasonable to make those decisions? You know, it's easy to criticize, but very hard to offer alternatives ... Not to mention the fact that it would most probably introduce another bunch of source/binary breaks in most programs. Obiously, it would be especially painful these days since we have not yet recovered from the shock of Platform Security. Instead, Symbian should make a smooth transition from old design to new (if it's reasonable), which will naturally take some time.
Analysts Wrong on Symbian
Most media in Sweden (and elsewhere) have reported that the iPhone is nothing new at all. It's mainly a nice package with limited/bad hardware and nothing particularly new on the software side.
Isn't that true?
However, if you look at the speed and effort needed to make new applications on iPhone compared with other platforms it's two completely different worlds.
I'm a little bit confused: does it make sense to make new applications for iPhone? Most probably you won't be able to install them at all.
Existing Mobile Platforms vs OS X
With Symbian (as well as WinCE, Palm OS, and I suppose also the Linux phones because they probably have a very limited number of Linux frameworks installed because of memory restrictions etc) you have a big problem to deliver on the marketing hype and media expectations because of all limitations. This is one of the reasons all mobile services are failing to badly—it's simply to hard and complicated to deliver the market expectations with today's platforms.
At this point I must admit that I have never used OSX (consequently never programmed for it, either). But regardless of that still wondering how OSX and iPhone overrule the rest of the mobile platforms?
Five Years Ahead
... entire section ...
Well, here I again must admit that I have never used Objective-C in my life. Thus, I can't make my own decision about this issue based on my own experience. What I have heard, though, from people who had used it is that it was very uncomfortable for them to use that language. And they felt sort of a freedom when they had changed from ObjC to C++. There weas no-one who told me that ObjC was (a) better (experience) than C++. Knowing that, is it really the language, the foundation, based on which a new mobile OS will rise and overrule the others? I don't think so, but please disprove me.
Nevertheless, I can see that you're right at some point. There're lots of things to improve, only a few examples:
- Documentation ==> developers spend a lot of time with browsing technical documentation. And it's by far not perfece/complete. One of the main (true) complaints about learning Symbian is that it has a very long learning curve. Although I think we're heading to the right direction (good examples in the SDKs, good and thorough books, trainings, forums, etc.) it still takes too much time for a beginner to get used to Symbian. We definitely need more better tools, for example, Carbide.C++'s UI Designer is another good step to the right direction. And Symbian and its stakeholders must realize it and take actions against it (I mean, the long learning process) in order for developers still to be motivated to write programs for Symbian.
- Tools ==> it's a cliche that there's no ultimate tool for Symbian development. What is even more painful that there is no single *free* tool that anybody could use with great benefit. For example, when Nokia made a political decision about not to support MS Visual Studio in their SDKs they should have already come out with a better alternative instead of MS VS. Not with CodeWorrier, of course. I believe that instead of investing so much money and time in CW Nokia should have turned to open source community sooner and then we would have a better, more stable and useful tool (Carbide.C++) by now. In my opinion, if Symbian and "their companion" want to give a boost to Symbian development, then they should provide/use free tools that simply work. Okay, it's easy to say, but still...
Tote
In most regards, Symbian's reputation as a modern, robust, stable and advanced OS for smartphones is not well deserved. Sure, Symbian works, it has a very long feature list, and it's probably even the best smartphone OS available today. But it's mostly because the competition is pathetic than anything else.
I must disagree with this statement. You might argue that the OS is not modern as lots of "not-so-new" features, such as STL, is not included, but this does not necessarily mean that it's not modern at all. How can you claim that the system is not robust, stable or advanced? How do you measure it? I don't think Symbian OS is worse in general than its competitors. On the contrary, I believe it's very robust and stable. Just an evidence: it can run for days, weeks without having to reboot it. Just show me another (preferably open) mobile OS that can do the same. And you mentioned that it had a very long feature list and the OS was the best today. Based upon all of this why do you say that the OS has not deserved to be the #1 OS for mobile phones?
The Three Symbians
From one point of view, there are no ‘Symbian’ phones in the market, but rather three incompatible and diverging OSs: NTT DoCoMo's Symbian MOAP for Asia, Nokia’s Symbian S60, and Sony Ericsson’s Symbian UIQ.
You're right and wrong. You're right that there is a very thick layer (S60, UIQ and MOAP) on top of the core Symbian OS that makes the three platforms incompatible at some extent. But you're wrong, because you can minimize the difference between these variants with some clever effort. For example, most engine components can be written with a common codebase. Which is not true if you compare different OSes like Windows, Palm, etc.
On the other hand, there's no better solution, I'm afraid. Neither Java nor Linux brings us the *ultimate solution*. And I'm sure it's clear for everyone why I'm not talking about WinCE here. Unfortunately, mobile OS market seems to be heading to divergence rather than convergence.
Finally, variation for iPhone and OSX is not an issue here as there is nothing to variate yet.
To make it even worse from a third party developer's point of view, Nokia and Symbian made the new S60 version 3 binary incompatible to previous versions of S60. So none of your old Symbian apps will work on any new phones (i.e. if you actually bought any :-).
You shouldn't be so cynical. Actually lots of phones have already been sold that are based on S60 3rd Edition. It's just one thing that you do not know it.
Symbian Signed
So much for independently third-party software development on Symbian compared to the ‘closed’ model used on iPhone. In practice the difference is not that big. Apple will, of course, allow close partners to develop apps like they do with iPod Games today.
"In practice", the difference is HUGE imho. In case you have not noticed, Symbian phones are not closed as opposed to (the almost) closed iPhone. I presume that to be a close partner of Apple will be much more difficult than to have your application Symbian Signed. And in lots of cases your application doesn't even have to be Symbian Signed - it all depends on what you want to use on the phone. You know, most applications are able to run smoothly with the most basic capabilities (or even without them) that do not require your application to be signed. I suggest you to take some lessons on how Symbian Signed works before judging it.
And you know, this is the price phone manufacturers have to pay to operators in order for their device to be sold. I believe it's still better than not being chosen as a 'close partner'.
Symbian Design Issues
... entire section ...
While I agree with you with regards to most of the technical issues you listed, I have one question: what do you expect from Symbian to do? Do you expect them to withdraw all those design decisions that they've made during those days when it was reasonable to make those decisions? You know, it's easy to criticize, but very hard to offer alternatives ... Not to mention the fact that it would most probably introduce another bunch of source/binary breaks in most programs. Obiously, it would be especially painful these days since we have not yet recovered from the shock of Platform Security. Instead, Symbian should make a smooth transition from old design to new (if it's reasonable), which will naturally take some time.
Analysts Wrong on Symbian
Most media in Sweden (and elsewhere) have reported that the iPhone is nothing new at all. It's mainly a nice package with limited/bad hardware and nothing particularly new on the software side.
Isn't that true?
However, if you look at the speed and effort needed to make new applications on iPhone compared with other platforms it's two completely different worlds.
I'm a little bit confused: does it make sense to make new applications for iPhone? Most probably you won't be able to install them at all.
Existing Mobile Platforms vs OS X
With Symbian (as well as WinCE, Palm OS, and I suppose also the Linux phones because they probably have a very limited number of Linux frameworks installed because of memory restrictions etc) you have a big problem to deliver on the marketing hype and media expectations because of all limitations. This is one of the reasons all mobile services are failing to badly—it's simply to hard and complicated to deliver the market expectations with today's platforms.
At this point I must admit that I have never used OSX (consequently never programmed for it, either). But regardless of that still wondering how OSX and iPhone overrule the rest of the mobile platforms?
Five Years Ahead
... entire section ...
Well, here I again must admit that I have never used Objective-C in my life. Thus, I can't make my own decision about this issue based on my own experience. What I have heard, though, from people who had used it is that it was very uncomfortable for them to use that language. And they felt sort of a freedom when they had changed from ObjC to C++. There weas no-one who told me that ObjC was (a) better (experience) than C++. Knowing that, is it really the language, the foundation, based on which a new mobile OS will rise and overrule the others? I don't think so, but please disprove me.
Nevertheless, I can see that you're right at some point. There're lots of things to improve, only a few examples:
- Documentation ==> developers spend a lot of time with browsing technical documentation. And it's by far not perfece/complete. One of the main (true) complaints about learning Symbian is that it has a very long learning curve. Although I think we're heading to the right direction (good examples in the SDKs, good and thorough books, trainings, forums, etc.) it still takes too much time for a beginner to get used to Symbian. We definitely need more better tools, for example, Carbide.C++'s UI Designer is another good step to the right direction. And Symbian and its stakeholders must realize it and take actions against it (I mean, the long learning process) in order for developers still to be motivated to write programs for Symbian.
- Tools ==> it's a cliche that there's no ultimate tool for Symbian development. What is even more painful that there is no single *free* tool that anybody could use with great benefit. For example, when Nokia made a political decision about not to support MS Visual Studio in their SDKs they should have already come out with a better alternative instead of MS VS. Not with CodeWorrier, of course. I believe that instead of investing so much money and time in CW Nokia should have turned to open source community sooner and then we would have a better, more stable and useful tool (Carbide.C++) by now. In my opinion, if Symbian and "their companion" want to give a boost to Symbian development, then they should provide/use free tools that simply work. Okay, it's easy to say, but still...
Tote
General, Symbian C++ |
Permalink |
Comments (3) |
Trackbacks (0)
Do you think that PlatSec signing process is a nightmare?
tote_b5 | 05 February, 2007 15:10
Well, then let me share the following article with you about midlet signing. It describes how painful a Java midlet signing process can be. In addition to that, it also contains some basic information about how signing works (e.g. chain of certificates) and what it costs. Shocking experience. :-
From signing and capabilities/permissions point of view I would say they're the same. You know, it's one thing that you've got to be familiar with a security system that sometimes simply doesn't work (unless you invest much-much money in it), the bigger problem that most developers suffer from is that you even have to pay for it. As security is our common concern wouldn't it make sense to introduce such a system in which nobody pays to nobody? You know, not only is the concern common, but the benefit would also be mutual. I know I'm so naive. :-
Tote
From signing and capabilities/permissions point of view I would say they're the same. You know, it's one thing that you've got to be familiar with a security system that sometimes simply doesn't work (unless you invest much-much money in it), the bigger problem that most developers suffer from is that you even have to pay for it. As security is our common concern wouldn't it make sense to introduce such a system in which nobody pays to nobody? You know, not only is the concern common, but the benefit would also be mutual. I know I'm so naive. :-
Tote
General, Java |
Permalink |
Add comment |
Trackbacks (0)
Cost monitoring
tote_b5 | 02 February, 2007 10:44
I've started wondering just recently why there is no support at all for cost monitoring on our phones? Okay, on S60 phones there are two applications where you can monitor
- how much time you've spent with speaking on the phone,
- how much data you've up/downloaded.
You've spotted that neither tells how much money you'll have to pay at the end of the month, right?
Obviously, one of the main reasons why there is no such an application on your phone is that there is no such application on the market. Neither built in your phone. Is it that simple, huh? Not really. Let's think about it how our application should work:
- it either keeps track of how much time you've spent with speaking (you called someone or someone called you while you're abroad) and also monitors how much data you've exchanged (up/download, SMS, MMS, etc.).
- or connects to your operator's site and download data from there.
Let's examine these two options in more depth:
- Keeping track of everything on client side: it makes sense to do it as most of the required features are already present. I guess, at least as I presume here that the APIs Logs and Connection Manager applications make use of are publicly available. What is missing, though, the information that could be used to figure out the actual costs. Okay, the tariff could be retrieved from various places and eventually could be typed in into our fictitious Cost Monitor application as well, but first users are usually pretty much lazy to do that, second it's not even trivial to find out which rate we should apply when. For example, how do you know what rate to apply when you're abroad? You can't expect that the user will do all these operations as it's pretty much laborious. Even I would not do that. :- Not to mention the fact that even though it's kept track of e.g. how much data you've downloaded, but I doubt that I could figure out which bearer (e.g. 3G, WLAN) I used each time. As usually we use public WLAN service free of charge or pay for it when we're there, I wouldn't like to see those figures in my calculations. And I'm sure that there are other issues as well that we would need to tackle to get a correct end result.
Briefly: it would be pretty much challenging, if not impossible, to write such an application and even if it was possible it would put a big burden on users' shoulders to manage the application.
- On the other hand, if Cost Monitor application was only a thin client that could connect to the operator's site, then we could put all the burden of implementing the calculation logic on operators' shoulders (can you imagine an operator with shoulders?:). Which, in fact, has already been implemented as operators always know it pretty well how much money they can pull out from your pocket. I guess, some of you have already found it out that there is a little problem with this approach. Not implementation-wise, but from strategic point of view. And well, the problem is not only little, but HUGE: operators will never make such a service (e.g. a Web Services API) available publicly. It's simply not in their interest as it might inspire their clients (i.e. us) to have better control over their costs.
Finally, I did not go into details as to the features of our Cost Monitor application. The obvious one would be to give visual representation of the user's costs. A non-obvious, but very useful, one would be to be notified upon reaching/approaching a pre-set limit. I'm sure that everyone can immediately see why this feature would be opposed by operators - whose help we would rely on, btw.
Looking forward to your comments!
Tote
- how much time you've spent with speaking on the phone,
- how much data you've up/downloaded.
You've spotted that neither tells how much money you'll have to pay at the end of the month, right?
Obviously, one of the main reasons why there is no such an application on your phone is that there is no such application on the market. Neither built in your phone. Is it that simple, huh? Not really. Let's think about it how our application should work:
- it either keeps track of how much time you've spent with speaking (you called someone or someone called you while you're abroad) and also monitors how much data you've exchanged (up/download, SMS, MMS, etc.).
- or connects to your operator's site and download data from there.
Let's examine these two options in more depth:
- Keeping track of everything on client side: it makes sense to do it as most of the required features are already present. I guess, at least as I presume here that the APIs Logs and Connection Manager applications make use of are publicly available. What is missing, though, the information that could be used to figure out the actual costs. Okay, the tariff could be retrieved from various places and eventually could be typed in into our fictitious Cost Monitor application as well, but first users are usually pretty much lazy to do that, second it's not even trivial to find out which rate we should apply when. For example, how do you know what rate to apply when you're abroad? You can't expect that the user will do all these operations as it's pretty much laborious. Even I would not do that. :- Not to mention the fact that even though it's kept track of e.g. how much data you've downloaded, but I doubt that I could figure out which bearer (e.g. 3G, WLAN) I used each time. As usually we use public WLAN service free of charge or pay for it when we're there, I wouldn't like to see those figures in my calculations. And I'm sure that there are other issues as well that we would need to tackle to get a correct end result.
Briefly: it would be pretty much challenging, if not impossible, to write such an application and even if it was possible it would put a big burden on users' shoulders to manage the application.
- On the other hand, if Cost Monitor application was only a thin client that could connect to the operator's site, then we could put all the burden of implementing the calculation logic on operators' shoulders (can you imagine an operator with shoulders?:). Which, in fact, has already been implemented as operators always know it pretty well how much money they can pull out from your pocket. I guess, some of you have already found it out that there is a little problem with this approach. Not implementation-wise, but from strategic point of view. And well, the problem is not only little, but HUGE: operators will never make such a service (e.g. a Web Services API) available publicly. It's simply not in their interest as it might inspire their clients (i.e. us) to have better control over their costs.
Finally, I did not go into details as to the features of our Cost Monitor application. The obvious one would be to give visual representation of the user's costs. A non-obvious, but very useful, one would be to be notified upon reaching/approaching a pre-set limit. I'm sure that everyone can immediately see why this feature would be opposed by operators - whose help we would rely on, btw.
Looking forward to your comments!
Tote
Business Opportunities/Services, S60 |
Permalink |
Comments (9) |
Trackbacks (0)
Author Profile
Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
calendar
recently...
- Brief status report about smartphone market, mid-2008
- Symbian and Nokia wrestling about voting rights?
- Static vs active application icons
- Cross-platform development
- Collection of great materials on Symbian going open-source
- Browser as an application platform
- iPhone for 1 Euro?
- Pay or not to pay for incoming calls and messages?
- Nokia stirs water with mobile Linux
- Mobile software development - Functional testing
Categories
- Symbian Foundation [2]
- Nokia [2]
- Android [2]
- Linux [5]
- Development [5]
- Innovation [1]
- Symbian [6]
- Windows Mobile [5]
- Platform Security [1]
- iPhone [6]
- UI [2]
- Mobile OS [10]
- Testing [3]
- Symbian C++ [11]
- Series 80 [0]
- Series 40 [0]
- S60 [13]
- Python [0]
- Open C [1]
- Messaging [0]
- Location Based Services [1]
- Java [3]
- General [16]
- Games [0]
- Flash [1]
- Event [5]
- Entertainment [0]
- Enterprise [2]
- Connectivity [2]
- CDMA [0]
- Business Opportunities/Services [16]
- Browsing [4]
