I am currently working under the assumption that -performSelector:withObject:afterDelay:
does not utilize threading, but schedules an event to fire at a later d
performSelector:withObject:afterDelay:
schedules a timer on the same thread to call the selector after the passed delay. If you sign up for the default run mode (i.e. don't use performSelector:withObject:afterDelay:inModes:
), I believe it is guaranteed to wait until the next pass through the run loop, so everything on the stack will complete first.
Even if you call with a delay of 0, it will wait until the next loop, and behave as you want here. For more info refer to the docs.