Mobile app development: Using delegates and blocks in VIPER

When to use delegates and protocols for data requesting, and when do blocks do the trick in VIPER-based mobile development? Let's examine both instances in this tutorial!

In mobile development powered by VIPER architecture, we have multiple ways to request and get data from external sources. In this article, I’d like to discuss two options:

  • delegates and protocols, perhaps the most natural one for VIPER,
  • and blocks, even more interesting and efficient.

Differently than in MVC, VIPER offers a different approach towards requesting and getting data. In my opinion, it's more secure. If you use the Generamba project to build your VIPER modules, you’re most probably used to delegates and protocols. It's common in VIPER, so let’s start with this one.

Delegates in VIPER

Requesting data in VIPER is very simple and secure. Let’s say we have View Controller in which we want to display some data right after it starts. VC informs Presenter that is ready to show data by the method viewIsReady(). So then we call Interactor by some function, e.g. refreshData(). Inteactor communicates with our Repository (it can be Core Data, JSON, XML - nevermind). Inside our Repository’s protocol, we create another one called dataDidChanged(). It looks like this:

protocol MyRepositoryDelegate: class {

    func dataDidChanged()


protocol MyRepository {



OK, that’s easy (peasy lemon squeezy :). When implementation of Repository fetches its data, it calls the dataDidChanged() function. And this one is implemented in Interactor. Interactor informs Protocol (also by a delegate) that it needs to refresh data in View Controller. So it’s done.

Blocks in VIPER - a remedy for corner cases

However, in some corner cases refreshing may be not as simple as in the example above. Sometimes one Presenter can request data from many repositories. And if in every repository we have the same dataDidChanged() method or if Interactor calls the same output method for every repository delegate, problems may arise.Flutter vs SwiftUI: A simple comparison

This is why we can use blocks.

Differently than delegates, blocks are focused on single tasks. You send a request and you wait till it’s done. So in our case, calling a request from Presenter would look like this:

func refreshData()  {
interactor.refreshData{ (receivedData) in

The Interactor method (same as in Repository) would be:

func refreshData(block: @escaping (([ReceivedObject]) -> Void)

This solution is better when you want to focus just on one tas For example if you have many requests in the same View Controller and don’t want to block the whole thread for the sake of a single task - you can simply split them thanks to blocks.

Wrapping up

Which method should I use, you may ask. Out of two ways of requesting data from external sources in VIPER, which I have presented in this short article, none is better than the other. We have to keep in mind that both delegates/protocols and blocks serve different tasks. Each of them is very useful for their dedicated use cases. Have fun with them and enjoy using VIPER!

See also:

Check our latest product - it's based on our experience of managing over 50-people strong company. The tool we're missing as a small company and not an enterprise. is an employee and performance management software. It's an unique tool allowing everyone to be in the loop - by having up to date info about co-workers, time-off, benefits, assets, helping with one-on-ones, being a go-to place for company-wide announcements.

Check out

Contact us

* Required fields

The controller of your personal data provided via this contact form is Prograils sp. z o.o., with a registered seat at Sczanieckiej 9A/10, 60-215 Poznań. Your personal data will be processed in order to respond to your inquiries and for our marketing purposes (e.g. when you ask us for our post-development, maintenance or ad hoc engagements for your app). You have the rights to: access your personal data, rectify or erase your personal data, restrict the processing of your personal data, data portability and to object to the processing of your personal data. Learn more.


We do not track you online. We use only session cookies and anonymous identifiers for the purposes specified in the cookie policy. No third-party trackers.

I understand
Elo Mordo!Elo Mordo!