Summa

For many Java/C# developers, developing for a mobile device is a new experience. Of course - we have the fringe Windows Mobile and J2ME developers, but the vast majority have used Java/C# for web and application development only. In order to develop for a mobile device, you need to be able to run the software on the device, but is this the lone choice? Apple and the XCode development environment provide the iPhone Simulator, an application to run and debug iPhone software without using an actual device. While this is a fantastic productivity enhancement (reduces the time necessary to deploy the code to the device), you need to be careful with this ability.

Gotcha #1: Performance

When working with simulators, you must pay special attention to the performance of the application. The performance of the simulator on your iMac or MacBook will outshine the iPhone or iPod touch physical hardware tremendously. You have a lot more memory and MIPS on those computers than you do on the handhelds. It is crucial to get your application on a device as soon as you can in your development process to start looking for performance bottlenecks and sluggishness. And when analyzing and figuring out performance issues on your device and/or simulator – instruments are your friend…but we will leave that for another post.

Gotcha #2: Memory behavior

When dealing with Objective C code, it is a virtual certainty that you will encounter memory issues. Either you will have improper memory release issues, where you attempt to access memory that has already been released or you will have issues where you are retaining too much memory, resulting in low memory situations. The simulator simply does not mimic the behavior of the devices in these situations perfectly. The simulator seems to be much more tolerant of accessing released memory than the device. This inconsistency of how memory issues reveal themselves in running the application on the simulator or the device is just a little disheartening. You need to run your application on the device as early as possible, and take it through various scenarios/tests to reveal memory issues as soon as you can. It is much better and easier to tackle memory issues early on and throughout the project than waiting till the end and just tackling the whole list of issues.

Gotcha #3: Limited Features

The simulator is great at doing touches and pinches and even shakes now in iPhone SDK 3.0. However, you can’t do location services, you can’t do magnetometer services, you can’t do accelerometer services and you can’t do mapping services. While there are plenty of applications out there that would not need to use any of these, most of those applications would be rather dull. The iPhone/iPod touch devices are full featured devices that not figuring out unique ways to leverage these capabilities would be a shame. Therefore, most developers and product managers would tend to invent features that will use these capabilities of the devices. Now – this poses a testing problem. You simply can’t test these features on the simulator to any extent and must test with the physical device from the very beginning.

Summary

Don’t get me wrong – I am not here to bash the simulator. The simulator is a fantastic tool that greatly improves development efficiency. However, you simply just can’t rely on the simulator to give you a perfect application for your mobile devices. The main lessons learned that we wish to impart on the reader is get a device, test with the device, from very early on and throughout the project. You will be very happy that you did and you will develop a higher quality application if you do. And isn’t that what we are all after?