Сервис лучше закрывать протоколом - это позволит подменить его реализацию, если потребуется (мок-сервис сделать, например). Синглтонами лучше не увлекаться: если использовать менеджер зависимостей это не понадобится.
Сервис может содержать следующие зависимости:
- Transport (RequestManager) - сущность, которая выполняет запросы к API. Может работать с Alamofire, например.
- Parser - сущность, которая парсит JSON в PONSO/NSManagedObject
- Cache - кэширование данных в БД, напимер в CoreData.

Получается, что сервис - это логика работы совокупности транспорта, парсера и кэша. Если объекты получаемые с API однообразны, можно сделать generic сервис для получения различных сущностей.

Вы говорите об архитектурных подходах. Принципы DI применимы везде и в разработке под iOS тоже. Однако, необходимо понимать, какие проблемы Вы хотите решить, используя тот или иной архитектурный паттерн.
Если вы только начинаете изучать разработку iOS, обратите внимание на MVC в представлении apple (DI там особо не пригодится). Столкнувшись с определенными проблемами MVC (толстый контроллер), можно посмотреть на MVP или MVVM.
Вообще не стоит обращать внимание на то что "модно" - следует по возможности следовать основным концепциям хорошего кода (SOLID, KISS ...).
Для начала я бы не уделял особого внимания архитектурам, а сосредоточился на основных вещах: использование storyboard и autolayout, UIKit, CoreData

Что касается библиотек - популярные либы для работы с сетью AFNetworking (Alamofire для swift). Остальное по вкусу, можно посмотреть лучшие либы например здесь.