Vous faites probablement allusion au fait que de nombreux développeurs d'applications vont finir par charger la classe app delegate avec beaucoup de choses de différentes sortes et gonfler cette classe. Le délégué d'app existe comme moyen pour le système iOS et l'objet d'application de communiquer avec votre app, le gonfler peut conduire à un code illisible et difficile à maintenir.
Une bonne façon d'éviter le gonflement est de créer de nouvelles classes. Par exemple, une app que je connais fait beaucoup de travail avec les notifications push et locales. Elle a donc une classe distincte pour gérer cela et le délégué d'app appelle les méthodes de cette classe.
Ma règle personnelle est que si une méthode de délégué d'app peut être gardée courte (peut-être moins de 50-100 lignes ou plus ?), alors gérez le travail dans cette méthode. Sinon, la méthode doit appeler d'autres méthodes ou utiliser d'autres classes pour gérer le travail. En particulier dans le cas du délégué d'application, vous voulez mettre l'accent sur d'autres classes plutôt que sur d'autres méthodes dans le même objet de délégué d'application. Juste créer des méthodes privées dans le délégué d'app est une autre façon de le gonfler.
Souvent, le plus grand délinquant est la méthode application:didFinishLaunching:withOptions : dans le délégué d'app. Nous l'utilisons tous pour configurer l'application et j'ai vu cette méthode devenir assez longue dans certains projets.
En général, le problème est qu'il s'agit de configurer divers objets de modèle ou objets du système iOS (localisation, suivi de mouvement, données de base, etc) qui seront utilisés dans l'application. La façon de gérer cela est de rendre la méthode init de votre objet modèle capable de le configurer et de l'appeler depuis votre méthode didFinishLaunching. Vous pouvez créer des classes "gestionnaire de modèle" pour gérer la mise en place de modèles d'application complexes. J'ai vu cela utilisé à bon escient.