Do multiple 'helper' classes conflict with the accepted Apple design scheme?

Do multiple 'helper' classes conflict with the accepted Apple design scheme?

I have a social location based application and I'm in a bit of design
conflict that I can't seem to solve or find good information on.
Realizing that I have multiple controllers that will similarly access the
user's location and load an array of places to be displayed in a table
view, I've made a class that has class methods to provide the users
location (coordinates and/or reverse-geocoded address), and populate a
variably sized NSArray of locations, and other methods that different
controllers will use to form their data. Call it SpotsManager.
Anticipating future complexity, I have separated SpotManagers duties into
2 separate classes, a SpotLocationManager for wrapping a CLLocationManager
and a SpotNetworkManager for wrapping AFNetworking.
Do all of these managers give off code smell? It seems excessive,
especially compared to most of Apple's sample apps but at the same time,
it also seems like beneficially strict organization.
To contrast my previous approach, I've branched and made a SpotsList class
that knows how to populate its instances with locations. But I question
extending this class without creating some God-class. (And [SpotList
currentCoordinate] doesn't sound right.)
I realize high level design questions provide an opportunity for opinions,
so I am specifically asking for an answers that will provide some
objectivity.