A lot has been written on the difficulty and complexity of development for the Symbian platform. It even prompted Russell Beattie to declare his belief and support in Linux as the future mobile development platform even though he had been a religious supporter of Symbian in the past (The Future of Mobility is Linux). The main reason for his abandoning of Symbian is the high level of complexity to develop even the simplest of programs, keeping the number of available applications rather limited (compared to other environments such as Palm,..). In this post I attempt to describe the (justified) reasons behind this complexity.

First of all, I can only confirm that developing for Symbian is difficult and laborious. Although having done only limited Symbian programming up to now, it has enabled me to experience the underlying complexity. Functionality or features which at first sight may only need a couple of lines of code ( as it would be in other platforms) invariably turn out to involve lots of classes, functions, parameters,… to make it work. And what seems to be a very small application eventually turns out to be a huge program with 30 files, 50 classess and 200 member functions.

A few notorious examples of tedious Symbian programming:
- persistent data storage (streaming program settings to a file)
- application architecture (set of UI classes/functions)
- handling key events
- active objects
- memory and exception management (NewLC…)
-…

Of course there is also the inherent complex nature of C++ which is a fairly low level, object oriented programming language.The fact that Symbian is based on a dialect version of the standardised C++ only adds to the complexity.

But why should Symbian be so difficult? Surely it was not the original goal of the people behind the development of the operating system.

I have written a lot about the many constraints mobile devices have to cope with: battery power, amount of memory, processor speed,… and the impact this has on the performance of these devices. It’s very tempting to add losts of functionality and high specifications to a device, only leading to bad, sluggish, unreliable performance. (The recently launched Nokia 770 Internet tablet is a notorious example of this). It has prompted me to describe this phenomenon as the mobility paradigm: there is a trade-off to be made between functionality and performance as the mobility constraints do not allow to have both at the same time, at least compared to desktop environments.

Symbian does not escape from the mobility paradigm. However, what they have done is develop a mobile operating system from scratch while all along keeping the mobility paradigm in the back of their minds . All design decisions were made to maximise efficiency and performance under the constraints of low speed, memory, power,… The choice of C++, the use of a specially designed memory management system to minimise memory leakage, the proprietary exception management, non-preemptive cooperative multitasking based on active objects, … all reflect this same attitude. It allows low level programming in order to get the highhest efficiency out of the limited hardware capabilities.

A lot of the aspects mentioned here are also described in David Wood’s “Symbian for software leaders” in which he tells the story of the creation of Symbian.

Unfortunately the price to be paid for all this is a rather laborious programming and development experience putting a big burden on developers. There is no easy way out of this. Packaging some of the low level features into higher level, encapsulated functionality would inevitably lead to a loss of efficiency and hence performance (I do expect however that some of the most tedious aspects of Symbian will disappear as the growing performance of mobile hardware allows to be less religious about efficiency, one example being the abandoning of the proprietary exception handling in Symbian 9.1).

Making matters worse are the current tools and documentation which are far from optimal. Documentation has to be collected from various sources among which the forums play a very important role (The official Symbian forum, Forum Nokia, the Newlc forum,…) and without which many developers would be unable to do any serious Symbian development. I also started collecting Symbian hints & tips.Development environments are offered by CodeWarrior, Borland and Microsoft Visual Studio but none of them have reached a high standard.

One possible solution to alleviate the development complexity could consist of development environments with advanced wizards, help, documentation, examples,… to assist in dealing with the complexity mentioned above.

Concluding, the solution certainly is not - as Russel Beattie has proposed - to abandon Symbian in favour of Mobile Linux. Apart from the fact that Mobile Linux is unlikely to be a very simple environment (and it remains to be seen how quickly a high quality development environment and support system can be made available), it suffers from the same issue as Windows Mobile: it is a derivative of an OS originally designed for the desktop (and server) environment, inevitably leading to a sub-optimal mobile OS. And it is here that the real power of Symbian kicks in: it still is and will remain for a long time the only mobile operating system designed from scratch for the mobile environment, without any legacy to fixed/desktop environments.

On the other hand, Symbian development has to be made easier by the availability of high performance development and documentation tools.In this respect the ongoing efforts of Nokia to develop the Carbide series of tools , including visual wizards, cannot be underestimated : it is the key for the long term success of Symbian. The aim should be to have tools and support with a quality comparable to the quality of the Microsoft Visual Studio tool chain for fixed and mobile Windows environments.

And finally I would like to see more open source projects for Symbian - they currently can be counted on one hand! It is vital for the Symbian ecosystem to share and exchange source code to accelerate the learning curve of new developers. Fortunately there are initiatives like the Symbian Codex established by Simon Judge to make the limited source code easily accessible.

So indeed, Symbian is unique and is there to stay. But Symbian should learn from the other environments: from Windows to make available top class documentation, tools and support and from Linux to stimulate open source and community spirit. If Symbian succeeds in doing this, I cannot possibly see who could challenge it in the near and even mid-term future.