Join Now

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.

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

Comments

Re: Symbian vs iPhone

coultonp | 09/02/2007, 09:49

coultonp Gabor

Nice blog and I would certainly agree with the thrust of your comments. From my perspective we work in a fragmented market and the iphone merely adds to the situation rather than alleviates the problems. Having been beta testing OpenC I think that will have a big part to play in this debate and I hope to get time to blog that soon

Re: Symbian vs iPhone

tote_b5 | 09/02/2007, 10:38

tote_b5 Thanks, Paul!

Note that I have no problems with iPhone and Apple appearing on mobile market. On the contrary, I welcome this step as I'm waiting for big innovations from Apple. Even if the only thing I can see from Apple is that they'll have a very nice user interface, nothing else. But that's also something.

What I wanted to point out in my blog, though, is that I wouldn't be so brave (stupid?) to make conclusions on a non-existing product and an operating system that has not even entered the mobile phone OS market yet. As we all know, it's one thing if an OS is great on desktops, servers, but it doesn't necessarily mean that it will succeed as a mobile OS, too.

Re: Symbian vs iPhone

coultonp | 09/02/2007, 10:52

coultonp Gabor

I agree its nice to see new products emerging and i too welcome aspects of what apple will bring to the market. It is you say way too early for people to make sweeping judements based on a glossy presentation and minimal blurb and as we know in this market things can change very quickly
You must login to post comments. Login
 
 
Powered by LifeType
     
     RDF Facets:
     
     
     qfnZtopicQUqfnBlogTopicZgeneralQ
     qfnZtopicQUqfnTopicZcppQ
     qfnZtypeQUqfnTypeZBlogContentQ
     qfnZtypeQUqfnTypeZBlogE45ntryQ
     qfnZtypeQUqfnTypeZCommunityContentQ
     qfnZtypeQUqfnTypeZWebpageQ
     qmarsZlanguageQUxhttpE3aE2fE2fswE2enokiaE2ecomE2flanguageE2d1E2fenX