What can happen though is that each of your objects in the nib file have to do something in awakeFromNib and the order in which awakeFromNib gets called isn't determined. So in that case you could use the perform with selector method. Although I would suggest you to load the nib yourself in that case and orchestrate your further initialisation using a normal Controller Object.
Another good reason for using the performSelector:withObject:afterDelay: is keeping your app responsive. If you have some time consuming task that can be split in loops or something then interrupting yourself with a performSelector: and a minimal delay will keep the beach ball from happening and give the user a chance to interact. However - with all the multi-cores out there you would probably be better of with doing the calculations in a separate thread.
by Dominik Wagner — Sep 18
What can happen though is that each of your objects in the nib file have to do something in awakeFromNib and the order in which awakeFromNib gets called isn't determined. So in that case you could use the perform with selector method. Although I would suggest you to load the nib yourself in that case and orchestrate your further initialisation using a normal Controller Object.
Another good reason for using the performSelector:withObject:afterDelay: is keeping your app responsive. If you have some time consuming task that can be split in loops or something then interrupting yourself with a performSelector: and a minimal delay will keep the beach ball from happening and give the user a chance to interact. However - with all the multi-cores out there you would probably be better of with doing the calculations in a separate thread.