Why I don't like Symbian
Sat May 05, 2007 · 1016 words

Just a few points why I think Symbian in general, and S60 in particular suck really bad. And I'm not alone in this:

Windows-only

I wonder how well the web would have taken off if the servers and development tools for making webapps and homepages would have been Windows-only. Some wonderful people have made an effort to get a Symbian toolchain running on *NIXes but they're all hopelessly outdated since there's no support from Nokia. Emulators only run in Windows. Nokia (the biggest Symbian licensee) doesn't seem to care. I'm not saying this just because I'm a Mac user - who the heck builds a development platform and doesn't support the OS's developers like the most (ie UNIX)?

Recently there has been some developments in the Open Source realm on Nokia's part but but the platform and toolset itself is still completely Windows-centric.

Lackluster toolset

For a long time there weren't any free IDE's available from Symbian or Nokia. If you wanted to develop for Symbian, you had to start off by paying ~$300 for a copy of CodeWarrior. This is almost as bad as forcing everyone interested in image processing to buy a copy of Photoshop 3 for the price of the latest version. Then came Carbide Express.c++ (based on Eclipse), which is still (currently v1.2) extremely crippled compared to the commercial ones. No UI design tools, no on-device debugging, no crash debugging, no optimization tools. What kind of a company sets off to establish an “industry leading” platform and doesn't start with a free (never mind cross-platform) set of development tools? This is all especially lame considering that the S60 SDK is built around PERL, Python, Java, GCC and Eclipse - all of which are (by now) Open Source. I haven't tried this myself, but from what I've heard from other devs, Microsoft has the upper hand in this with Windows Mobile.

Symbian C++

Gawd… where do I begin…. Apparently Symbian C++ evolved at a time when the C++ standard was undergoing heavy updating. But instead of following the emerging standard, they took their own route. For starters, they have 4 types of strings (TDesC, TDes, HBuf, HBufC), 3 types of constructors (ConstructL, NewL, NewLC), it's own threads (Active Objects), non-standard exceptions and a totally convoluted naming convention.

* it's an appointment in a calendar.

Platform incompatibility (UIQ vs S60, 80, 90 etc)

Generally not backwards-compatible (source nor binary). Emulator can't run native binaries (imagine having to build separate versions of Windows programs for Virtual PC!). This is one of my biggest gripes with Symbian and S60 - you build and test something on the emulator but you can be pretty sure it won't run on the actual device. This is completely unacceptable. OK, you have a different version of the OS for each hardware platform, but all of this should be transparent to the application.

Extremely slow emulation

Sometimes emulating supposedly one of the most efficient OS's running on a 220 Mhz ARM processor w/ 10 MB RAM (a Nokia 6630) on a 2,4 Ghz Pentium w/ 512 MB RAM running Windows XP feels like you're doing the exact opposite. I don't even want to think about running this stuff through an x86 emulator (althought I think I've tried it a while back).

The whole UID business

Why on earth do we need this? And why do they have to be cryptic hex strings (why not com.me.myapp)? Shouldn't the OS handle the identification of programs? Why would anyone want to leave this task to the developer? This leads us to our next point…

Signing

So you got over all the hurdles and your app actually runs on a phone (congrats!). How do you distribute it? Put it on your website for download? Maybe get a deal with an operator to carry it? Sure, right after you get it signed by Symbian. Simply stupid. At the minimum, this will cost you $350 + some silly testing costs that aren't even listed (my guess is they're outrageous). The operators claim this keeps the mobile network clean of malware, but to me it seems more like a quick way to milk the developers. If this doesn't kill innovation, then I don't know what does.

Pasted Graphic 1

… or just use one of the alternatives - Java, Python or Flash Lite.


back · essays · credits ·