Si sta probabilmente alludendo al fatto che molti sviluppatori di app finiscono per caricare la classe del delegato dell'app con un sacco di cose di vario tipo e gonfiano questa classe. Il delegato dell'app esiste come modo per il sistema iOS e l'oggetto dell'applicazione di comunicare con la tua app, gonfiarlo può portare ad un codice illeggibile e difficile da mantenere.
Un buon modo per evitare il bloat è quello di creare nuove classi. Per esempio, un'app che conosco lavora molto con le notifiche push e locali. Quindi ha una classe separata per gestire questo e il delegato dell'app chiama i metodi di quella classe.
La mia regola personale è che se un metodo del delegato dell'app può essere mantenuto breve (forse sotto le 50-100 linee o giù di lì?) allora gestite il lavoro in quel metodo. Altrimenti, il metodo deve chiamare altri metodi o usare altre classi per gestire il lavoro. Specialmente nel caso dell'app delegate, volete enfatizzare altre classi piuttosto che altri metodi nello stesso oggetto app delegate. Creare semplicemente dei metodi privati nel delegato dell'app è un altro modo per gonfiarlo.
Spesso il più grande colpevole è il metodo application:didFinishLaunching:withOptions: nel delegato dell'app. Lo usiamo tutti per impostare l'applicazione e l'ho visto diventare piuttosto lungo in alcuni progetti.
Di solito il problema è che sta impostando vari oggetti modello o oggetti del sistema iOS (posizione, motion tracking, dati principali, ecc.) che saranno usati nell'app. Il modo per gestire questo è quello di rendere il metodo init del tuo oggetto modello in grado di impostarlo e chiamarlo dal tuo metodo didFinishLaunching. È possibile creare classi "model manager" per gestire anche l'impostazione di modelli di applicazioni complesse. L'ho visto usato con buoni risultati.