Подход App Delegate прост в использовании, недостатком является то, что все должно пойти, получить делегат, а затем получить общий объект.
Синглтоны означают, что только классы, использующие синглтон, должны знать об этом, но может быть сложнее написать модульные тесты или выполнить очистку должным образом в ситуациях нехватки памяти. Также вы должны писать синглтон-классы более тщательно, чтобы они работали правильно (посмотрите на документы Apple по синглетонам).
Передача объекта может устареть, потому что иногда вы в конечном итоге получаете только ссылку на объект для передачи кому-то другому, поэтому я бы избегал такого подхода, если вы просто не переходите от одного родителя к нескольким непосредственным детям.
Между первыми двумя я немного склоняюсь к синглетам только из-за того, что граф зависимостей проще (как уже упоминалось, классы включают только одноэлементные заголовки, о которых они заботятся, а не целую кучу от делегата приложения). Если бы у вас их было несколько, то нужно было бы создать одноэлементные классы распределения, которые содержали бы отдельные экземпляры групп классов, просто чтобы облегчить делегат приложения и не создавать столько классов, которые были бы настоящими одиночками.
Мне нравится использовать делегат приложения для удержания корня вашего реального пользовательского интерфейса, такого как контроллер панели вкладок или контроллер основного представления. Это кажется более естественным, чем начинать его в другом месте.