As we’re all aware, the iPhone represents an exciting innovation in the mobile space. Developers finally have a platform to distribute content that has a widespread audience of techies and casual users. One of the major draws to the platform is the perceived lack of device fragmentation that exists given that one is developing for a very small set of devices in the iPhone and iTouch.
While Apple has done a tremendous job in limiting the level of fragmentation, its inevitable that developers will run into issues as they create content. Keeping some of the suggestions we’ve provided in mind when designing and developing your application will help make your code more portable across the different platforms.
1. Device Simulator vs. Actual Hardware
Its incredibly difficult to create an accurate device simulator that runs on a developers machine, given that the underlying hardware and user input mechanisms are different from the get go. Apple has provided one of the best device simulators that we’ve seen for mobile devices. Given their focus on the generation of unique and compelling content, this shouldn’t come as much of a surprise.
The first thing I noticed was the accuracy and speed at which the emulator operates at. To given an example, the Apple emulator can be loaded in a matter of seconds while RIM’s BlackBerry emulators take quite some time to load and I’ve found the load time takes me out of the development “flow”. They’ve also made it very easy to run the emulators across the different released firmware versions (which is quite useful when you’re trying to isolate firmware specific bugs in your application).
When developing using the emulator versus the device, the following should be noted:
The simulator does not have an accelerometer, thus making it difficult to test any applications that require those functions
There are ways to simulate the accelerometer and tie it to the one located inside your MacBook
The simulator does not provide access to location but it does provide you with a default location thus allowing you to use the API
The performance on the hardware itself is notably slower than on the simulator. Graphically demanding applications should always be tested on the handset itself to ensure the performance is up to par
There are several video playback issues
The simulator does not appear to take into account the case sensitive filenames stored on your MacBook’s hard drive. For example, if you have a test.png in your application, [UIImage imageWithName:@”Test.png”] will work on the simulator but not on the device (notice the capital “T” in “Test.png”)
I had a custom button with an image:
UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];[button setImage:image forState:UIControlStateNormal];
I tried to dynamically position the button using some computations. If button.frame.origin.x was not a round number the margin of the button will show up fine on the simulator but is chopped of on the real device. The solution was to use the round() function when computing button.frame.origin.x, which makes sense but is something I assumed the platform would have done for me
2. Differences between firmware SDK versions
When you develop for a mobile device, the firmware version of the device is often a major factor. One could have different firmware versions for a single device as its deployed across multiple carriers as an example. There are also have some users who actively update their firmware to the latest and others who do not. As a result, one could end up with different builds for the same device for each targeted carrier, because they introduced the device at a different point in time with different firmware versions.
Luckily, with iPhone updating the device is extremely well thought out and easy process from the user’s point of view. A developer typically only has to worry about the current operating firmware and the previous version. While a developer compiles the application, its tied to the version of the SDK so a user with an older SDK will not be able to install it and will be prompted to update their firmware in order to do so.
There are still some issues that you might want to keep in mind:
If you are not building against the latest SDK, make sure that you are testing the application on devices with previous versions
There are bugs fixed/introduced in each new version. A few that I’ve run into include:− the list of supported fonts is different from version 2.0 and 2.1. I believe some fonts were taken out or the name was changed. My font selection dialog was crashing after updating to the new version.
There used to be a way to provide a transparent background for a UIWebView in firmware version 2.1…. unfortunately this appears to have been removed
See the links for additional changes: 2.0 to 2.1 2.1 to 2.2
3. Fragmentation between Apple devices
From a device fragmentation perspective, one should consider the three different versions of devices that Apple supports: iPhone 2G, iPhone 3G and iTouch.
When designing your application you have to carefully choose your feature set based on the targeted audience.
Some additions items you should take into consideration when developing your applications:
iPhone 2G vs iPhone 3G
Because of the network speed, iPhone 2G is not suitable for streaming applications
iPhone vs iPod Touch
There is no camera on the iPod Touch
There is no sound recording mechanism on the iPod Touch
Location information is limited when using the iPod Touch, and is only available when the device is connected to a WiFi network
The iPod Touch does support any phone functions
The 2nd generation of iPod Touch introduced a faster processor: 532MHz (up from 412MHz). This has an impact on applications which are dependent on the CPU speed (mostly games).
4. The Future
It will be interesting to see how Apple tackles the fragmentation problem as they release additional versions of their platforms. The rumored 3rd generation of the platform has quite a few enhancements that will allow for more interesting applications to be created, but may cause issues for existing verisons to run on the handsets. I believe Apple will control this by releasing new versions on a controlled basis and ensuring hardware changes are ramped up over time.
The challenge all developers will face is ensuring that there is both portable and future proof at the same time.
Check back soon for additional iPhone development tips and tricks!
