How does iPhone development compare to Symbian development?

Question

Having spent several years doing Symbian C++ development, I'd like to know how iPhone development compares to Symbian development.

I am interested in answers from people who have spent some time working on both platforms.

To clarify: Examples: How do the following compare:

• Symbian C++ vs Objective C - the former is yuck IMHO.
• Symbian libraries vs iPhone libraries
• emulator - how close is the emulator to the real device - the Symbian emulator is really a simulator as it Symbian libraries modified to run on Win32. E.g. a process is a thread on the Symbian emulator and not a Symbian process. The emulator is a separate build target.
• IDEs - how do they compare (e.g. eclipse or codewarrior vs relevant iPhone IDE)
• documentation - how does the documentation compare - Symbian documentation leaves a lot to be desired.
• community support
• fragmentation - There are many Symbian OS versions and phones that can can potential target - this can be a real development and maintenance nightmare. Plus various flavours of UI.
• deploying apps - e.g. Symbian signed / private APIs / operators vs what? on iPhone

Answer 1

I have never done any iPhone development, but I'd like to point out a few developments in the Symbian world which relate to some of your points:

Symbian C++ vs Objective C - the former is yuck IMHO.

It's certainly not to everyone's taste! For application development, Symbian C++ is going to become less and less relevant, as Qt (which is generally regarded as a very user friendly set of libraries) will be used for the next generation of the application framework / UI layers. The lower layers of the OS will continue to use the Symbian dialect of C++, but Qt libraries for functionality such as multimedia, location and messaging are being added - so app developers are unlikely to have to directly call native platform APIs.

emulator - how close is the emulator to the real device - the Symbian emulator is really a simulator as it Symbian libraries modified to run on Win32. E.g. a process is a thread on the Symbian emulator and not a Symbian process. The emulator is a separate build target.

Your description of the emulator (single host process, separate build target) is correct. Because of this, the emulator is essentially a port of the OS to a completely different platform (in this case x86), so does not model a phone closely at all. Happily, it is being phased out and replaced with a simulator, like those already included in the iPhone and Android SDKs. (In fact, the simulator is based on the same technology - QEMU - used by Android) Because the simulator translates ARM instructions into those understood by the desktop machine, the same binaries can be deployed to both the simulator and onto the device itself.

The simulator includes a "board model" consisting of a number of virtual peripherals, each of which maps part of the host machine - so for example the simulator audio device may be hooked up to the desktop sound card. Because this board model can be modified, the simulator environment can be tailored to very closely model a particular device, so expect to see device manufacturers ship a simulator in their SDK which closely resembles the corresponding physical device.

IDEs - how do they compare (e.g. eclipse or codewarrior vs relevant iPhone IDE)

CodeWarrior is a pretty old and rather creaky IDE. Carbide (which is based on Eclipse) is better, and offers reasonably mature on-device debugging support (although not as slick at the XCode / iPhone solution). The IDE included in all Qt SDKs (Qt Creator) is probably the nicest, and has been compared to XCode in terms of usability.

fragmentation - There are many Symbian OS versions and phones that can can potential target - this can be a real development and maintenance nightmare. Plus various flavours of UI.

Definitely true in the past. Hopefully getting better in future. Where there were once multiple UIs (S60, S80 and UIQ), there is now just one (currently S60-based; about to be replaced with a Qt-based UI).