What I’d like to ask in this article is: how does one apply this concept? Well, there’s the obvious: don’t be precious about sharing your ideas with others. Telling people about them allows iteration, and iteration makes ideas better. But on top of that, it should influence not just how you execute your ideas, but also what ideas you execute.

If you’re anything like me, when you first start trying to come up with ideas… it’s a slow process. But after a certain point, the ideas come in a flood. Pretty soon you have too many ideas to execute than you’ll have time to do in 10 lifetimes.

Applying this principle should help you narrow that list down; ask yourself: which of these ideas is easiest to execute? Note: you may not know the answer to this yourself, and you may need to ask others with expertise their opinion. And that’s wonderful! Again, getting feedback will only make your ideas more robust.

Start with the easiest of your ideas to do. If it works, great! On to the next one, but with more experience (and hopefully money). If it doesn’t work, that’s fine too – you’ll still have more experience for the next easiest idea. The key thing to remember is that you don’t actually know what will work and what won’t – the only way to know is to try, so optimize for trying as many things as possible.

Once you do have some success(es) under your belt, you can start thinking about your more ambitious ideas. If you’re known for executing your ideas, you should have people willing to help you, and if you’ve already run your ideas past them, you should have some buy in from them as well. Once you have those things, so many other things will be easier to fit into place – for instance, if you need to raise money, an experienced team working with a successful executor will have an easier time than a complete unknown.

One final note: when I say “easiest idea to execute” I mean: for you personally. This is another way to narrow down your list of ideas. In a best case scenario, your idea should relate to a problem you have, that you would pay money to whoever solved it for the solution to it. If you have expertise in the problem, you’ll be much better at solving it. If you have to use your solution to actually solve the problem you’re facing, you’ll be able to iterate on the solution faster. That will make your solution better, and more likely to make money from people like you who are facing the same problem. This is also why you should usually try to make something better, not make something new.

Suppose we want to test a part of our code that’s time dependent:

class SomethingImportant {
  func aTimeDependentAction() {
    var currentTime = Date()
    // ...do something with the current time
  }
}

To test this code, rather than using Date() to get the current time, we want to inject a dependency that returns the time so we can swap it out in our tests. Great! This dependency injection is a classic case for a protocol, or so we might believe. Let’s create a protocol and a default implementation:

protocol DateProvider {
  func currentDate() -> Date
}
class DefaultDateProvider: DateProvider {
  func currentDate() -> Date {
    return Date()
  }
}

Well that was easy! Now let’s add a dependency on this to the class we want to test:

class SomethingImportant {
  var dateProvider: DateProvider

  init(dateProvider: DateProvider = DefaultDateProvider()) {
    self.dateProvider = dateProvider
  }

  func aTimeDependentAction() {
    var currentTime = dateProvider.currentDate()
    // ...do something with the current time
  }
}

So far so good – we have a date provider variable that we accept in the initializer that will give us the current date. Now let’s make a version we’ll use in our tests:

class MockDateProvider: DateProvider {
  func currentDate() -> Date {
    return Date(timeIntervalSince(1632745282432))
  }
}

Rad! Now all we need to do is instantiate our SomethingImportant class with our mock provider:

SomethingImportant(dateProvider: MockDateProvider())

Now, let’s add some complexity: what if we now want to test a different time in addition? Well, now we need to make a whole new implementation of DateProvider. In fact, we’ll need to create a different provider for every time we want to test. Creating a whole new class for each time we’re looking to test is… frustrating. This is a simple example, so it’s relatively easy to copy paste these classes, but imagine a more complex example and all those extra classes get a little overwhelming.

What if we use functions instead? Well, ok, let’s change our SomethingImportant to depend on a function:

class SomethingImportant {
  var dateProvider: () -> Date

  init(dateProvider: () -> Date = Date.init) {
    self.dateProvider = dateProvider
  }

  func aTimeDependentAction() {
    var currentTime = dateProvider()
    // ...do something with the current time
  }
}

This already looks simpler: no protocol, no implementations, just the raw functions. How could we mock this? Easy:

SomethingImportant { Date(timeIntervalSince(1632745282432)) }

If we add the additional complexity of wanting to test multiple times, it’s still very simple: no need for a whole class for each time, we’re just passing in a different function directly – something we can easily do in the test function itself, making the tests easier to understand.

This is why we say functions to protocols – protocols require an implementation, which often involve functions, so you may as well cutout the middleman in every case you can. I’ve written elsewhere how applying functional programming concepts to protocol implementations themselves can save you time, energy, and lines of code.

If you liked this article, I’d highly recommend checking out PointFree – they go into this and a bunch of other incredible demonstrations of functional programming’s benefits.

My app development company wrote some code to make error handling easy. With this approach, you can handle errors on a given task in one line of code!

Let’s look at an example. Lots of folks now use URLSession directly, or with a minimal wrapper over it. You might do something like this:

let vc = UIViewController()
var cancelBag: Set<AnyCancellable> = []

let request = URLRequest(url: URL(string: "https://lithobyte.co/api/v1")!)
let session = URLSession(configuration: .default)
var taskPub = session.dataTaskPublisher(for: request).eraseToAnyPublisher()

// handle success
taskPub.sink(receiveCompletion: doNothing, 
             receiveValue: handleSuccessFunctionGoesHere)
    .store(in: &cancelBag)

In words, we have a view controller and some cancellable holder, we create a request and a session, and from those we get a taskPublisher using URLSession‘s Combine extensions, handling the data received in a success scenario. Then handling errors is as simple as adding something like this:

taskPub
  .sink(receiveCompletion: debugTaskErrorAlerter(vc: $0), 
        receiveValue: debugServerResponseErrorHandler(vc: $0))
  .store(in: &cancelBag)

That is, in words: on completion, handle any URLLoading errors (eg, no internet, request timed out, etc), and on receiving a server response, handle any errors returned by the server (eg, 404 not found, 500 server error, etc).

How does it work? Well, there’s some functional programming magic to it (which just allows easy composition of functions for flexibility), but basically it takes in a view controller and uses it to display a UIAlertController that it creates depending on the error encountered. There’s a default parameter called error map that you can pass in to provide your own server error descriptions, and we’ve supplied a custom operator << to merge dictionaries so you can take the defaults for everything except the ones you care about, eg:

debugServerResponseErrorHandler(
  vc: $0, 
  errorMap: urlResponseErrorMessages << [401: "Unauthorized. How DARE you."]
)

Which would use the default error messages except for 401, and in that case it would use what you supplied (in this case: “Unauthorized. How DARE you.”). Just like this:

There are a lot of error handling functions you can use in this library, with lots of ways to mix and match, but it’s helpful to know about custom operators and functional programming, since composing those functions will make things significantly easier.

With this library you can display errors with a simple alert, print the errors, decode any json data associated with the error (in fact, a lot of server frameworks return JSON that looks something like { “message”: “User was not authorized” }, and this library can easily decode and display that message to the user in place of the default error code message), replace the default messages with your own, and so on. But frankly, the reason it’s so useful is that all you have to do is add the cocoapod:

pod 'FunNet/ErrorHandlingCombine', git: 'https://github.com/LithoByte/funnet'

and with one line of code per request you can provide a default error handler. That, for me, is the biggest win, especially early on in an app’s development. Concentrate on the features you want, but make bug squashing down the line easy? Yes please and thank you.

Everything your program does, it does with functions. Classes, as a concept in Object Oriented Programming, are largely organizational; that is, they work to constrain and restrict functionality to a given context, to limit where that function(ality) can be used. This can be extremely useful when breaking a problem down, and grokking each part – but it also limits the code you write (which can be a good thing, don’t get me wrong — it’s designed to limit scope).

By leaning on functions over objects, on the other hand, you give yourself (and other people who use your code!) more flexibility in the long run. This, too, can be both a blessing and a curse – too much flexibility and limitless possibility can cause confusion – but knowing how to use it will give you tools to write better code.

When I first started teaching (object oriented) programming, I described classes as nouns and functions as verbs. That is, a class or object has things that it does and things that it owns. A Person object might have related objects (properties) called name or age, and might be able to do things like write() or walk().

This way of thinking can be genuinely useful when programming. For the example above it works really well: all of us can clearly imagine how to model a Person by describing things they have or do. Unfortunately, however, it can also cause some strange anti-patterns, especially when we get into real world programming scenarios.

I’m a mobile app developer, so let me take an example that happens in almost every app I work on: displaying lists of things.

In iOS, Apple has built a UI element called UITableView that we as developers can use to display lists. This class allows you to handle various user-driven events (like if the user taps on an item in the list or scrolls to the next item) by providing it with something called a UITableViewDelegate. This delegate has a bunch of things it can handle, but let’s concentrate on tapping and scrolling in particular, as those relate to two of the most common list-related tasks:

• taking the user to a new screen that displays details about the clicked on item, and
• loading more items when the user scrolls to the bottom of the list.

The Object Oriented (or OO for short) approach to this is to create a UITableViewDelegate that does BOTH of those things – and for simple use cases, this isn’t the worst thing. In Apple’s example code, the UITableViewDelegate lives in a class that is capable of doing both, and, what’s more, in simple cases both of those things are a line or two of code.

But if you’ve worked on programming for any amount of time, you know that simple things quickly become complicated. One line of code becomes two, becomes four, becomes a hundred.

Housing these two distinct bits of functionality in one place will make experienced programmers wince for a different reason: it violates one of our most important, most sacred, and (probably) most violated laws, the revered “Single Responsibility Principle” (or SRP for short). If you’re not familiar with it, the concept is simple enough: a class should do only one thing. This is a little vague, so we generally alter it to say: a class should have only one reason to change. In this case, if we wanted to change what happens when a user taps on a list item, OR if we wanted to change when we fetch the next chunk of items, this class would have to change; therefore, SRP is being violated.

So how could we fix that? The pure OO approach might be to give the UITableViewDelegate an object that can display the item details screen as well as a separate object that can fetch more items. And that would work! But, I’d argue, it may also be overkill. In iOS there already exist classes to display screens, but they do more than just display screens; so handing one of these over to an instance of UITableViewDelegate gives it access to more functionality than just displaying the screen. On the other hand, if you want to restrict UITableViewDelegate to just displaying the new screen, you’d have to create a new class that does only that… which is reinventing the wheel, since you’ll need to copy the functionality from an existing class. A similar argument can be made for fetching more items.

In many modern languages, however, you can pass functions around as objects. That is, you can create variables/properties that hold functions. With this in mind, instead of creating a version of UITableViewDelegate that accepts an object with the relevant function, you can create a UITableViewDelegate which can just accept the relevant function itself, as an object.

This will allow you to share exactly the functionality you want with UITableViewDelegate, all the while keeping the rest of the functionality cordoned away.

By doing this, your code becomes more expressive and concise. Since we name functions using verbs, it becomes really clear what we want to do:

delegate.onItemSelected = viewController.displayDetailsScreen
delegate.onScrolledToBottom = Api.items.loadNextPage

This feels much better. We’re clearly, concisely saying that when an item is selected, we should display the details screen; when the user scrolls to the bottom, we should load the next page of items. Better, these functions live in relevant places: the view controller (or, in best practice, the flow coordinator) should control displaying a new view, while the API should probably be in charge of fetching another page of items for display. And finally, this is all more reusable: a delegate with settable functions in this way can be used anywhere in your app, you just have to swap out the functions; the OO version would only be usable in one place.

This is the power of functional programming. By focusing on functions instead of objects, you allow yourself to let functions live where they make the most sense, not where they have to in order to satisfy some generalized requirements. It makes functionality easier to find, and easier to reuse. SRP is easier to satisfy, we’re following Apple’s recommendation to use configuration over customization, and jeez is this code readable – not to mention that due to its simplicity, it’s easy to test.

The concepts from FP have really leveled up my development. I’m writing more tests, I’m reusing a huge percentage of code between projects, and making changes to apps is a breeze. For sure, it’s a paradigm shift, and as a result it takes some work to grok – but once you do, so many more things become possible.

How they solved this chicken and the egg problem was creative to say the least. They went to their alma mater on a Saturday night, and went to a sorority at which they had connections. They stood up and told the whole house about the app, and how there were tons of guys waiting to meet them. Then, they immediately left the sorority and sprinted to the nearest frat, where they told THEM that there were tons of girls on the app waiting to meet them. And so it went, all that night, going from sorority to frat to sorority as quickly as possible to get as many people swiping as possible.

This is an example of a simple multi-sided business: at the time Tinder needed girls on it for the guys to want to use it, and it needed guys on it for the girls to want to use it. Even now, the same is true no matter how you use Tinder; if you’re looking to match with anyone of any gender description, for you to use the app you need people of that/those gender(s) to also be using the app.

There are tons of other multi-sided businesses as well, for instance: food ordering apps (restaurants need lots of customers, people want lots of restaurants), car service apps (drivers want to have lots of riders, riders want lots of driver availability), and any sort of reservation app (hosts want lots of guests, guests want lots of options for stays).

Now, I just listed some common markets for these companies. In fact, you can probably name several companies in each category (eg, Grubhub and Chownow for food apps, Lyft and Uber for car service apps, and Airbnb or Hipcamp for reservation apps). However, these sorts of companies can be very difficult to get off the ground. The reason for this is the company is attempting to offer something different to multiple, totally different groups of people. If those multiple groups are required to make your company a success, then failing to interest ANY of those groups dooms you to failure.

I do not recommend beginning entrepreneurs attempt to build a product like this. Getting product-market fit for a single market is hard enough, let alone a market that relies on another market to be successful.

Let me give you an example of a company I see getting invented every few years. The idea goes like this: young adults want to know where the party is, so we’ll provide an app that shows you where there are large groups of your peers on a party night. One iteration of this I saw was a company that put blurred out webcams in bars, so you could see how busy a bar was but not necessarily who was there (for privacy).

Problem is, you have to provide value to two separate groups for the product to be useful. Bars have to see the value in it to put the cameras in, while people need to have enough cameras in their favorite bars to use the app. To make any money, the company has to charge the bars, and they’ll have to make the case that the bar will get more customers as a result. But that’s a chicken and egg problem, in that without lots of users you can’t say that the bar will get more customers, which means bars won’t sign on, and without lots of bars users won’t use the app.

Now, this is exactly what funding is for; to prove out your case, to get you through the period when you don’t have enough of either users or bars. If bars don’t have to pay money, perhaps they’ll be more likely to install the cameras. But they’ll still have to manage the cameras to an extent, which is an opportunity cost in itself – and I’ve heard that bars, restaurants, and other service based local businesses are getting offered things like this all the time, so even when it’s free it could be a hard sell. Many investors won’t want to invest in something that doesn’t have revenue sources lined up, and so now you have a different chicken/egg problem: to get revenue lined up, you need investment, and to get investment you need revenue lined up.

Solving these problems is possible. Obviously, companies have done it. But jeez is it hard to build something that has to be an amazing experience for multiple different stakeholders. If you’re starting out in entrepreneurship, there are lots of ways to create value – I’d suggest starting with something else.

Let’s consider a common task in iOS development: building styling code we can easily reuse throughout an app. Suppose, for the sake of argument, we want to build an interface something like this:

Cool! So, how do we start? Well, let’s look at the properties of the buttons here:

• Each button has rounded corners
• Two buttons have a blue border
• Two buttons have a grey background

Great! How, normally, would we start to build this in an Object Oriented fashion? Well, it’d be reasonable to start with a super class that has rounded corners, but here we already run into an issue:

open class DiamondButton: UIButton {
    required public init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        layer.cornerRadius = 4
    }

    override public init(frame: CGRect) {
        super.init(frame: frame)
        layer.cornerRadius = 4
    }
}

We have a required initializer which requires us to repeat our code. That’s ok though, we can just add a function that both initializers call:

open class DiamondButton: UIButton {
    required public init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        setupCorners()
    }

    override public init(frame: CGRect) {
        super.init(frame: frame)
        setupCorners()
    }

    func setupCorners() {
        layer.cornerRadius = 4
    }
}

This is a little redundant, but that’s ok – we’ve isolated the code appropriately and are just calling it from the initializers. What’s next? How about handling that grey background, like in the solitary button:

open class BgButton: DiamondButton {
    required public init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        setupLightGreyBackground()
    }

    override public init(frame: CGRect) {
        super.init(frame: frame)
        setupLightGreyBackground()
    }

    func setupLightGreyBackground() {
        backgroundColor = UIColor(displayP3Red: 0.8, green: 0.8, blue: 0.8, alpha: 1)
    }
}

Well, ok, now we see another problem: we have to implement both initializers each time we subclass it. So, we’ll go back to the super class and change it to call a single configuration function that our subclasses can override, obviating the need for the duplicate initializers:

open class DiamondButton: UIButton {
    required public init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        configure()
    }

    override public init(frame: CGRect) {
        super.init(frame: frame)
        configure()
    }

    open func configure() {
        setupCorners()
    }

    func setupCorners() {
        layer.cornerRadius = 4
    }
}

And now our subclass is much simpler:

open class BgButton: DiamondButton {
    override open configure() {
        super.configure()
        setupLightGreyBackground()
    }

    func setupLightGreyBackground() {
        backgroundColor = UIColor(displayP3Red: 0.8, green: 0.8, blue: 0.8, alpha: 1)
    }
}

That’s… ok, but it does feel like we’re having to override 3 functions and implement another two, just to allow two behaviors we want. But whatever, let’s press on, let’s handle the cancel button, which has a border and rounded corners:

open class BorderButton: DiamondButton {
    open override func configure() {
        super.configure()
        setupBorder()
    }

    func setupBorder() {
        layer.borderWidth = 1
        layer.borderColor = UIColor.blue.cgColor
    }
}

That’s another class and two functions in order to enable one behavior; feels like overkill, but it works, so let’s not worry about it. Alright, last button! Let’s implement the button that needs rounded corners, a blue border, and a grey background:

…except we have a problem. Both our BorderButton and our BgButton subclass DiamondButton to get the rounded corners. We want our new button to include all of those things, but we can only subclass one thing. If we subclass BorderButton, we won’t get the grey background. If we subclass BgButton, we won’t get the blue border. This is called the Diamond Inheritance problem, and it’s called that because when we diagram it out it kinda looks like a diamond shape; we want the features of two different super classes, but we can only subclass one:

    Diamond
   /       \
Border   Background
   \      /
    Paired

So what can we do? If you’re like me, you’re getting a twitch in your eye because you know you’re going to have to reimplement something. The best we can do is perhaps use an extension on UIButton that holds all our setup functions, and then refactor our code to call those functions appropriately:

extension UIButton {
    func setupCorners() {
        layer.cornerRadius = 4
    }

    func setupLightGreyBackground() {
        backgroundColor = UIColor(displayP3Red: 0.8, green: 0.8, blue: 0.8, alpha: 1)
    }

    func setupBorder() {
        layer.borderWidth = 1
        layer.borderColor = UIColor.blue.cgColor
    }
}

open class DiamondButton: UIButton {
    required public init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        configure()
    }

    override public init(frame: CGRect) {
        super.init(frame: frame)
        configure()
    }

    open func configure() {
        setupCorners()
    }
}

open class BgButton: DiamondButton {
    override open configure() {
        super.configure()
        setupLightGreyBackground()
    }
}

open class BorderButton: DiamondButton {
    open override func configure() {
        super.configure()
        setupBorder()
    }
}

This would minimize the amount of duplication we need to do for the PairedButton:

open class PairedButton: BorderButton {
    open override func configure() {
        super.configure()
        setupLightGreyBackground()
    }
}

However, that still makes me feel icky because PairedButton and BgButton are basically the same, only the name and superclass are different. Now imagine if this was a more complicated example, and much more code had to be duplicated – yikes!

Let’s look at how we’d do this with functional programming. Since functional programming (FP for short) is all about functions, let’s write some!

func setupCorners(_ object: UIButton) {
    object.layer.cornerRadius = 4
}

func setupLightGreyBackground(_ object: UIButton) {
    object.backgroundColor = UIColor(displayP3Red: 0.8, green: 0.8, blue: 0.8, alpha: 1)
}

func setupBorder(_ object: UIButton) {
    object.layer.borderWidth = 1
    object.layer.borderColor = UIColor.blue.cgColor
}

These are all just the functions from our extension, except they have a parameter instead of referring to self.

So how do we use them? Well, we can just pass in the buttons to the functions:

class MyViewController: UIViewController {
  @IBAction var solitaryButton: UIButton!
  @IBAction var cancelButton: UIButton!
  @IBAction var pairedButton: UIButton!

  override public func viewDidLoad() {
    super.viewDidLoad()

    setupCorners(solitaryButton)
    setupLightGreyBackground(solitaryButton)

    setupCorners(cancelButton)
    setupBorder(cancelButton)

    setupCorners(pairedButton)
    setupBorder(pairedButton)
    setupLightGreyBackground(pairedButton)
  }
}

Whoa! That’s way easier! Fewer lines of code, and very easy to understand. And it gets better: we can generalize these into more free standing functions, so we can use them anywhere in our app (which is like the whole point of styling code):

func styleSolitary(_ solitaryButton: UIButton) {
  setupCorners(solitaryButton)
  setupLightGreyBackground(solitaryButton)
}

func styleBordered(_ cancelButton: UIButton) {
  setupCorners(cancelButton)
  setupBorder(cancelButton)
}

func stylePaired(_ pairedButton: UIButton) {
  setupCorners(pairedButton)
  setupBorder(pairedButton)
  setupLightGreyBackground(pairedButton)
}

Which makes our view controller even shorter:

class MyViewController: UIViewController {
  @IBAction var solitaryButton: UIButton!
  @IBAction var cancelButton: UIButton!
  @IBAction var pairedButton: UIButton!

  override public func viewDidLoad() {
    super.viewDidLoad()

    styleSolitary(solitaryButton)
    styleBordered(cancelButton)
    stylePaired(pairedButton)
  }
}

Very short, very clear, very reusable.

So, why does this work?

Fundamentally, functions work to expand the capability of your code, while classes restrict it. Sometimes that’s good – it helps with modularization and SRP – but the restrictions here are hurtful, not helpful. There’s no reason to restrict only BorderedButtons to having a border, or only BgButtons to having a grey background – in fact, that was the entire problem. Object Oriented programming often unnecessarily restricts functionality to certain classes when there’s no reason to.

FP, however, makes it easy to write programs that can act on the broadest possible set of concepts. Because functions are about adding functionality, you have much better control over the scope of their parameters and outputs.

Realizing this (by watching the PointFree videos) is what convinced me to do more FP in my own work. This has led me to being able to do in hours what it used to take weeks to do. I have more code I can reuse between projects, my code is easy to stub, easy to refactor, easy to add new things to, and easy to test, all because of the power, flexibility, and reusability that FP provides me.

Functional Programming is fun and all the cool kids are doing it. MVVM has made my code clearer and more testable. Several libraries I’ve written make my code more flexible, while others allow me to skip to the fun stuff.

There’s a lot of really neat stuff happening in Swift these days. I’ve been super excited about the great content coming out of PointFree, and cool new libraries are coming out weekly at least. Swift gives us so many powerful features and shiny new toys to play with, it’s easy to get carried away.

However, while it’s very tempting to, as soon as you discover a cool new way to do things, refactor all your codebases to make use of [shiny new architecture/library/paradigm], it often adds unnecessary dev cycles to your work (I find it similar to the “let’s start from scratch” phenomenon). We all want to build something beautiful – but the truth is, what we had was probably already pretty good… which is why I try to remain pragmatic about my codebases. Here are some rule I use to keep shipping while still loving my older codebases.

Ask yourself: will this improve the codebase (in a non-aesthetic way)?

Sure, the new thing is pretty. But will it make something you plan to do easier? Or do you just want to do it because it’s pleasing? Does it enable you to do more in the future? Or just reduce line count on what you’ve already written?

This is the heart of pragmatism here: unless it helps future-you, it’s probably not worth giving present-you more work rewriting stuff that past-you already completed. Moreover, you need to consider how much work doing a refactor will take, and compare that to how much work it’ll save you in the future compared to sticking with what you’ve got. If it doesn’t balance out, it may not be worth the investment on this codebase, which is why I try to:

Always have new projects

This one I always keep in my back pocket, and keeps me from overhauling a project that doesn’t need it just because I want to play with something new and fascinating. New projects are a great chance to try out new things; they allow you to play, but productively.

Whenever I want to start a new project (which is h*ckin often) I try one of the new toy libraries out there.

But what if you need to do it in an existing project?

Stick to SOLID

SOLID is a classic for a reason. When incorporating something into a pre-existing project, try to limit the interface between them. That makes it easy to tear out and replace it with the next new thing you want to try out.

That said…

Prefer protocols to classes; prefer functions to protocols. The first part of the statement should seem pretty familiar to Swift devs who are already sticking to SOLID. The second might be a little less familiar, but I’ve written a short article with an example of why preferring functions makes your code simpler, more modular, and easier to understand.

Love the lazy refactor

Wanna use something new and neat in your codebase but don’t want to spend a lot of time rewriting the old way of doing it? Use the Lazy Refactor! It’s simple: if you, in the course of doing something you’d do anyway, stumble across the old way of doing things, then refactor just that one place.

There is danger here: if you never complete a lazy refactor, your codebase can get littered with obsolete code and bloated with barely used libraries.

So what do you think? What strategies do you use to stay on top of changes in the Swift ecosystem without giving yourself way more work than you need to?

“You have to believe in yourself and your idea.”

“Everyone will tell you your idea is bad – just keep going.”

“You miss 100% of the shots you don’t take.”

And so on. And it’s true, of course, in a way – entrepreneurship is a difficult emotional journey, and there will probably be many more downs than ups for quite some time (believe me, I know). If you bow to that pressure, you’ll miss out on any potential the business ever had.

But by this logic, you should never give up. Not only that, but you should believe in your idea unquestionably. That, to me, is an issue: sure, you miss 100% of the shots you don’t take, but if you do take a shot, how do you know when you missed?

There’s a time, in entrepreneurship, to cut your losses (or, better, walk away with your winnings). Having an accurate, realistic vision of what your idea can really do is invaluable. I see lots of entrepreneurs aiming for a billion dollar valuation down the road, trying to make the case to angels and VCs that their idea will be the one that turns out to be a unicorn; but it’s a tough sell for anyone. There are lots of good ideas, ideas that the world needs, that will never be worth a billion dollars. Aiming for that, especially from the get-go, is a recipe for over confidence on the one side and disappointment on the other.

And let me tell you, I’ve seen many entrepreneurs over extend themselves against all the evidence that they should get out now. Trying to force an idea to work when it’s never going to (or, at the least, when you don’t have access to the resources to make it) is only going to deplete your savings, strain your relationships, and make you miserable, before eventually you have to pack it in anyway.

I prefer a model of entrepreneurship based on faith in oneself and doubt of the idea. The difference here is believing in yourself doesn’t mean you think you can do anything – it means you can do something. You don’t have to have all the strengths as long as you can find other people to help you.

Doubting the idea itself allows you to take a critical eye to what you’re doing, to think clearly about what your goals are, keep the problem you’re trying to solve in view, and to test your assumptions aggressively.

Doubt is a powerful motivator to innovate, and shouldn’t be spurned just because it’s uncomfortable.

So, in collaboration with the excellent Soroush Khanlou, my mobile app development company created an encoder (like the JSONEncoder many of you will be familiar with) that will convert a Swift object to a multipart data stream that you can attach directly to a URLRequest. Suppose we wanted to upload a model like this with a multipart request:

struct TitledImageUpload: Codable {
    var title: String?
    var file: PngImage?
}

PngImage refers to an empty subclass of UIImage that exists solely so you can be explicit about how you want to encode the data – but to be clear, any UIImage can be cast to a PngImage, and if you want your data encoded as a jpg instead you can just call our extension function on UIImage called jpgImage(ofQuality:), which will return a jpg of the requested quality. And just like for a JSONEncoder, we make the model Codable.

With that definition out of the way, here’s how we use it:

let image = UIImage(named: "...")
let imageUpload = TitledImageUpload(title: "Awesome Img", file: image as PngImage)
let encoder = FormDataEncoder()
let stream = try? encoder.encode(imageUpload, boundary: "--boundary-\(Date().timeIntervalSince1970)file-image-boundary--")
let request = URLRequest(url: URL(string: "https://lithobyte.co/api/v1")!)
request.httpMethod = "POST"
request.httpBodyStream = stream?.makeInputStream()
// add headers, etc

We take the UIImage called image and create our struct from it, casting the UIImage as a PngImage, then we create a FormDataEncoder, and encode the struct with a multipart boundary. This gives us a stream that we can assign to a URLRequest‘s httpBodyStream.

This is available as a subspec in our networking library, which I introduced when talking about what I want in an ideal networking layer. To use just the multipart stuff though, add it to your Podfile like this:

pod 'FunNet/Multipart', git: 'https://github.com/LithoByte/funnet'

So, to help alleviate this problem, I wrote a lightweight library called fuikit that allows me to leverage the power of FP with UIKit objects and classes. It works by subclassing common UIKit classes and creating a bunch of functions as properties. So for instance, instead of implementing viewDidLoad in every subclass of UIViewController, you could just subclass FUIViewController and assign a function to its property called onViewDidLoad:

class MyViewController: FUIViewController {}

func myViewController() -> MyViewController {
    let vc = <create MyViewController>
    vc.onViewDidLoad = setupMyViewController(_:)
}

fuikit offers a bunch of these sorts of subclasses of common UIKit classes, including UIViewController and UITableViewController, as well as functional style implementations of common protocols such as UITableViewDataSource and UITableViewDelegate, among many others.

So why is this cool? Flexibility! Let’s look at an example.

Suppose you have an array of Users that you’d like to display in a table view. Normally this would entail implementing UITableViewDataSource with a couple functions. But using fuikit, you could just do this:

func usersDataSource(users: [User]) -> UITableViewDataSource {
  let dataSource = FPUITableViewDataSource()
  dataSource.onNumberOfRowsInSection = { _ in users.count }
  dataSource.onCellForRowAt = { tableView, indexPath in
    if let cell = tableView.dequeueReusableCell(withIdentifier: "userCell") as? MyTableViewCell {
      configure(cell, with: users[indexPath.row])
      return cell
    }
    return UITableViewCell()
  }
  return dataSource
}

func configure(_ cell: MyTableViewCell, with user: User) { ... }

In words, this creates an instance of FPUITableViewDataSource, assigns a closure to onNumberOfRowsInSection which just returns the number of users you’re displaying, and then assigns a closure to onCellForRowAt which dequeues a cell, configures it with a function defined elsewhere, and returns it. This allows you to use composition to break down each step of configuring the cell into component parts, and use/reuse them freely. For instance, suppose you had another model called Contact, which has a user: User? property, and you wanted to display the list of contact users in a table view. Then all you need to do is this:

let contactUsers = contacts.compactMap { $0.user }
let contactUsersDataSource = usersDataSource(users: contactUsers)

Rad! But what if you want to display the contact itself in a different way? We can do the same thing as before:

func contactsDataSource(_ contacts: [Contact]) -> UITableViewDataSource {
  let dataSource = FPUITableViewDataSource()
  dataSource.onNumberOfRowsInSection = { _ in contacts.count }
  dataSource.onCellForRowAt = { tableView, indexPath in
    if let cell = tableView.dequeueReusableCell(withIdentifier: "contactCell") as? MyTableViewCell {
      configure(cell, with: contacts[indexPath.row])
      return cell
    }
    return UITableViewCell()
  }
  return dataSource
}

func configure(_ cell: MyTableViewCell, with contact: Contact) { ... }

which we can use similarly as well:

let contactsDataSource = contactsDataSource(contacts)

If you look closely, you’ll notice that only 3 things are different between the contacts function and the users function: a) the cell identifier, b) the configure function called in onCellForRowAt, and c) the type of the array of users/contacts.

So, if we want to get ~fancy~, we can generalize this to ANY array of objects to be displayed in ANY UITableViewCell using generics:

func arrayDataSource<Model, Cell>(models: [Model], 
                                  configurer: @escaping (Model, Cell) -> Void,
                                  identifier: String = "Cell") 
  -> UITableViewDataSource where Cell: UITableViewCell {
    dataSource.onNumberOfRowsInSection = { _ in contacts.count }
    dataSource.onCellForRowAt = { tableView, indexPath in
      if let cell = tableView.dequeueReusableCell(withIdentifier: identifier) as? Cell {
      configurer(cell, with: models[indexPath.row])
      return cell
    }
    return UITableViewCell()
  }
  return dataSource
}

And we could use it like this:

func configure(_ cell: MyTableViewCell, with contact: Contact) { ... }
let contactsDataSource = arrayDataSource(models: contacts, 
                                         configurer: configure(_:with:), 
                                         identifier: "contactCell")

which reproduces the contactsDataSource we defined above. As you can see, this approach is incredibly flexible, and doesn’t require a new UITableViewDataSource subclass every time you want to display a list of things. It removes boilerplate and allows you to concentrate on the things that are *different* about your app.

So how would we actually use this on a table view? Or in a controller with a table view in it? Well, as a matter of fact, fuikit provides a view controller for that purpose. It’s a regular UIViewController subclass with an outlet for a tableView and a bunch of function properties for the view controller’s lifecycle, and it’s implementation looks something like this:

open class FPUITableViewViewController: UIViewController {
  @IBOutlet public var tableView: UITableView?
    
  public var onViewDidLoad: ((FPUITableViewViewController) -> Void)?
  ...

  open override func viewDidLoad() {
      super.viewDidLoad()
      onViewDidLoad?(self)
  }
    
  ...
}

This is a class I subclass all the time, since so many VCs contain table views somewhere. By having this as the superclass, I can use existing functions to set up the tableView, while also allowing me to do the normal styling, IBActions, and other VC tasks that we’ve come to expect. So for instance, to display a list of contacts, I could create the following function:

func setupMyViewController(_ vc: MyViewController) {
  let contactsDataSource = arrayDataSource(models: contacts, 
                                           configurer: configure(_:with:), 
                                           identifier: "contactCell")
  vc.tableView?.dataSource = contactsDataSource
  
  // since dataSource is a weak property on UITableView,
  // store contactsDataSource in a strong property:
  vc.dataSource = contactsDataSource

  // style vc, etc.
}

class MyViewController: FPUITableViewViewController {
  var dataSource: UITableViewDataSource?
}

Then, wherever you configure your VC (a flow coordinator, prepareForSegue, etc) you can just set the appropriate property, like so:

vc.onViewDidLoad = setupMyViewController

(This is not exactly true – onViewDidLoad technically passes a FPUITableViewViewController, so you’d need to use an operator like ~> to cast it appropriately, which is described on my article on optional casting.)

With this, the view controller becomes an empty, reusable, configurable class, and the functions involved are (mostly) reusable. This allows me to write more, better code faster, and build almost unimaginable libraries that speed up development and reduce bugs.