Inside Symbian: the Platform Nokia Secretly Hates

DECS writes "The Symbian OS runs the majority of todays smartphones, and is generally regarded as a solid platform. All is not well behind the scenes however. Here's why Apple ported its own OS X to the ARM architecture for the iPhone, why Motorola left Symbian for Linux, and why Nokia executives secretly regard Symbian with contempt. An inside look from Symbian developers: Readers Write About Symbian, OS X and the iPhone."

Comments

I own a Nokia E61

[thammoud]

While the phone is nice, the software is very slow and quirky. IMAP support is abysmal. I guess you can write slow software in any language.

Re:I own a Nokia E61

[Bowdie]

Have you got the left hand side hard button set to that? When you press that button, the phone waits five seconds for you to press * to lock the handset. It's a throw back to the old "MENU *" handset lock all Nokias do.

Try setting another button to the function, and see if it still takes that time.

Hope that helps

Re:Oh, RoughlyDrafted.com

[xoyoyo]

(I say "no longer", but then I don't recall Motorola ever making a Symbian phone...)

They made three: the A1000, the A920 and the A925. They were all horrible. The horribleness of Motorola phones has nothing to do with OS

Hmmm... which link should I read???

[bad_fx]

The summary seems to imply that:

* The first link explains why Apple ported OS X (obvious IMO)
* The second link explains why motorola moved to Linux (again obvious IMO)
* The third link is some thoughts from Symbian Developers.

So... if I want to find out why it's "The Platform Nokia Secretly Hates" which bloody link should I read? Bleh, bugger it, I think I'll just read none of them and complain about it instead. That's what /. is all about right? =)

(Seriously though... the only bit of the summary that doesn't link to anything is the "Nokia Hate" bit so wtf man?)

Re:Oh, RoughlyDrafted.com

[UnknowingFool]

I'm pretty sure Apple ported OS X for the same reason as Microsoft ported Windows CE. It was their OS. They have complete freedom to do as they wish with it. It's a good platform. Why the hell not?

The point in the series of articles is why Apple chose to port OS X instead of using Symbian, Linux, etc. After all, Apple doesn't use OS X on the iPod. Developing applications for mobile devices is not easy. Symbian (and Palm) have succeeded so far because their feature set is smaller and easy to maintain. Scaling up on features is harder. Windows and Linux suffer the problem of having too much and it's not easy to trim them down and which version. In fact, Microsoft did not "port" Windows CE. Porting suggests that the OS/program was tweaked to work on a different environmment, hardware, etc. Windows CE is a complete re-write and really only superficially shares the Windows name and look.

Unlike Symbian a ported version of OS X could expand its functionality. Linux is modular like OS X but Linux's problem is with standardization. Each company must maintain their own mobile Linux which makes development harder (Nokia mobile Linux, Sony mobile Linux, LG mobile Linux, etc). Having to maintain their own flavor of Linux is not something that these companies are equipped to do. Thus supporting development is not easy for these companies. Apple needs only to extend their current developers to include a mobile OS X division. Hopefully for Apple, mobile OS X, unlike Windows CE, it's not a new OS but just a new set of APIs.

Re:"the majority of todays smartphones"

[rcs1000]

Rogerborg, normally I appreciate your posts. But this time, I'm afraid you're just plain wrong.

* Qualcomm no longer makes handsets.
* Casio is a very minor player worldwide.
* DoCoMo is not a handset maker, it is the Japanese version of Verizon.
* Hitachi: do they still make mobile phones?
* Samsung *is* the third largest mobile phone maker in the world.

Of all the world's smartphones, 95% run on one of three platforms: Symbian (Nokia, Sony Ericsson), Blackberry (RIM) and Windows Mobile (HTC, Samsung). Samsung, with the BlackJack, is a small player. Trust me, the world's best selling smartphones are in the Nokia N- and E- series. After Nokia, HTC is almost certainly the second best selling smartphone maker.

*Globally* Symbian is not an irrelevance.

Misconceptions in TFA

[mstrom]

As a Symbianophile (and a former Symbian employee) allow to point out some mistakes the author of the TFA has made:

"Nokia's POS/OS. Sources close to Nokia say that Symbian is secretly regarded inside the company--even among high level senior executives--as a "peace-of-shit-OS," explaining that "Finnish people usually have a very coarse language.""

Well from the POV of a SymbianOS developer, it's Nokia that have screwed things up with a very buggy "middleware" S60 layer where (the rumours have it) much of the functionality has been implemented by summer interns and there are some long standing bugs with S60 that make SymbianOS look bad

"And of course UIQ has never been source code nor binary compatible with S60. But still you get the impression from analysts and media that 'Symbian' is one stable OS."

Although they aren't binary compatible, the fact that they both sit on a X-windows-esque Eikon windowing layer means that their Windowing systems are in fact very similar and it's easy to cross-compile for both. Remember that UIQ is for the most part Pen-based whereas S60 is numeric-keypad-based (broadly speaking) and it in fact impressive that these two separate systems can be so easy to port between thanks to them both sitting on SymbianOS for most core tasks.

"Symbian Signed ... makes shareware and hobby programming almost impossible ..."

... I'm sure /. readers understand the necessity for signed s/w on mobiles. Also the point (unquoted) about needed full certifcation is misleading - it just means the user gets are warning dialog like many modern OSs. The situation with J2ME midlets is much the same.

"Some operators are requiring the phones to be locked for any apps not carrying a 'Symbian Signed' certificate"

The biggest issue all of us in the industry have is the power of the network operators customising and locking users in/out of features - this will occur with any OS (and does already with PocketPC) due to he unfortuant power of the networks who control the industry.

"Crippled C++ support They made their own home-cooked version of exceptions called Leaves"

SymbianOS v9 (S60 v3+, UIQ v3+) can use exceptions (although they are Leaves under the hood) - happy now? The point TFA makes here is very uninformed as Symbian jumps through hoops to make it difficult for apps to leak through the combination of CleanupStack and Leaves

"Limited support for multi-threading That was hardly even a relevant argument in 1993 but it meant that Symbian uses 'active objects' instead of threads in almost all applications."

In fact, the cost of a OS context-switch is still high when every bit of battery power matters - battery technology hasn't changed that much since 1993

"Bad development environment ... need to install Visual Studio 2003 to make it work ..."

Carbide.c++, which is based on Eclipse and CDT, is the only IDE Nokia is supporting from now on and it's great and stable. The author admits "My first installation a few years ago" ... nuff zed.

and there's more ... but I don't have that much time Motti

Re:Misconceptions in TFA

[w3woody]

With respect to "crippled C++ support" and a bad development environment--SymbianOS 9 and Carbide.c++ are relatively new. For a commercial software developer SymbianOS 9's support for exceptions is worthless if you still need to target earlier versions of SymbianOS, and converting a build process from Metrowerks Codewarrior or Visual C++ is a royal pain in the ass--which is why Symbian still sells Metrowerks Codewarrior, last I checked (about two months ago).

So while these are good trends, in a way it's too little, too late: until SymbianOS 9 captures enough of the market that we no longer have to deal with earlier versions of Symbian, we can't use exceptions. And converting our build process to Carbide, while it may make life easier, is one of those apparent high-cost zero-reward projects to management which is highly unlikely to be given a high priority by management.

But for new development--you're right. And if you're doing new development, it's far easier to get rolling on Microsoft Windows CE--whose market penetration is gaining on Symbian.

As someone who recently moved to a project which is targeting WinCE (PocketPC and SmartPhone) and Symbian (UIQ and S60), and which is considering targeting various Linux phones, I have to largely agree with the analysis in the original article about Symbian. What the author doesn't point out, however, is that there are similarly egregious design decisions in WinCE and Linux cell phones which make them also somewhat problematic platforms.

For WinCE:
Extremely heavy weight applications. If you decide to use .NET for development or you decide to use a framework such as MFC or even ATL, you can easily wind up with a 1 or 2 megabyte application footprint. For a small mobile device, this may not matter in five years--but right now, that's bloody huge. Dot NET seems to be the favored environment right now, but that requires shipping the .NET engine which takes a fairly large footprint.

Windows API doesn't map well to SmartPhone use. Generally most applications are, from a WinCE perspective, "full screen" applications. The WinCE layer appears to have full support for creating framed dialogs and windows--yet on a device that is 220x180 pixels in size, do you really need or want a 32-pixel title bar?

Where this makes things really awkward is when dealing with switching applications using the 'back key' or when relaunching the currently running instance of your application. See, while the user sees just his little LCD display, what is going on under the hood is a multitude of windows layered in Z-order with the current display being the topmost window. While this doesn't generally matter, it is possible (and is a common bug, fixed by using something like .NET or MFC if you're willing to ship a fat binary) to create a circumstance where the current focus belongs to a different window than the frontmost one--leaving the user with the impression that the phone has locked up. It hasn't; you just can't see the window where your keystrokes are going.

WinCE Smartphone "smart keys" menu ill-designed. Like all other pieces of Windows, the smart keys bar at the bottom of the screen live in its own, separate window. It's not handled like the Apple menu bar at the top of the screen on System 7: a drawing region that is not a window, which obeys its own rules. Instead, the smart keys bar is its own window, with its own z-ordering, created by a new shell call which, if not managed correctly, breaks the illusion of simply being a label associated with the buttons.

Inconsistency in UI decisions between PocketPC and SmartPhone. One of my personal gripes: the UI on SmartPhone for most applications include a "cancel" button as one of the choices for dismissing dialogs--but on PocketPC, generally you only have an "OK", implied when you close the dialog by clicking in the upper-right 'close' box. It's a minor thing, but if you're writing code that targets both platforms,