Rewriting an app in Swift, part 1

4 min readDec 28, 2017

Part 2 is here

Hello guys, I’m the creator of Todo Rugby, an app developed to bring rubgy fans info and news updates about matches, fixtures, tournaments and teams. I started developing it a year and a half ago and launched on June 13th of 2016. In that moment, I wrote it on Objective-C because it was my main language for developing iOS apps, and the learning curve of Swift was kind of annoying for me. I was wrong.

Today I’m starting a series of posts about how I’m writing from scratch the same app on Swift, what problems I’m encountering with, what are the solutions I’m taking, and why should you all consider doing the same, or at least start integrating and developing new features with it. On the following posts you’ll be able to see my progress, and how fast I’m moving on with it.

One of the main reasons I didn’t started earlier was the fact that with newer versions of Swift, you had to convert all your code base to the new syntax, which was too tedious and a pain in the ass for all the developers. With Swift 4, the code you write today won’t change on future versions (hopefully). Part of this is because Swift has gained a lot of support from the community (42k ⭐ on Github at the time I wrote this). So let’s start with this.

Where should I start?

Every time a developer starts a new project, a whole of ideas and a bunch of code starts boiling from it’s head. This is because we usually think quicker than we can write code.

First of all, I like to start coding the basic structure and the skeleton, which for me is the navigation. After removing the storyboard (I don’t like it), I have to code the window initialization:

Don’t forget to remove the Main Interface on your Target settings:

⌘ + R and voilà. The first step of a long road is done.

CocoaPods

The second step of this journey is to integrate, IMO, the best dependency manager for iOS: CocoaPods. I’m a big fan of not reinventing the wheel, and when it comes to coding, using a well tested, documented and supported library is way better than programming it yourself. So let’s start installing it by running on your console pod init . Here I’m not covering how to manage your Podfile or how to install the dependencies.

However, there are a couple of libraries worth to mention:

Localize-Swift: it’s a helper for all your localization problems
R.swift: it’s one of the greatest libraries developed for the iOS ecosystem. This gives you the ability to get strong typed autocompleted resources, the same one that exists from the beginnings of Android.
SnapKit: the best library for layout views programmatically that already existed on Objective-C it’s available too for Swift, and is amazing!

Navigation Manager

The third step on this post is about a singleton that should exist in every app, and that I like to call it the NavigationManager . As you may expect, we have to make it a singleton. But how to make a singleton on Swift? This is the way we used to write singletons on Objective-C:

Now, googling a little bit, I find a way to code a one-liner (or two) singleton on Swift:

Better right?

So now the only thing we have to do on the AppDelegate is to call NavigationManager.sharedInstance.start() . And that’s it.

Drawer and Tabs

If you download Todo Rugby from the AppStore, you’ll notice that it has two kind of navigation patterns: Drawer and Tabs. The reason why I took this decision is simple. I needed a way to show the user the available tournaments, but also navigate through the information of each tournament:

Drawer

So in order to replicate this, I’m going to install the same library than the one used on Objective-C: MMDrawerController.

TabBarController

The second thing that I need is to subclass the well known UITabBarController . I like to do this due to a couple of reasons:

This class knows what’s the selected tab and the classes that are on each tab.
Remove code from classes where don’t need to be there (e.g. NavigationManager ).