Continuing the miniseries, here are some more good ideas I’ve learned while developing for the Apple platforms:

(1) Beware NSTimer
Using “fire and forget” timers seems like a great idea, but it may not be ideal in a world where states transition constantly and unexpectedly. Example: something special in your game triggers a timer that causes a point pop-up to display later, but before that timer fires the level ends. Best case is you get an ugly point display on the level-over screen; worst case is the game crashes. Either use something that gives you a finer level of control or make sure you’re managing the timers appropriately.

(2) Understand shouldAutorotateToInterfaceOrientation
This method is not the appropriate place to DO anything, mostly because when it gets called is unpredictable and varies between SDKs. It’s a query only. If you want to actually do something in response to an orientation change, either listen for the appropriate message or add the appropriate delegate to your view. I forget the names of both of those right now, but you’re industrious people who clearly have the internet available.

(3) Don’t Use Apple’s Private APIs
This is expressly forbidden by Apple. There was a time when you could get away with it, and that time is over. It’s tempting, since the private APIs have some handy functionality like turning off rubber-banding on a web view or showing a text field in an alert, but you’ll get failed during review. Trust me.

(4) The iPad is Different
That seems obvious, but it’s different for a more important reason than just screen size - the Human Interface Guidelines are different. The most notable change is that users expect the iPad to “just work” regardless of what orientation they’re in - there’s no real “up” for an iPad. And when I say the users expect this, I mean Apple’s reviewers expect this too - I’ve read about plenty of people being failed for not supporting rotation properly. There are of course special cases like games where you can support only landscape (both versions of landscape, mind you), and you should be aware of those while developing. In short: read the HIG document.

(5) Regarding Facebook, Ads and Such
There are a lot of libraries that add a lot of little touches. The Facebook API is not terribly hard to implement and can get your game a little more exposure (though how valuable that exposure is is pretty open to interpretation). Ad services like AdMob can help monetize a free application. Flurry Analytics can give you valuable information about your players.

That’s all for now. I’m constantly putting together more ideas, and so we’ll probably see the series return in the future, but it won’t be a regular thing.

The Android is more fun to develop for anyhow.