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.

• A language is a tool and a tool is supposed to be a productivity multiplier. It took me about a week to develop an J2ME RSS reader with OPML support, that also runs on S40 (and many other Java-enabled) devices while I've struggled for months to create a basic bitrate calculator using Cymbian C++. The first time I had to read a Symbian C++ program it felt like the eighties all over again. Quite frankly, I find it down right offensive, that at a time when some platforms enable us to build a full-featured dating service in less than 2 weeks, grown men must toil over getting their hello worlds to work.

• Crummy documentation. OK, so all the sales talk has won you over and you want to sacrifice your life to developing Symbian apps. Where do you start? You go to the Symbian site and all you find is a list of courses and some London guy's contact information. Mmkay… Then you fish around some more and finally get to the Getting Started PDF which is mostly just a collection links, but it also shows you how to build (and nothing more) a UIQ app using Carbide Express from a Hello World template (comes with the SDK). The last 4 pages is just s listing of books you should buy. The best Symbian help I've found so far is from this Italian guy's homepage. Googling for “symbian tutorial” will not have a single symbian.com or nokia.com page among the first 2 pages of results.

• Weird names galore! Uikon, Eikon, Avkon - no, these are not the moons of some Klingon planet. CAknCaleMonthlyStyleGrid - there's a nice name for a calender view. Can you guess what CAgnAppt does?* How the hell is one supposed to remember this crap?

* 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.

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