 <p>I've seen you already accepted an answer but there are two things here that I wanted to rectify:</p> <ol> <li>It's <em>not needed</em> to retain a scheduled timer but it doesn't do any harm (as long as you release it when it's no longer needed). The "problematic" part of a timer/target relationship is that...</li> <li><strong>a timer retains its target</strong>. And you've decided to set that target to <code>self</code>.<br> That means — retained or not — the timer will keep your object alive, as long as the timer is valid.</li> </ol> <p>With that in mind, let's revisit your code from bottom to top:</p> <pre><code>- (void)dealloc { [timer_porthole invalidate]; // 1 [timer_porthole release]; timer_porthole = nil; // 2 [super dealloc]; } </code></pre> <p><strong>1</strong> is pointless:<br> If <code>timer_porthole</code> was still a valid timer (i.e. scheduled on a runloop) it would retain your object, so this method wouldn't be called in the first place...</p> <p><strong>2</strong> no point here, either:<br> This is <code>dealloc</code>! When <code>[super dealloc]</code> returns, the memory that your instance occupied on the heap will be freed. Sure you can nil out your part of the heap before it gets freed. But why bother?</p> <p>Then there is</p> <pre><code>-(void) kill_timers{ [timer_porthole invalidate]; timer_porthole=nil; // 3 } </code></pre> <p><strong>3</strong> given your initializer (and as others have pointed out) you are leaking your timer here; there should be a <code>[timer_porthole release]</code> before this line.</p> <hr> <p>PS:</p> <p>If you think it all over, you'll see that retaining the timer (at least temporarily) creates a <em>retain-cycle</em>. In this particular case that happens to be a non-issue which is resolved as soon as the timer is invalidated...</p>