Nstimer not invalidating
Run loops maintain strong references to their timers, so you don’t have to maintain your own strong reference to a timer after you have added it to a run loop.
To use a timer effectively, you should be aware of how run loops operate.
You could use notifications but that would not be the cleanest solution.
For some reasons you cannot or may not want to use view disappear events. Clearly it does not cover all edge cases and possible solutions to the problem.
If the firing time is delayed so far that it passes one or more of the scheduled firing times, the timer is fired only once for that time period; the timer is then rescheduled, after firing, for the next scheduled firing time in the future.).
This flexibility in when a timer fires improves the system's ability to optimize for increased power savings and responsiveness.
A repeating timer always schedules itself based on the scheduled firing time, as opposed to the actual firing time.
For example, if a timer is scheduled to fire at a particular time and every 5 seconds after that, the scheduled firing time will always fall on the original 5-second time intervals, even if the actual firing time gets delayed.
Due to hardware or software timer resolutions or other things happening on the system, that may not occur.
It’s not a big deal when you use a non-repeating timers as they get invalidated automatically after firing.
However, when you use a repeating timer and forget about retaining, this means trouble.
See Threading Programming Guide for more information. If a timer’s firing time occurs during a long run loop callout or while the run loop is in a mode that isn't monitoring the timer, the timer doesn't fire until the next time the run loop checks the timer.
Therefore, the actual time at which a timer fires can be significantly later. You specify whether a timer is repeating or nonrepeating at creation time.