Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Common iOS Gotchas

Often enough, we find ourselves battling a problem that can sometimes seem to last forever and when we finally find the solution, it seems so trivial. Fear no more. This article is going to explain some of the common gotchas that arise during our iOS development sessions.

Localizable Strings

Adding localization to your application has been made quite easy with the use of the Localizable.strings file; however, sometimes it seems like NSLocalizedString() is always returning English. When NSLocalizedString() performs a look-up, if it cannot find the corresponding key, it returns the key as the value. If your application is using the English text as the key, and your Localizable.strings files are not correctly setup, you may think your application is always defaulting to your English localizations. What may be happening here, is that your target’s Build Phases may not have your Localizable.strings file listed under “Copy Bundle Resources.” Without this, the localizations will not be compiled and your localization look-ups will fail.


Memory management may not be the first task that comes to mind when implementing an NSTimer, but this gotcha could have you debugging for quite a while.

When an NSTimer is created, it will retain its target and release it when the timer is invalidated. This means that timers need to be managed manually when attempting to release its target. The naive approach would be to invalidate the timer within the deallocation of the controller it is created from. However, if the controller was the target, the timer will have retained it and thus the dealloc method will not be invoked until the timer has finished. At this point, an exception may be thrown if the timer’s selector accesses member variables of the controller. To avoid this, you must explicitly invalidate the timer before you release its target.


Although the NSNotificationCenter will not retain its observers like NSTimers retain their targets, notifications can cause problems if you do not properly manage the adding and removing of observers.

If you add yourself as an observer for a notification, you are expected to also remove yourself at a later time. Some notifications are added upon viewDidLoad and removed within the dealloc. If, however, you add a notification upon an event (e.g. buttonPress) you are expected to remove the observer within the notification callback. Failing to remove this observer can cause the NSNotificationCenter to duplicate the object as an observer (e.g. for each press of the button) and the object will receive the callback for each instance it was registered as an observer.


NIBs allow for an easy, visual way to layout the UI for your views. Linking UI elements in the interface builder to the code within the header file appears seamless but can cause vague errors when refactoring.

When an object is linked between the NIB and the header file it is declared as an IBOutlet. This connection is usually handled properly (i.e. removed) if the object is removed from the header file; however, when an object is refactored (e.g. renamed) then the NIB file will still assume the link to the old object. If the link is not manually removed, then upon creation of this view, when the NIB is invoked, an error will be thrown. It is in best practice to always verify the links are correct when using NIBs.

  1. […] Pivotal Labs’s Common iOS Gotchas […]