How is iPhone development compared to Symbian?

After spending several years working on developing Symbian C ++, I would like to know how iPhone development compares with Symbian development.

I’m interested in the answers of people who have been working on both platforms for some time.

To clarify: Examples: How to make the following comparison:

  • Symbian C ++ vs Objective C - the first is Yuck IMHO.
  • Symbian Libraries and iPhone Libraries
  • emulator - how close the emulator is to the real device - the Symbian emulator is really a simulator, since its Symbian libraries are modified to work on Win32. For example. a process is a thread on a Symbian emulator, not a Symbian process. An emulator is a separate build target.
  • IDE - how they are compared (for example, eclipse or codewarrior versus the corresponding iPhone IDE).
  • documentation - how documentation is compared - Symbian documentation is poor.
  • community support
  • fragmentation. There are many versions and Symbian OS phones that could be a potential target - this could be a real nightmare for development and maintenance. Plus various flavors of the user interface.
  • application deployment - for example. Symbian signed / private APIs / operators versus what? on iPhone
+6
iphone symbian
source share
1 answer

I have never been involved in iPhone development, but I would like to mention several events in the Symbian world that concern some of your questions:

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

This, of course, is not for every taste! For application development, Symbian C ++ will become less relevant, since Qt (which is usually considered a very convenient set of libraries) will be used for the next generation of application framework / UI layers. The lower levels of the OS will continue to use Symbian dialogs in C ++, but Qt libraries for functions such as multimedia, location and messaging have been added - so application developers are unlikely to have to directly access the platform APIs.

emulator - how close is the emulator to the real device - Symbian emulator is really a simulator since it has updated Symbian libraries to run Win32. For example. a process is a thread to a Symbian emulator, not a Symbian process. The emulator is a separate build goal.

Your description of the emulator (a separate host process, a separate build target) is correct. Because of this, the emulator is essentially an OS port on a completely different platform (in this case x86), so it does not simulate the phone at all. Fortunately, it gradually stops and is replaced by a simulator similar to those already included in the iPhone and Android SDKs. (In fact, the simulator is based on the same technology - QEMU - is used by Android) Since the simulator translates ARM instructions into understandable ones on the desktop computer, the same binaries can be deployed both on the simulator and on the device itself.

The simulator includes a “board model” consisting of several virtual peripheral devices, each of which displays part of the host machine, so that, for example, the simulator’s audio device can connect to the desktop sound card. Since this board model can be changed, the simulator environment can be adapted for a very accurate model of a specific device, so expect to see device manufacturers send a simulator to their SDK, which is very similar to the corresponding physical device.

IDE - how they are compared (for example, an eclipse or a code word against the corresponding iPhone IDE)

CodeWarrior is a pretty old and pretty creaky IDE. Carbide (which is based on Eclipse) is better, and offers reasonably mature debugging support on the device (although not so smoothly in 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 and phones that can be a potential target - this can be a real development and maintenance of a nightmare. Plus various flavors of the user interface.

Definitely true in the past. I hope everything will be better in the future. Where there used to be several user interfaces (S60, S80 and UIQ), now there is only one (currently based on S60, which should be replaced with a Qt-based user interface).

+6
source share

All Articles