When You Are Lazy to Rewrite Your Code but Want to Have Reactiveness


Often in projects you can have a callback hell :) You do. Glad if you don’t have it. And at some point of time someone comes and says: “Let’s use a new library that uses promises/futures/reactiveness, so we won’t have callback hell anymore!”

And you agree that you need to do it, but your codebase is soo large, that you cannot do migration with one change only.

Here’s an implementation of the crazy idea of how you can perform such migration, so that:

  • You don’t need to rewrite everything at once;
  • You can use both variants, while you’re migrating;
  • You’ll use some magic. :)

Deprecate all the things

Since you’re migrating – deprecate old methods, so next time you see those methods, you will use correct implementation (probably)

Duplicate existing methods with promises

In case if everything is written in one style – just use rename and replace. If not – just do it manually :) Here’s an example of how you can do it for current project

Convince compiler that you know what you’re doing

We’re not going to implement all methods now, instead we’ll use forward invocation technique. Since we’re doing this, we’ll need to suppress compiler warnings

Performing Runtime Magic

Since we decided not to have implementation of methods those are returning promises, in order to use Message Forwarding we would need to implement two methods:

First one is:

Second one is:

First one is used by runtime to understand what structure it needs to pass params to the method and return values from it. In this example we’ll have only object parameters + success and failure blocks, so it’ll be easy to construct method signature. We also will have helper method that will search for original method selector based on ‘promise’ method selector. So we’ll be able to search for


Once we returned valid method signature for ‘promise’ method, we’ll need to implement invocation forwarding.

Forwarding invocation

Our steps will be next:

  • Find original selector that we need to call based on ‘promise’ method

  • Create NSInvocation with original selector

  • Pass all parameters to original selector invocation

  • Add two additional parameters (success and failure block)
  • Create a promise
  • Resolve promise with a success in success block
  • Resolve promise with an error in failure block

  • Return promise as a value

Now you can use your manager with promises!



  •  There are a lot of ways how to do it, each one has his own pros and cons.
  • This was just an example of one possible implementation.
  • This will work only for small amount of users.
  • I would not recommend using this approach, if you aren’t covering something with tests.
  • We can easily add cancelling there.
  • This one was just a proof of concept, that this is theoretically possible to do in short period of time.
  • Make code, not war.

Originally published on GitHub


Read more:

Optimistic Models 1: Do Not Let Your User See Spinners

Optimistic Models 2 : Handling Multiple Interactions Without Server Confirmation

November 23, 2015

app developmentios