Arkadiusz Holko

Hiding Implementation Details Using internal Properties

Mon, 08 Oct 2018 16:25:37 +0200

Swift comes with five access-level modifiers: open, public, internal, fileprivate and private. The internal modifier leads to entities being available for use only within their defining module. It’s a default modifier but it starts getting interesting only once we split our codebase into modules.

In this article, we’ll see how to provide an ability to inject a framework’s data structure into the framework’s classes, while at the same time keeping its internals hidden.

Problem Statement

Most apps these days need some kind of local persistence of data. There are many choices: Core Data, Realm, SQLite with or without wrappers, etc. No matter what we choose, once our project exceeds 10K, 50K, or 100K lines of code we’ll inevitably start thinking about splitting it up into modules.

One of the modules we can consider extracting from the main target would contain the database access code. Let’s call it PersistenceKit, following Apple’s naming convention. We can implement the module either as a dynamic framework or a static library.

Let’s assume that PersistenceKit will contain many repositories, such as: ArticleRepository, UserRepository, etc that we’ll use to fetch and store data. A repository can be implemented as follows:

public struct Article {
    public let id: ArticleID
    public let title: String
    public let content: String
}

public class ArticleRepository {
    public func article(for id: ArticleID) -> Article? {
        // finds a row in the database and maps it to a struct
        //
        // missing implementation
    }

    // other methods...
}

To be able to perform an actual database access in implementations of repositories’ methods, we need some kind of reference to the database, be it:

Core Data: NSManagedObjectContext
Realm: Realm object
SQLite in C: sqlite3 pointer
GRDB.swift: DatabasePool

Being good engineers we strive to be, we want to:

Avoid keeping any of these references in a singleton or as a shared global variable.
Don’t let users of PersistenceKit know about its implementation details, i.e. we want the fact that we use NSManagedObjectContext or DatabasePool internally stay hidden.

Solution

I recently spent some time thinking about these two goals and came up with an approach that I’m happy with. It’s based on a mix of public and internal modifiers. Let’s introduce a new struct:

public struct Connection {
    let pool: DatabasePool
}

This way Connection struct is accessible outside of PersistenceKit but pool property isn’t. It’s not even possible to initialize this struct outside of PersistenceKit because its memberwise initializer is in this case internal.

Now, since users of our framework won’t be able to initialize Connection, we have to provide them with an instance. We can do that in an entry point to PersistenceKit:

public struct AppDatabase {
    public func setup(with path: URL) throws -> Connection {
        // performs the setup and returns a connection instance
    }
}

What’s left, is injecting Connection to our ArticleRepository, by changing its implementation to:

public class ArticleRepository {
    public func article(for id: ArticleID, connection: Connection) -> Article? {
        // we can access `pool` property here because it’s accessible in this module
        return connection.pool.read { (db) -> Article? in
            return Article.fetchOne(db, key: id)
        }
    }
}

Users can now set up PersistenceKit as follows:

class AppCoordinator {
    let connection: PersistenceKit.Connection
    ...

    init() throws {
        let database = AppDatabase()
        connection = try database.setup(with: path)
    }
}

Then, when they want to fetch something, they can simply pass connection to ArticleRepository’s methods:

let repository = ArticleRepository()
let article = repository.article(for: id, connection: connection)

Even if users of our framework wanted to access Connection.pool here directly, they couldn’t because it’s not accessible outside of PersistenceKit. We can be sure that database access code stays in PersistenceKit leading to a cleaner overall architecture.

Summary

Public types with internal properties are a powerful tool. We showed how to allow users to own and pass an object we need – as the framework’s authors – without exposing any of the internals. Are you aware of any other cool uses of public types with internal properties?

Why #if DEBUG Conditional Should Be Avoided in Library Code

Mon, 24 Sep 2018 14:55:00 +0200

Conditional Compilation along with Active Compilation Conditions is a way to alter the app’s behavior depending on the build configuration. For example for the code to compile only in the Debug configuration, we can do:

#if DEBUG
  performAdditionalChecks()
#endif

In this article, I’ll show why these kinds of conditional blocks shouldn’t be used directly in the source code of libraries distributed to other developers.

Problem

Around a week ago I noticed that my DeallocationChecker library didn’t catch a leaking view controller in a project I help with. At the time the main entry method in that library looked like this:

public func dch_checkDeallocation(afterDelay delay: TimeInterval = 2.0) {
  #if DEBUG
    // Real logic can be ignored for this article
    if isLeaked {
      assertionFailure()
    }
  #endif
}

After a short debugging session I noticed that even though the app is running in the Debug configuration, the code within this #if DEBUG block isn’t compiled at all! It confused me because that code was running fine just a few months ago.

Here’s a summary of the situation:

Active Compilation Conditions were set up correctly in the main project because the code in #if DEBUG blocks inside the project was being compiled and executed.
DeallocationChecker was included through Carthage.

So, there was something wrong with conditional compilation using DEBUG flag specifically in the project included through Carthage.

Carthage

In contrast to libraries imported through CocoaPods or as subprojects, Carthage operates in a two-step way:

First, when we add or update a dependency, Carthage builds it and produces a binary framework.
Then, going forward we use that prebuilt framework in the project.

This means, that when Carthage builds a framework, it doesn’t know whether the framework will be used in Debug, Release or any other configuration! So, it defaults to the Release configuration, causing that #if DEBUG block to not be compiled. We end up with our app’s code running in the Debug configuration, yet the library’s code is at the same time running in its Release configuration.

Technically speaking, we can instruct Carthage to use the Debug configuration but that complicates the workflow significantly. We would have to build both configurations and make sure to not ship a non-optimized Debug version to our users.

Also, the same rule applies to libraries distributed only in a binary form, e.g. Fabric.

Solution

A better approach to conditioning the execution depending on a configuration is to get the current configuration from a library’s user. It can be as simple as:

#if DEBUG
  let library = YourAwesomeLibrary(useDebugChecks: true)
#else
  let library = YourAwesomeLibrary(useDebugChecks: false)
#endif

This way, as a library’s author we stop being dependent on the exact way a user builds it. The intention gets explicit.

Summary

We learned how a subtle difference in a build process can break an otherwise sound code. What’s worse in this case, due to the nature of DeallocationChecker, which is invisible unless there’s a leak, the bug went unnoticed for some time.

As to why the conditional check stopped working for us just in recent months? We switched from CocoaPods to Carthage in the meantime. So, DeallocationChecker didn’t suddenly break, it just never worked correctly with Carthage.

Future-Proof Dependency Injection for Storyboard-Based View Controllers

Wed, 06 Dec 2017 16:05:00 +0100

One of the issues introduced by storyboards is that they make it impossible to pass dependencies to view controllers in initializers. I proposed an API modification in past that would allow for exactly that, but alas, it doesn’t seem to be high on the priority list for UIKit. I recently came up with a new approach leveraging code generation which I’m excited to show you today.

Initialization Recap

Since it’s not possible to use initializers to pass dependencies, in most cases developers rely on implicitly unwrapped optionals to indicate properties that should be set immediately after a view controller was created, e.g.:

final class ProfileViewController: UIViewController {
    var viewModel: ProfileViewModel!
}

Then at a call site, a view controller is initialized as follows:

let storyboard = UIStoryboard(name: "Profile", bundle: Bundle.main)
let viewController = storyboard.instantiateViewController(withIdentifier: "profileViewController") as! ProfileViewController
viewController.viewModel = viewModel

We can use a third-party tool like SwiftGen to get rid of strings, leaving us with:

let viewController = StoryboardScene.Profile.instantiateProfileViewController()
viewController.viewModel = viewModel

The Problem

While observing a lifetime of a few codebases relying on storyboards I noticed that at a time a new view controller is added everything is fine, no bugs here. The bugs start appearing when a view controller is modified and not all dependencies are set properly in each call site. In case of implicitly unwrapped optionals (IUO), that leads to runtime crashes.

We can leverage the Swift compiler to warn us about those issues if we make a few assumptions:

Properties defined as implicitly unwrapped optionals (excluding @IBOutlets) are dependencies that should be passed in from the outside.
We’re fine with code generation.
We’ll always use the same generated methods to initialize or set up (in case of segues) view controllers.

Knowing these assumptions it becomes clear (maybe only when you’re standing under a shower, though 😀) that all we need is an additional method that accepts all objects we need to initialize IUO properties. So for our ProfileViewController we should have:

extension ProfileViewController {
    static func makeFromStoryboard(
        viewModel: ProfileViewModel
    ) -> ProfileViewController {
        // magic here
    }
}

What’s important, if we add a new dependency to our view controller, e.g.:

final class ProfileViewController: UIViewController {
    var viewModel: ProfileViewModel!
    var analyticsManager: AnalyticsManager!
}

that method should be automatically updated to:

extension ProfileViewController {
    static func makeFromStoryboard(
        viewModel: ProfileViewModel,
        analyticsManager: AnalyticsManager
    ) -> ProfileViewController {
        // magic here
    }
}

We definitely don’t want to have to update this method manually each time we change a view controller. Code generation to the rescue!

Code Generation

SourceKit provides us with metadata about types in our Swift project. Based on that metadata we can generate additional code each time our project changes. There’s already a good tool doing exactly that – Sourcery – that we’ll use.

Let’s start by declaring a new protocol:

protocol StoryboardInitializable where Self: UIViewController {
    static func instantiateFromStoryboard() -> Self
}

and mark our ProfileViewController as conforming to it. instantiateFromStoryboard() is a method using instantiateViewController(withIdentifier:) under the hood:

extension ProfileViewController: StoryboardInitializable {
    static func instantiateFromStoryboard() -> ProfileViewController {
        let storyboard = UIStoryboard(name: "Profile", bundle: Bundle.main)
        return storyboard.instantiateViewController(withIdentifier: "profileViewController") as! ProfileViewController
    }
}

So, for this view controller we want the following methods to be generated:

// MARK: - ProfileViewController - StoryboardDependencyInjection
extension ProfileViewController {

  static func makeFromStoryboard(
    viewModel: ProfileViewModel
  ) -> ProfileViewController {
    let viewController = ProfileViewController.instantiateFromStoryboard()
    viewController.setDependencies(
      viewModel: viewModel
    )
    return viewController
  }

  func setDependencies(
    viewModel: ProfileViewModel
  ) {
    self.viewModel = viewModel
  }
}

I prepared a template for Sourcery which does exactly that (it's also on GitHub):

<% types.implementing.StoryboardInitializable.forEach(function(type){ -%>
// MARK: - <%= type.name -%> - StoryboardDependencyInjection
extension <%= type.name -%> {

<%
var allProperties = [];
var currentType = type;

while (currentType) {
  allProperties.push.apply(allProperties, currentType.storedVariables);
  currentType = currentType.supertype;
}
var properties = allProperties.filter(function(property) {
  return property.isImplicitlyUnwrappedOptional &&
  !property.attributes.IBOutlet &&
  ["internal", "public", "open"].indexOf(property.writeAccess) > -1
})
-%>
    static func makeFromStoryboard(
<% properties.forEach(function(property, index){ -%>
        <%= property.name -%>: <%= property.typeName.unwrappedTypeName -%><% if (index !== properties.length - 1) { %>,<% } %>
<% }) -%>
    ) -> <%= type.name -%> {
        let viewController = <%= type.name %>.instantiateFromStoryboard()
        viewController.setDependencies(
<% properties.forEach(function(property, index){ -%>
            <%= property.name -%>: <%= property.name -%><% if (index !== properties.length - 1) { %>,<% } %>
<% }) -%>
        )
        return viewController
    }

    func setDependencies(
<% properties.forEach(function(property, index){ -%>
        <%= property.name -%>: <%= property.typeName.unwrappedTypeName -%><% if (index !== properties.length - 1) { %>,<% } %>
<% }) -%>
    ) {
<% properties.forEach(function(property){ -%>
        self.<%= property.name %> = <%= property.name %>
<% }) -%>
    }
}

<% }) %>

Having these methods, each time we want to create ProfileViewController, we should do it this way:

let profileViewController = ProfileViewController.makeFromStoryboard(viewModel: viewModel)

If we add a new IUO property to ProfileViewController, the build will fail with an error because there will be a new parameter in makeFromStoryboard() method:

ProfileViewController.swift:19:98: Missing argument for parameter 'analyticsManager' in call

✨

Even Better Code Generation

What we have here is nice and will help us avoid bugs when we modify our view controllers in the future. We can go a step further, though.

If we use SwiftGen, it will generate a file with constants for us, e.g.:

enum StoryboardScene {
  enum Profile: String, StoryboardSceneType {
    static let storyboardName = "Profile"

    case profileViewControllerScene = "profileViewController"
    static func instantiateProfileViewController() -> ProfileViewController {
      guard let vc = StoryboardScene.Profile.profileViewControllerScene.viewController() as? ProfileViewController
      else {
        fatalError("ViewController 'profileViewController' is not of the expected class ProfileViewController.")
      }
      return vc
    }
  }
}

Instead of implementing instantiateFromStoryboard() in each view controller, we can let Sourcery analyze the contents of StoryboardScene enum and put a correct initialization in our generated file:

  static func makeFromStoryboard(
    viewModel: ProfileViewModel
  ) -> ProfileViewController {
    let viewController = StoryboardScene.Profile.instantiateProfileViewController()

    viewController.setDependencies(
      viewModel: viewModel
    )
    return viewController
  }

We got rid both of stringly-typed API and future-proofed our code. You can find this template on GitHub here. I think this is pretty cool!

Conclusion

Bridging external resources with code is hard. Code generation seems to be a temporarily approved way (see code generation for NSManagedObject subclasses or Codable protocol) of working around the design issues in iOS APIs. We showed how to use code generation to create a safer API for view controllers when using storyboards. You can find templates described in this article on GitHub.

Stop Xcode from constantly rebuilding your project because of @IBDesignable

Wed, 15 Nov 2017 15:30:00 +0100

If you use Interface Builder along with @IBDesignable attribute you may have noticed that Xcode sometimes builds your project even though you didn’t trigger a build. This is because it needs to compile views marked with @IBDesignable to be able to render them in Interface Builder. What's problematic is that these builds seem to occur a bit too often.

After closer inspection, I managed to notice what happens without having to disassemble Xcode. Xcode can be in two states:

Default state:
- You can edit all source files and save them, without Xcode triggering builds needed for IB rendering.
Once you open any XIB or storyboard file that references a view marked as @IBDesignable:
- Saving any source file (not even a view) associated with the same target will now cause an automatic rebuild of the project.
- What’s more, even after you’ve closed all Interface Builder tabs, the behavior will persist until you reopen the project. I think this is a bug (reported as rdar://35558659).

Thankfully, you can disable these automatic rebuilds by opening any file in Interface Builder, going to Editor menu and unchecking Automatically Refresh Views.

Deselect "Automatically Refresh Views" if Xcode rebuilds your project too often

After this change, you’ll now have to manually trigger an IB-specific build when you want to see the preview of your @IBDesignable views. I recommend setting up a key binding for Refresh All Views option if you use @IBDesignable often.

UPDATE: Tom Brodhurst-Hill mentions on Twitter that some of these issues got fixed/improved in Xcode 9.2 beta 2.

Optimizing Swift build times →

Wed, 08 Nov 2017 20:20:00 +0100

I spent some time recently trying to optimize build times of a project I contribute to. To my surprise, the knowledge needed to do that was scattered around many blog posts and tweets. So, I decided to do something about that by putting everything I knew and learned in a single document. It's available on GitHub here.

Hope you learn something new!

Surprising behavior of non-optional @NSManaged properties

Mon, 18 Sep 2017 16:20:00 +0200

Core Data is not a first-class citizen in the Swift world. Its inherently dynamic nature is lurking at us through an attribute created specifically for it: @NSManaged. Let me show you how this dynamic nature caught me off guard. I ended up with a property having a value I’d never assigned to it!

@NSManaged means dynamic

Imagine we’re starting a new project and need a way to represent a user. We’ve got:

class User {
    var name: String
}

which doesn’t yet compile in this form. We have to either 1) add an initial value to the name property, or 2) add an initializer that sets the value of that property. Another option is to store the user’s data with Core Data. If we just inherit from NSManagedObject and add @NSManaged attribute, the code will … compile cleanly:

class User: NSManagedObject {
    @NSManaged var name: String
}

This is Core Data’s way of saying I’ll take it from here. Getter and setter for name are created dynamically by NSManagedObject class. We can confirm that fact by using @NSManaged on a class not inheriting from NSManagedObject:

class FakeUser: NSObject {
    @NSManaged var name: String
}
let fakeUser = FakeUser()
fakeUser.name = "John"

leading to -[FakeUser setName:]: unrecognized selector sent to instance 0x608000009fb0 exception. With all the safety Swift brings, we can hit a runtime error with as little as 5 lines of code, as long as it uses Core Data.

Peculiar non-optionals

Let’s go back on track, though. We initialize a user, passing an NSManagedObjectContext instance to it:

let user = User(context: context)
user.name = "John"
print(user.name) // => "John"

So far, so good. We add a method responsible for creating users, to make sure a user always has a name and forget about this code:

func createUser(in context: NSManagedObjectContext, withName name: String) -> User {
    precondition(name != "")

    let user = User(context: context)
    user.name = "John"
    return user
}

One day though, we notice that in some parts of the app, the user’s name is equal to an empty string:

print(user.name) // => ""

That’s weird: precondition call makes sure that the name is initially never set to an empty string. It’s also never changed by other parts of the codebase!

A few minutes (or more honestly hours) of debugging later, we notice that the name is an empty string only on instances that were deleted from a context and the context was saved. (Deletion of managed objects is unrelated to ARC, so we have objects living in memory even though they are already treated as deleted.)

Because the name property is dynamic, we can’t check who changes its value to "". Let’s attack from a different angle by changing its type to optional:

@NSManaged var name: String?

In this case, after a User object was deleted and a context was saved, the value of name is correct: nil, not an empty string. Which leads us to the conclusion: returned value depends on the way the property is declared. ~~When it’s non-optional, NSManagedObject does what it can to never return nil, substituting a default value instead.~~

(UPDATE: Sep 20, 2017: As pointed out on Reddit replacement of nil with an empty string is actually caused by bridging from NSString to String.)

The same silent substitution happens for these types too:

numeric types use a value equal to 0
Data uses an empty Data instance

The substitution doesn’t happen for other types. In these three cases we get nils when the type system doesn’t expect them, often causing crashes somewhere inside stdlib:

Date
UUID
URI

It’s worth mentioning, that the substitution happens even when there’s no default value set for an attribute in the xcdatamodel file.

Relationships

This behavior spans relationships too. Let’s say we also have an Event class:

class Event: NSManagedObject {
    @NSManaged var timestamp: Date
    @NSManaged var user: User
}

and run this code:

let event = Event(context: context)
print(event.user.name)

Can you guess what happens? We didn’t set up the user relationship, so we should get either a nil or a fatal error, right? Well, we don’t. An empty string is printed in this case too!

This is completely counter-intuitive when compared to the normal Swift code: event.user is nil, yet event.user.name isn’t.

Possible solution

The safest approach is to make all @NSManaged properties optional but it’s not great as far as a codebase’s readability goes.

The specific approach I’m considering switching to is:

Optionals for @NSManaged properties which are optional in the regular Swift sense.
Implicitly unwrapped optionals for @NSManaged properties which should be nil only twice in their lives:
- before the first time their value is set
- after a managed object they belong to was deleted

Implicitly unwrapped optionals will make some call-sites look worse but they’ll allow us to fail early with the familiar:

fatal error: unexpectedly found nil while unwrapping an Optional value

instead of having an unexpected value propagating through the program.

Conclusion

In cases like this, it becomes clear that Core Data predates Swift. There are some really rough edges around it. If breaking changes were possible on the framework level, I’d propose for Core Data to:

trap on reads when a value behind a non-optional attribute/relationship is nil, at least in the debug configuration, or
don't allow @NSManaged properties to be declared as non-optional

Catching Leaky View Controllers Without Instruments

Mon, 26 Jun 2017 15:40:00 +0200

One of the well-known techniques for finding memory leaks caused by retain cycles is checking if all view controllers get deallocated when they’re not on screen anymore. This is a process that should be manually repeated before each release but it’s both unpleasant and error-prone. Wouldn’t it be cool if we could learn about UIViewController leaks earlier in the process, during the day-to-day development?

Turns out it’s possible thanks to two not-so-well-known UIViewController properties:

isBeingDismissed – it’s true when a presented modally view controller is being dismissed.
isMovingFromParentViewController – true when a view controller is being removed from a parent view controller. This includes removal from system containers such as popping a view controller from UINavigationController’s stack.

If one of these properties is true, we know that the view controller should get deallocated promptly. We don’t know how long exactly it will take a view controller to finish all its internal state cleaning and ARC to deallocate it, though. For the simplicity’s sake, let’s assume that it will be no more than 2 seconds.

Putting everything together we get:

extension UIViewController {
    public func dch_checkDeallocation(afterDelay delay: TimeInterval = 2.0) {
        let rootParentViewController = dch_rootParentViewController

        // We don’t check `isBeingDismissed` simply on this view controller because it’s common
        // to wrap a view controller in another view controller (e.g. in UINavigationController)
        // and present the wrapping view controller instead.
        if isMovingFromParentViewController || rootParentViewController.isBeingDismissed {
            let type = type(of: self)
            let disappearanceSource: String = isMovingFromParentViewController ? "removed from its parent" : "dismissed"

            DispatchQueue.main.asyncAfter(deadline: .now() + delay, execute: { [weak self] in
                assert(self == nil, "\(type) not deallocated after being \(disappearanceSource)")
            })
        }
    }

    private var dch_rootParentViewController: UIViewController {
        var root = self

        while let parent = root.parent {
            root = parent
        }

        return root
    }
}

The interesting bits happen in asyncAfter(deadline:execute:) call. First, we weakify self ([weak self]), so that it’s not retained by the delayed closure. Then, we assert that self (the UIViewController instance) is nil. It’s not nil only if we have a retain cycle keeping the view controller alive.

Now, all we need to do is call dch_checkDeallocation() from viewDidDisappear(_:) in all view controllers (except for those that we keep alive after they’re removed from their parents or dismissed):

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)

    dch_checkDeallocation()
}

If there’s a leak, we’ll see an assertion failure (only in -Onone builds):

At this point, we can simply open the (awesome) Memory Graph Debugger to investigate and fix the reason of a cycle.

I think it’s really cool how quickly we can learn about newly introduced retain cycles with this approach. I hope you’ll enjoy using it too! The production-ready code (with more comments and #if DEBUG check) is available on GitHub: DeallocationChecker.

Avoiding Third-Party UI Libraries

Wed, 31 May 2017 15:50:00 +0200

There’s been some discussion recently in the iOS community about pros and cons (OK, mostly cons) of using third-party dependencies. Many arguments I saw were rather generic — grouping all third-party libraries into one basket. As with most things, though, it’s not that simple. So, let’s try to focus on a single case today: should we avoid using third-party UI libraries?

Reasons to consider third-party libraries

There seem to be two main reasons developers consider using a third party library:

Lack of skill or knowledge. Let’s say, you’re working on a photo sharing app. You don’t start by rolling your own crypto.
Lack of time or interest to build something. Unless you have an unlimited amount of time (which no human has yet) you have to prioritize.

Most UI libraries (not all!) tend to fall into the second category. This stuff is no rocket science, but it takes time to build it right.

What to “outsource”

So, how do we actually decide what code to write ourselves and what to delegate to a third-party component? The famous Joel’s advice applies really well here:

If it’s a core business function — do it yourself, no matter what.

A (possibly hard) truth is that most iOS apps are skewed towards being frontend- rather than backend-heavy. The look matters. It follows that we should consider doing as much UI development as possible in-house. One could argue that it’s just one person’s opinion, so let’s go through specific reasons you should rethink your usage of third-party UI libraries.

Problems with UI libraries

Generic vs. specific

There are pretty much two types of controls/views:

Generic, allowing you to use them in many different contexts not even thought of by their creators, e.g. UICollectionView from UIKit.
Specific, designed for a single use-case, e.g. UIPickerView.

Most third-party libraries tend to fall into the second category. What’s more, they’re often extracted from an existing codebase for which they were optimized.

As an example, that cool-looking pull to refresh control you saw last month? Yeah, it probably won’t fit your app’s design or use cases, like view controller containment or contentInset value being modified.

Inheritance as a way to personalize

As far as OOP goes, there’s an industry-wide move from subclassing to composition. Make sure you’re not going against the flow when choosing a library. In most cases you let someone else do the composition for you, leaving you with only subclassing or direct code modification at your disposal.

(Delegate pattern is one of the approaches to composition.)

Too customized look

This may seem counterintuitive but the less visible UI there is in a library, the better. The problem with highly customized controls/views is that it’s not possible to specify their requirements in a way that will fit all use cases.

If there’s a lot of custom UI, you may not be able to contribute back to the upstream, because your ideas about the look or feel may be different than those of the maintainer. You’ll have to either maintain a fork or use some ugly hacks on the app’s side just to remove that one shadow.

On the other end of the spectrum are libraries that operate on the UI level but don’t provide any or almost any look by themselves, think SDWebImage or my SloppySwiper. These have a higher chance of not needing to be modified just to fit into your project.

Unknown early assumptions

Many teams do code reviews of their internal code but may be taking third-party source code’s quality for granted. It’s worth spending a bit of time just browsing a library’s code. You may end up being surprised to see some red flags, e.g. swizzling used where it’s not needed.

Try to get a glimpse of the architecture. Will you be able to adjust the library to your future needs or will you have to rewrite it after your MVP ships?

You should assess the general health of the project too. How many commits, pull requests and issues have there been lately? Are there any unit or UI tests? Ignore the GitHub stars, though – they’re mostly meaningless.

Idea > code?

I like open-source because it allows me to see how other people think and design their solutions. Often learning the idea is more beneficial than obtaining the resulting code itself. If a library touches UI and is small, it’s often better to get inspired by its code and develop a component yourself to suit your needs perfectly.

Can’t hide it

Because of the way UIKit is designed you most probably won’t be able to hide the third-party UI library, e.g. behind an adapter. A library will intertwine with your UI code becoming a de-facto first-class citizen of your project.

Future time cost

UIKit changes with each iOS release. Things will break. Your third-party dependency won’t be as maintenance-free as you may expect.

Conclusion

As it’s often the case in programming, it’s hard to provide general rules. We have to consider every chunk of code we add to our codebase on a piece-by-piece basis. From my personal experience, most uses of third-party UI code boil down to exchanging smaller flexibility for some time gain.

We leverage ready-made code to ship our current release faster. Sooner or later, though, we hit the limits of the library and stand before a hard decision: what to do next?

Introducing IBAnalyzer

Tue, 31 Jan 2017 15:00:00 +0100

I'm happy to announce the release of my new tool called IBAnalyzer. Its aim is to allow you to catch common xib and storyboard-related issues without running an app or writing unit tests.

With IBAnalyzer, you're currently able to:

Find unimplemented outlets & actions in classes. Avoid crashes caused by exceptions, like a dreadful:

*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '
[<Sample.TwitterViewController 0x7fa84630a370> setValue:forUndefinedKey:]: this
 class is not key value coding-compliant for the key twitterImageView.'

Find @IBOutlets and @IBActions defined in code but not connected to from nibs. No more:

and

All that thanks to its output, an example of which you can see below:

$ ./ibanalyzer ~/code/Sample/

TwitterViewController doesn't implement a required @IBAction named: loginButtonPressed:
TwitterViewController doesn't implement a required @IBOutlet named: twitterImageView
LoginViewController contains unused @IBAction named: onePasswordButtonTapped:
MessageCell contains unused @IBOutlet named: unreadIndicatorView
MessagesViewController contains unused @IBAction named: infoButtonPressed

IBAnalyzer is in an early stage of life but I hope it will continue to get new types of warnings and become a useful tool for developers relying on Interface Builder. You should give it a go. Its source is available on GitHub.

Imagining Dependency Injection via Initializer with Storyboards

Wed, 14 Dec 2016 16:15:00 +0100

Storyboards, both their good and bad parts, are something I already analyzed in the past. To recap, they just don’t feel like the first class citizen in the Swift world. Third party tools can help but only with some of the issues, e.g. SwiftGen allows us to minimize the usage of “stringly typed” APIs.

At the end of the day though storyboards can be completely fixed only by Apple. So, let’s see how Apple could improve the biggest pain point there is – the lack of dependency injection via initializer.

Why Dependency Injection via Initializer Is Important

Dependency Injection (or passing stuff between objects) is a commonly used design pattern. There are two popular ways of injecting dependencies in Swift:

Initializer Injection – dependencies are passed to an initializer. Properties using them can be declared as non-optional constants:
- let dependency: SomeType
Setter Injection – dependencies are provided after the initialization time. Properties storing them have to be variables, either optional or with an implicitly unwrapped optional attribute:
- var dependency: SomeType? or
- var dependency: SomeType!

The biggest advantage of the initializer injection is that it’s possible to confirm at the compile-time that all dependencies are set up properly. No need to run the app or tests to check that all the assumptions are met. This turns out to be a huge benefit in a large codebase!

All is good except that we can’t use initializer injection with storyboards. A view controller with a view defined in a storyboard is initialized this way:

let storyboard = UIStoryboard(name: "Main", bundle: nil)
let viewController = storyboard.instantiateViewController(withIdentifier: "detailsViewController")
present(viewController, animated: true, completion: nil)

We don’t call a view controller’s initializer directly, its instance is created for us by a UIStoryboard object. We can only pass data to it after the initialization time.

Idea

This problem has been bugging me for a long time. I recently came up to the conclusion that it can be divided into two cases:

View controllers that are the destination of at least one segue
View controllers being initialized only through instantiateViewController(withIdentifier:) and instantiateInitialViewController()

There’s not much that can be done about the first case. View controllers can be initialized and presented without any of our code being called, as it’s not mandatory to do anything in or even implement at all prepare(for segue: UIStoryboardSegue, sender: Any?) method.

So, let’s focus on the second case – the view controller initialization from code. What happens, in that case, is UIKit simply calling init(coder:) on our view controller passing an NSCoder instance to it. Seems like a dead end too. We can’t pass any instances along that path anyway, right?

Stack trace of the initialization triggered by instantiateViewController(withIdentifier:)

Well, what if we could reverse things a bit. Instead of letting a UIStoryboard instance initialize a view controller for us, we could get an NSCoder instance from it. So, we would have something like:

// Hypothetical method, not present in UIKit. `decoder` has the type `NSCoder`.
let decoder = storyboard.decoder(forViewControllerIdentifier: "detailsViewController")

Then, in our view controller we could have a new initializer:


class DetailsViewController: UIViewController {

    let dependency: SomeType

    init?(coder aDecoder: NSCoder, dependency: SomeType) {
        self.dependency = dependency
        super.init(coder: aDecoder)
    }
}

and initialize our view controller by calling that initializer directly (!)

let detailsViewController = DetailsViewController(coder: decoder, dependency: dependency)

That one initializer is not enough to satisfy the compiler, though. We would have to implement init(coder:) too. If we simply called super.init(coder: aDecoder) from within it, the compiler would now note that:

Property 'self.dependency' not initialized at super.init call

If we were sure that our view controller will not be used with segues, we could silence the error by putting fatalError() in that initializer. Otherwise, we would have to set the value of the dependency property without it being passed from the outside. That’s not always possible, though.

If we were to tie the code with storyboards closer, we could introduce a protocol for view controllers that can’t be initialized through segues, e.g. NotSegueInitializable.

Conclusion

We presented a simple addition to UIStoryboard class that could improve an important downside of that API. We weren’t able to confirm – not having access to UIKit’s source code – that this addition is indeed as simple as it seems.

With that API and with avoidance of segues we would have storyboards that don’t exercise most of the issues pointed out in “Storyboards and Their (Better) Alternatives.” Let’s hope that this is something Apple is currently working on and that we’ll see better APIs for storyboards soon.