Game Development Reference
From time to time you may encounter nasty cases where a game runs just fine on the
iOS Simulator but crashes on the device or the game slows down for no apparent reas-
on. There may also be graphical glitches that appear only on the iOS Simulator or only
on the device. If in doubt, and before delving into a prolonged quest to figure out
what's wrong, always try running your game on the device if you're having trouble on
the iOS Simulator, or vice versa. Sometimes, the problem may just go away, but if not,
you may get a hint about what's going on.
Don't bother figuring out issues that only occur on the Simulator. Likewise, don't ig-
nore any issues that only occur on the device but work fine on the Simulator.
About Performance and Logging
By default, an Xcode project will use the Debug build configuration with code optimiz-
ations turned off for debugging purposes, and logging turned on for the same reason.
One NSLog or CCLOG in the wrong place can spam the Debugger Console with
logging messages, causing slowdowns and lag. Logging is very slow, and a continuous
stream of log messages printed to the Debugger Console can drag your game's per-
formance down to a crawl. If you suspect your game's performance to be particularly
slow in Debug builds, always check the Debugger Console for excessive logging activ-
ities. In Xcode, click Run
Console to show the Debugger Console window.
The exclusion of logging and typically better code optimization settings are the main
reason you should only use Release builds to test your game's performance. You can
temporarily set your project to use the Release build configuration by selecting Product
Manage Schemes. . . from the Xcode menu. Then select your app's target and edit
it. Select the Run configuration on the left, as in Figure 2-18 . Then just change the
Build Configuration to Release.