Monthly Archives: May 2011


This article is from , useful for debugging the annoying EXC_BAD_ACCESS exception.

You have to accept the fact that sooner or later you will need to debug an EXC_BAD_ACCESS problem and most probably won’t be easy to.

This article however is about how to make the process easier, in some cases easy as a piece of cake.

What does EXC_BAD_ACCESS mean?

EXC_BAD_ACCESS means that message was sent to a point in the memory where there’s no instance of a class to execute it. Thus “bad access”

When EXC_BAD_ACCESS happen?

You will get EXC_BAD_ACCESS in 3 cases:

  1. An object is not initialized
  2. An object is already released
  3. Something else that is not very likely to happen

That’s already a good starting point. Start using the debugger, if you recently added a new object to the class you’re working on, put a breakpoint at the line before the freshly added object is used for the first time and check the values in the debugger.

What’s happening most though is that you will be sending a message to an overreleased object – i.e. object that is gone from the call stack. In this cases everything (and indeed everything) you will get in the console will be just :


This is because the object is gone, there is no information what class was it, or what source file or anything else. That’s really tough to debug with NSLog … NSLog is helpful, but you need to put 1,000 NSLogs around to fetch where is the problem.

Enabling NSZombies

The solution to overreleased objects are the zombies. When this feature is enabled, a dummy object (a zombie) is kept on the place of every released object, thus allowing to debug objects which were released already. Very easy to enable:

  1. Double click your executable in the “Executables” in XCode
  2. Open “Arguments” tab
  3. In “Variables to be set in the environment” (that’s the list at the bottom, be careful which one you edit) click the “+” button and for name of the variable enter “NSZombieEnabled” and for value “YES”


Now instead of wondering what’s going on and which exact object produced the problem, you’ll see exactly which class is the trouble maker, and you’ll debug it quite fast.

Beware the zombies though

Just a reminder not to leave the zombies enabled, when you submit your app to the App store. Also, it’s a good practice to disable them if you don’t really need them.

All the sizes of iOS app icons

  1. 57 px, iPhone – good ol’ classic.
  2. 72 px, iPad
  3. 114 px, iPhone 4 – make sure your icon shines on the Retina Display.
  4. 512 px, iTunes – Used in iTunes and in the App Store, where it’s sized down to 175 px. Sadly, you can’t provide the 175 px version directly.
  5. 29 px, iPhone Settings/Spotlight, iPad Settings – used in these table views. Minor, but still important!
  6. 48 px, iPad Spotlight – yup, the iPad uses a different size for Spotlight and Settings. This size is controversial! Apple’s docs actually say the icon is 50 px, but then there’s this note: The final visual size of this icon is 48 x 48 pixels. iPhone OS trims 1 pixel from each side of your artwork and adds a drop shadow. Be sure to take this into account as you design your icon. How weird!
  7. 58 px, iPhone 4 Settings/Spotlight – that’s right, you have to make both 57 and 58 px versions of your icon – d’oh! Good luck aligning this if there’s a line running down the middle of the icon.
  8. 64 px document icon – who knew: iOS apps can provide document icons. It’s unclear how these will be used – they don’t do much currently – but it’s not a bad idea to start planning now.
  9. 320 px document icon – why not 256, darn it? :)
  10. Let’s say Apple comes out with a high-ppi iPad. That will mean at least 2 new sizes – maybe 144 px and 96 px.

From:  All the sizes of iOS app icons (Neven Mrgan’s Tumbl)

iPageRank Released

iPageRank is a handy tool for checking website Google PageRank on your iPhone/iPod Touch, anytime and anywhere.

iPageRank home page:

iPageRank is available on iTunes App Store for free: