I’ve been mulling over a few relatively Good Ideas while doing iPhone dev. I have more than one post’s worth, so here’s, well, one post’s worth, with more to follow:

(1) Localize Late
Localization will inevitably involve interface changes to suit each language, and thus you’ll be left with multiple versions of the interface. If you then have to change something non-language specific like adding a new view, you have to change that in every unique interface, which is painful at best and problematic at worst. If possible, it’s best to save localization for the last step.

(2) Avoid UIImageView for Representing Sprites
It might be a knee-jerk reaction to make a sprite have an associated UIImageView for display and animation purposes, but this slow. Slow in a way you’re pretty likely to run into.

(3) Test Early and Often on a Device
The emulator is nice and convenient and terribly misleading. It basically has infinite speed and storage as far as an iPhone game is concerned, and thus if you’re having speed or memory issues on a real device, they might go unnoticed for too long. Testing on devices of different qualities is also recommended, as you’re a lot more likely to run out of memory or have severe performance issues on a 2nd gen iPhone than you are on a modern iTouch.

(4) Use Instruments but Don’t Trust It
Instruments is The Tool for iPhone profiling. Which is unfortunate since it will lie to you. Use it often to gather benchmarks and spot memory leaks, but don’t trust it to tell you the whole truth. Make sure you check the iPhone logs and output messages for memory warnings to supplement your benchmarks.

(5) Invoke memory warnings
There’s no better way to spot trouble areas than when a program runs out of memory. When a low memory warning triggers, the iPhone will dump a lot of its unused memory and try to keep going. If your program doesn’t crash in the near future (not necessarily immediately), you’re doing good. If your program does crash, it’s very possible you’ve got a memory management problem hidden somewhere that needs to be addressed. Common culprits are failing to retain an object that you access later. Keep in mind that, while the iPhone simulator does have a “simulator memory warning,” option, it doesn’t behave the same way as it does on the device, so things which quietly keep working on the simulator will go down in flames on the phone.

(6) Frequently Test Application Interrupts
When an app is interrupted because of an SMS message or just falling asleep, weird things can happen. Notably the sound system likes to become corrupted and needs a restart. It’s good to find these problems early, since they can be irritatingly persistent.

OK, that’s all we have time for. This won’t be a long-running series like my game polishing posts, but I have at least enough to fill another post in the near future.

Did you calibrate it to binary white?