How does iPhone development compare to Symbian development? -

Having spent many years in developing Symbian C ++, I would like to know how iPhone development compares Symbian development .

I am interested in answering the people who have spent some time on both platforms.

To illustrate: Example: Compare how to:

• Symbian C ++ vs. Visual C - formerly the ICHHO
• Symbian Library vs. iPhone Library
• Emulator - How close is the emulator for actual devices - Symbian emulator is actually a simulator because it has been modified to run on the Symbian Library for Win32. Like a process is a thread on the Symbian emulator and there is no symbian process. The emulator is a separate build target. IDE - How do they compare (eg Eclipse or Covverrier vs. relevant iPhone IDE)
• Documentation - How do documents compare - Symbian documentation much to be desired. Community Support
• Fission - There are many Symbian OS versions and phones that can potentially target - this can be a real development and maintenance nightmare, apart from the different tastes of UI.
• App deployment - e.g. Signing Symbian / Private APIs / Operators vs. What? On iPhone

I have never developed an iPhone, but I want to point out See some incidents in the Symbian world that are related to some of your points:

Symbian C ++ vs. Visual C - formerly Yuk IMHO.

This is definitely not for everyone's taste! For application development, Symbian C ++ is going to be less and less relevant, because (which is generally considered to be very user-friendly libraries) will be used for the next generation of application frameworks / UI layers . The lower layer of OS will continue to use the Symbian quote of C ++, but they are being added - therefore, app developers are unlikely to call the original Platform API directly. Emulator - how far is the real emulator for the device - Symbian emulator is actually a simulator because it has been modified to run on the Symbian Library on Win32. Like a process is a thread on the Symbian emulator and there is no symbian process. The emulator is a separate build target.

The description of the emulator (single host process, separate build target) is correct. For this reason, the emulator essentially has a port of OS for a completely different platform (in this case x86), so the phone does not exactly model at all. Happily, it has been phased and replaced with simulator, such as already included in the iPhone and Android SDK (In fact, the simulator is based on the same technology - used by Android) because the simulator translates ARM instructions that understand the desktop machine, the same binary can be deployed for both simulators and on the device itself.

The simulator includes a "board model" that includes several virtual accessories, each of which is part of the host machine - so for example the simulator audio device can be connected to the desktop sound card. Because the model of this board can be modified, the simulator environment can be made in accordance with a very close model of a particular device, so the device manufacturers have hoped to see a simulator ship in their SDK, which is related to the physical device Is near

IDE - How do they compare (eg Eclipse or Codwadi vs relevant iPhone IDE)

CodeVariore is a very old and current IDE. The carbide (which is based on Eclipse) is better, and provides sufficient debugging support on the device (although not as crafty on the excompose / iPhone solution) all the Qt SDKs included in the IDE are probably the best, and the references to the applicability XCode has been compared to.

Fission - There are many Symbian OS versions and phones that can potentially target - this can be a real development and maintenance nightmare, apart from the different tastes of UI.

Of course it is true in the past. Hopefully it will be better in the future, once there were multiple UIs (S60, S80 and UIQ), now only one (currently S60-based; almost to change with a QT-based UI)