It’s not a good strategy to turn your AppDelegate into a “big ball of mud” that contains a million methods and properties (although it might be tempting).
A better and more object oriented approach to section off bits of functionality into well-designed objects — for example you might have a class DatabaseManager which handles all database interactions. You might then have bits of your app which need the DatabaseManager ask the app delegate instance for a reference to a DatabaseManager.
Alternatively, you can pass around a reference to the DatabaseManager to the parts of the app that need it. This last approach does however cause more ‘interface pollution’, where you have to modify interfaces in lots of places in order to pass in the DatabaseManager.
And yet another alternative would be to effectively make your DatabaseManager itself be a ‘singleton’ — whereby an instance of it is accessed via a class method on the class. Singletons that work in this way are often frowned upon, and usually for good reasons (makes testing harder, that sort of thing). I tend to avoid having objects have their ‘singleton’ nature baked right into the object — I prefer, if I need that sort of thing, to have a known point of access (a kind of ‘factory’ if you like) where you can go to obtain a shared instance.