Migrating a Marvel's App to view code!

Thiago Lioy
Cocoa Academy
Published in
4 min readDec 21, 2016


Nowadays view code is becoming the new hype inside iOS community. It is not something new, in many ways this approach is a return to iOS's origins where views were created in code. If you guys remember Xcode's first versions did not have Interface builder. Storyboard for instance born much later on.

I've become very interested in the subject, after talking with several developers that were adopting view code in there’s applications, claiming several benefits.


  • Better team working, avoiding storyboards | xibs conflicts.
  • Better build time.
  • Code tend to become more modular, reusable, with a clear propose.
  • It is easier to test.
  • It is easier to maintain and evolve the code base.

Today i'm going to migrate a Marvel's app that i've created in a series of posts(*You can check the first post of the series here), to view code. Sharing with you guys my experience, opinions and lessons learned in the process. You can check the project repository with view code here.

The approach ..

Migrating to view code is not something that must be done in a "all in" manner, you can start migrating some small parts of your code first. I've started this process migrating first the cells. They were already living apart of the storyboard in a separated xib. So let's make the diff.

Using xib

Using View Code

There are a lot going on here. The second version using view code is much bigger. Let's analyse the difference before any prejudge.

  • First no more IBOutlets with force unwrap!! =)
  • The cell implements now the Reusable protocol instead of the NibReusable, both from the amazing Reusable pod.
  • The cell must implement now some expected initializers, which were not needed before when it was created from the xib or storyboard. This might look like something bad at first, but now we have control of the initialization process, which is amazing. This makes testing a breeze.
  • The cell also implements a ViewConfiguration protocol, that i've defined to create a pattern
  • This methods are needed now to build the view hierarchy, setup constraints and do some extra configurations.
  • If you notice i'm using SnapKit library, a DSL that makes working with autolayout really easy. There are many other libraries alike: Cartography, PureLayout, to name a few. They all do almost the same thing, personal taste can be your ally here, on choosing the right one for you.

No other change in this project is needed, and all keeps running as it should. The big difference is that, now if you want to change the cell, add another label or button for instance, it is much easier. You only need to change in one place, and forget about merge problems. It is also fast, for the ones tired of dragging and dropping programming, this is the real deal!

Repeating the pattern ..

From this point on your job is to migrate the rest of the project, other cells view controllers and so on. It is almost the same thing so i will only mention the next important parts, you can check the code on the repo anytime .. =)

LoadView, the new kid on the block ..

Now that we're not loading view Controllers from storyboards, we must worry about another life cycle method called loadView, it is called before viewDidLoad. Until now this was done automatically by storyboard, not anymore!! In this method we need to setup view controller's self.view with something that makes sense.

Last part of the puzzle, after ditching the storybord, is to tell our app that we don't need it. Thank god! I'm only joking! This can be done in a two step process. First we tell our app that we don't need a main Interface, the second step is to setup the app delegate to handle this task.



After this step everything should work properly, i will layout another controller here so we can check the diff.

Not using ViewCode

Using ViewCode

You guys, can notice that the controller size is almost the same, but the second version have much less responsibility than the first. Much was moved for more suitable places. Not to mention, no more IBOutlet or IBActions, force unwrap, etc .. It is also much easier to test this new ViewController because we don't have to bring it from the storyboard.

So ..

I've enjoyed so very much this experience. View code is something that I will definitely explore and bring to my future projects. In the future i will make another post about testing + view code, and how we can refactoring our old marvel's app tests to work with our new design. That said, this was my first approach to view code. There are much more to be explored and done.

Now I'd like to hear from you about your experiences with the subject, pain points, other designs, patterns, etc ..

Share your thoughts, as a response bellow. I really think this could be a great discussion!

As always any thoughts, doubts or feedbacks are more than welcome. =)

Ps: If you like this post, share it on twitter, recommend it on medium, or both =). This really helps me to reach more people. Thanks a lot ..



Thiago Lioy
Cocoa Academy

iOS developer, design enthusiast, blogger, weekend cook, guitar player, traveler. Creator of iOS mag: https://medium.com/cocoaacademymag