Probablemente estés aludiendo al hecho de que muchos desarrolladores de aplicaciones acaban cargando la clase app delegate con un montón de cosas de diversa índole y hinchan esta clase. El delegado de la aplicación existe como forma de que el sistema iOS y el objeto de la aplicación se comuniquen con tu aplicación, hincharlo puede llevar a un código ilegible y difícil de mantener.
Una buena forma de evitar el hinchamiento es crear nuevas clases. Por ejemplo, una aplicación que conozco trabaja mucho con notificaciones push y locales. Así que tiene una clase separada para manejar eso y el delegado de la aplicación llama a los métodos de esa clase.
Mi regla personal es que si un método de delegado de la aplicación se puede mantener corto (¿tal vez menos de 50-100 líneas o así?) entonces maneja el trabajo en ese método. De lo contrario, el método necesita llamar a otros métodos o utilizar otras clases para manejar el trabajo. Especialmente en el caso del delegado de la aplicación, quieres enfatizar otras clases que sólo otros métodos en el mismo objeto delegado de la aplicación. Simplemente crear métodos privados en el delegado de la aplicación es otra forma de hincharlo.
A menudo el mayor infractor es el método application:didFinishLaunching:withOptions: en el delegado de la aplicación. Todos usamos esto para configurar la aplicación y he visto que se alarga bastante en algunos proyectos.
Por lo general, el problema es que está configurando varios objetos del modelo u objetos del sistema iOS (ubicación, seguimiento de movimiento, datos del núcleo, etc) que se utilizarán en la aplicación. La forma de manejar esto es hacer que tu método init del objeto modelo sea capaz de configurarlo y llamarlo desde tu método didFinishLaunching. Puedes hacer clases de «gestor de modelos» para manejar la configuración de modelos de aplicación complejos también. He visto que esto se utiliza con buenos resultados.