Re-binding self: the debugger's break(ing) point

For the Objective-C veterans in the audience, the strong-self-weak-self dance is a practice mastered early on and one that is used very frequently. There are a lot of different incantations, but the most basic one goes something like this:

1
2
3
4
__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    [weakSelf doSomething];
});

Then, if you needed a strong reference to self again inside the block, you'd change it to this:

1
2
3
4
5
__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    typeof(weakSelf) strongSelf = weakSelf;
    [strongSelf.someOtherObject doSomethingWith:strongSelf];
});

Fortunately, this was much easier on day 1 of Swift when using the [weak self] directive:

1
2
3
4
5
DispatchQueue.main.async { [weak self] in
    if let strongSelf = self {
        strongSelf.someOtherObject.doSomething(with: strongSelf)
    }
}

self is now weak inside the closure, making it an optional. Unwrapping it into strongSelf makes it a non-optional while still avoiding a retain cycle. It doesn't feel very Swifty, but it's not terrible.

More recently, it's become known that Swift supports re-binding self if you wrap it in backticks. That makes for an arguably much nicer syntax:

1
2
3
4
DispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }
    self.someOtherObject.doSomething(with: self)
}

This was long considered, and confirmed to be, a hack that worked due to a bug in the compiler, but since it worked and there weren't plans to remove it, people (including us at Lyft) started treating it as a feature.

However, there is one big caveat: the debugger is entirely hosed for anything you do in that closure. Ever seen an error like this in your Xcode console?

1
2
3
error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
        ~~~~^~~~~~~~~~~~~~~~~~~~

That's because self was re-bound. This is easy to reproduce: create a new Xcode project and add the following snippet to viewDidLoad():

1
2
3
4
5
6
DispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }

    let description = self.description
    print(description) // set a breakpoint here
}

When the breakpoint hits, execute (lldb) po description and you'll see the error from above. Note that you're not even using self - merely re-binding it makes the debugger entirely useless inside that scope.

People with way more knowledge of LLDB than I do can explain this in more detail (and have), but the gist is that the debugger doesn't like self's type changing. At the beginning of the closure scope, the debugging context assumes that self's type is Optional, but it is then re-bound to a non-optional, which the debugger doesn't know how to handle. It's actually pretty surprising the compiler supports changing a variable's type at all.

Because of this problem, at Lyft we have decided to eliminate this pattern entirely in our codebases, and instead re-bind self to a variable named this.

If you do continue to use this pattern, note that in a discussion on the Swift forums many people agreed that re-binding self should be supported by the language without the need for backticks. The pull request was merged shortly after and with the release of Swift 4.2 in the fall, you'll be able to use guard let self = self else { return } (at the cost of losing debugging capabilities!)

Using Interface Builder at Lyft

Last week people realized that Xcode 8.3 by default uses storyboards in new projects without a checkbox to turn this off. This of course sparked the Interface Builder vs. programmatic UI discussion again, so I wanted to give some insight in our experience using Interface Builder in building the Lyft app. This is not intended as hard "you should also use Interface Builder" advice, but rather to show that IB can work at a larger scale.

First, some stats about the Lyft app:

With the rewrite of our app we moved to using IB for about 95% of our UI.

The #1 complaint about using Interface Builder for a project with more than 1 developer is that it's impossible to resolve merge conflicts. We never have this problem. Everybody on the team can attest that they have never run into major conflicts they couldn't reasonably resolve.

With that concern out of the way, what about some of the other common criticisms Interface Builder regularly gets?

Improving the workflow

Out of the box, IB has a number of shortcomings that could make working with it more painful than it needs to be. For example, referencing IB objects from code still can only be done with string identifiers. There is also no easy way to embed custom views (designed in IB) in other custom views.

Over time we have improved the workflow for our developers to mitigate some of these shortcomings, either by writing some tools or by writing a little bit of code that can be used project-wide.

storyboarder script

To solve the issue of stringly-typed view controller identifiers, we wrote a script that, just before compiling the app, generates a struct with static properties that exposes all view controllers from the app in a strongly-typed manner. This means that now we can instantiate a view controller in code like this:

1
let viewController = Onboarding.SignUp.instantiate()

Not only is viewController now guaranteed to be there at runtime (if something is wrong in the setup of IB the code won't even compile), but it's also recognized as a SignUpViewController and not a generic UIViewController.

Strongly-typed segues

All our view controllers have a base view controller named ViewController. This base controller implements prepare(for:sender:) like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
open override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    guard let identifier = segue.identifier else {
        return
    }

    let segueName = identifier.firstLetterUpperString()
    let selector = Selector("prepareFor\(segueName):sender:")
    if self.responds(to: selector) {
        self.perform(selector, with: segue.destination, with: sender)
    }
}

This means that a view controller that has a segue to TermsOfServiceViewController can now do this:

1
2
3
4
@objc
private func prepareForTermsOfService(_ viewController: TermsOfServiceViewController, sender: Any?) {
    viewController.onTermsAccepted = { [weak self] self?.proceed() }
}

We no longer have to implement prepareForSegue and then switch on the segue's identifier or destination controller, but we can implement a separate method for every segue from this view controller instead which makes the code much more readable.

NibView

We wrote a NibView class to make it more convenient to embed custom views in other views from IB. We marked this class with @IBDesignable so that it knows to render itself in IB. All we have to do is drag out a regular UIView from the object library and change its class. If there is a XIB with the same name as the class, NibView will automatically instantiate it and render it in the canvas at design time and on screen at runtime.

Every standalone view we design in IB (which effectively means every view in our app) inherits from NibView so we can have an "unlimited" number of nested views show up and see the final result.

Basic @IBDesignables

Since a lot of our views have corner radii and borders, we have created this UIView extension:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
public extension UIView {
    @IBInspectable public var cornerRadius: CGFloat {
        get { return self.layer.cornerRadius }
        set { self.layer.cornerRadius = newValue }
    }

    @IBInspectable public var borderWidth: CGFloat {
        get { return self.layer.borderWidth }
        set { self.layer.borderWidth = newValue }
    }

    @IBInspectable public var borderColor: UIColor {
        get { return UIColor(cgColor: self.layer.borderColor!) }
        set { self.layer.borderColor = newValue.cgColor }
    }
}

This lets us easily set these properties on any view (including the ones from UIKit) from Interface Builder.

Linter

We wrote a linter to make sure views are not misplaced, have accessibility labels, trait variations are disabled (since we only officially support portrait mode on iPhone), etc.

ibunfuck

A bug impacting developers that use Interface Builder on both Retina and non-Retina screens (which at Lyft is every developer) has caused us enough grief to write ibunfuck - a tool to remove unwanted changes from IB files.

Color palette

We created a custom color palette with the commonly used colors in our app so it's easy to select these colors when building a new UI. The color names in the palette follow the same names designers use when they give us new designs, so it's easy to refer to and use without having to copy RGB or hex values.

Our approach

In addition to these tools and project-level improvements, we have a number of "rules" around our use of IB to keep things sane:

Of course, even with these improvements everything is not peaches and cream. There are definitely still problems. New versions of Xcode often change the XML representation which leads to a noisy diff. Some properties can simply not be set in IB meaning we're forced to break our "do everything in IB" rule. Interface Builder has bugs we can't always work around.

However, with our improved infrastructure and the points from above, we are happy with how IB works for us. We don't have to write tons of Auto Layout code (which would be incredibly painful due to the nature of our UIs), get a visual representation of how a view looks without having to run the app after every minor change, and maybe one day we can get our designers make changes to our UI without developers' help.

Silencing NSLog

When your app has a lot of third-party dependencies, what often happens is that those libraries log a bunch of things to the Xcode console to help their own debugging. Unfortunately, a lot of these logs are useful only to the developers of the library, but not the developers of apps that integrate the library. For example, they log things like <SomeLibrary> (version 1.2.3) initialized, or <SomeLibrary> started <primary functionality>, sometimes with a long list of parameters or input sources that are irrelevant to you.

Finding your own log statements in a jungle of other logs can then be very difficult and adds to the frustration of not being able to work the debugger as you would like to.

If a library is open source you can suggest a change by removing the log or otherwise make it less obtrusive. However, if your change gets accepted at all, that doesn't solve the immediate problem of being able to debug your own code using the console.

Meet _NSSetLogCStringFunction(). This C function has been around in Foundation for a long time, and while there is some documentation on it, it's still a private method. However, that doesn't mean you can't use it in debug mode when your logs are the most valuable!

In short, this function lets you set a function pointer that can log C strings, which NSLog then uses instead of the normal implementation. You can do this in two ways.

The first one is by adding this to your Objective-C bridging header:

1
2
3
#if DEBUG
extern void _NSSetLogCStringFunction(void(*)(const char*, unsigned, BOOL));
#endif

and then use it like this:

1
2
3
4
5
6
func disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif

If you want to stick to pure Swift, you can do so by adding this to your code somewhere:

1
2
@_silgen_name("_NSSetLogCStringFunction")
func setNSLogFunction(_: @convention(c) (UnsafePointer<Int8>, UInt32, ObjCBool) -> Void)

and then use it like this:

1
2
3
4
5
6
7
func disableNSLog() {
#if DEBUG
    setNSLogFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif
}

Obviously, you can do anything you want inside the closure, including writing to a file, annotating the message with a date/time, passing it to your custom logging library, etc.

One downside of this is that Apple's frameworks use NSLog extensively as well, so in the above case of completely disabling logging, helpful messages get lost as well. You won't be able to use NSLog yourself either anymore, so I suggest you use print() or a custom logging framework that's not NSLog based.

If you're not afraid of doing (more) horrible things in your codebase, you can avoid losing Apple frameworks' messages by parsing the stack trace and looking at the framework that called this function and see if it's something you want to let through:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
func disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // message is of type UnsafePointer<Int8> so first see if we can get a
        // normal String from that. Safety first!

        guard let message = String.fromCString(message) else {
            return
        }

        let callStack = NSThread.callStackSymbols()
        let sourceString = callStack[6]
        let separatorSet = NSCharacterSet(charactersInString: " -[]+?.,")
        let stackFrame = sourceString.componentsSeparatedByCharactersInSet(separatorSet)
        let frameworkName = stackFrame[3]

        if frameworkName == "UIKit" || frameworkName == "Foundation" {
            MyCustomLogger.log(message)
        }
    }
#endif
}

This discards all logs, except if they're coming from UIKit or Foundation. The stack trace parsing is by no means safe (its format could change, for example), but since it's wrapped in #if DEBUG directives it won't mess with anything in the App Store build.

Note that static libraries are part of your main app's target, which means you have to filter out logs from your own target to hide those.

You could even go a bit farther and check the message for keywords you like or don't like and make a decision on whether you want to log or not. Keep in mind, though, that any work you do here needs to be fast as you don't always know just how much is being logged.

Outlets: strong! or weak?

There are a lot of styles out there when it comes to using Interface Builder outlets in Swift. Even Apple's documentation and sample code isn't always consistent. The most common one, the one Apple uses in its sample code, follows this pattern:

@IBOutlet private weak var someLabel: UILabel!

Let's break this down by keyword:

While at first this seems like a solid approach, at Lyft we quickly realized we weren't fans of this one-size-fits-all way of defining outlets. Instead, the behavior and consequences of the different elements should define the outlet's exact syntax, just like any other variable.

For example, if there is a code path that removes an outlet from its superview, or the outlet is (intentionally) not hooked up in the storyboard, it needs to be an optional because the outlet is not guaranteed to be there when it's accessed.

@IBOutlet private var someLabel: UILabel?

If there is no code path that re-adds the outlet to the view hierarchy, it would also be good to make it weak to not hold on to it unnecessarily when it gets removed:

@IBOutlet private weak var someLabel: UILabel?

This ensures that if the label is removed from the superview, it's not being kept in memory by the strong reference in the view controller. In the most common case, where there is an outlet that will always be there, a strong, implicitly unwrapped optional is appropriate:

@IBOutlet private var someLabel: UILabel!

The outlet isn't weak in case the code ever changes so that there is a code path that removes the view from the view hierarchy but you forget to update the optionality of the property. The object will stay in memory and using it won't crash your app.

These examples all follow 3 simple rules:

  1. ! needs a guarantee that the view exists, so always use strong to provide that guarantee
  2. If it's possible the view isn't part of the view hierarchy, use ? and appropriate optional-handling (optional binding/chaining) for safety
  3. If you don't need a view anymore after removing it from the view hierarchy, use weak so it gets removed from memory.

Applying these three rules means you properly use the optional semantics. After all, using ! for a view that may not exist is no different than defining any other property as an implicitly unwrapped optional that may not exist.

@objc class prefixes fixed in Xcode 7 beta 4

Back in December I wrote about what I thought was a bug in the Swift compiler that would expose the wrong class name for a Swift class in Objective-C. I then later found out everything worked as intended and I had just misunderstood what @objc() exactly did. Apparently it was never supposed to modify the class name at compile time, but only at runtime.

I'm sure changing the class name just at runtime has its uses, but in my opinion, this would be most helpful if it also affected the compile time name of Objective-C classes. It allows you to namespace your classes in Objective-C using your three-letter prefix, without needing that prefix in Swift because you could namespace by way of modules.

And fortunately, in Xcode 7 beta 4, they have actually modified the @objc() notation so that it does do this. For example, if I have a Swift module that I want others to be able to use in their Objective-C codebase, I could write a class like this:

1
2
3
4
@objc(SDCMyClass)
class MyClass: NSObject {
    // ...
}

And in MyProject-Swift.h the Objective-C class is defined as:

1
2
3
4
SWIFT_CLASS_NAMED("MyClass")
@interface SDCMyClass : NSObject
- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
@end

In Swift I can simply use the class as MyClass, but in Objective-C its name is SDCMyClass, which ensures it doesn't collide with other classes named MyClass. Needless to say, I'm very happy they changed this behavior, it makes much more sense now.