Preserving a minimum tappable area for UIButton

One of the Apple Human Interface Guideline says:

Provide ample touch targets for interactive elements. Try to maintain a minimum tappable area of 44pt x 44pt for all controls.

(https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/)

But sometimes, your graphic designer only gives you a tiny image and:

  1. you don’t want to deal with the button insets in your layout
  2. you still want your users to have a reasonable hit zone

The solution is to override the func hitTest(_:, with:) -> UIView? method of the UIButton, so that it returns said button even if the tap if slightly out of bounds (as long as this matches the 44×44 points rule):

import UIKit
class MinimumTouchAreaButton: UIButton {
override func hitTest(_ point: CGPoint, with _: UIEvent?) -> UIView? {
guard !isHidden, isUserInteractionEnabled, alpha > 0 else {
return nil
}
let expandedBounds = bounds.insetBy(dx: min(bounds.width – 44.0, 0), dy: min(bounds.height – 44.0, 0))
return expandedBounds.contains(point) ? self : nil
}
}

Only assign new values when the right operand is not nil

It’s sometimes useful to create custom operators to avoid boilerplate code. For example in the following code, we check if a variable is not nil before assigning it to our object:

if let basedOn = basedOn {
    story.basedOn = basedOn
}

It would be much better if we could simplify and have this instead:

story.basedOn ?= basedOn

To do that in Swift, we can create an “Optional Assignment” custom operator, as short as ?= here, with a few lines of code:

import Foundation
precedencegroup OptionalAssignment {
associativity: right
}
infix operator ?=: OptionalAssignment
public func ?= <T>(variable: inout T, value: T?) {
if let unwrapped = unwrap(any: value) ?? nil {
variable = unwrapped
}
}
public func unwrap<T: Any>(any: T) -> T? {
let mirror = Mirror(reflecting: any)
guard mirror.displayStyle == .optional else { return any }
guard let child = mirror.children.first else { return nil }
return unwrap(any: child.value) as? T
}

Reveal in Project Navigator shortcut

Xcode 11 buried even more this option allowing to reveal the current file in the Project Navigator:

Right Click / Navigate / Reveal in Project Navigator

Good news, there is also a keyboard shortcut for this action: ⇧ + ⌘ + J

Registering and dequeuing cells in a collection view

When using custom cells in UICollectionViews, you usually have to go through two things:

  • registering the cell: usually in the viewDidLoad method, you have to let the collection view know how to create a cell of a given type
  • dequeue the cell: usually in the collectionView(_:, cellForItemAt:) method, you ask the collection view to dequeue a cell of a given type so that you can configure it and return it

What’s wrong with that?

  • there is a lot of boilerplate code here
  • uncertainty around cell identifiers
  • when dequeuing, you always have to deal with this optional even though there isn’t much you can do if the cell isn’t there

Making registration easier

To make cell registration easier, each cell has to provide two things:

  • a cell identifier is a string identifying the cell
  • a cell nib is an object of type UINib used by the collection view to instantiate the cell

I created a protocol that will make more sense later on:

protocol UICollectionViewRegisterable {
    static var cellIdentifier: String { get }
    static var cellNib: UINib { get }
}

So the cell just needs to conform to this protocol:

extension HomeCell: UICollectionViewRegisterable {
    static var cellIdentifier: String {
        return "HomeCellID"
    }

    static var cellNib: UINib {
        return UINib(nibName: "HomeCell", bundle: nil)
    }
}

Then we have to register the cell in the collection view, here an extension on UICollectionView will help us get rid of the optional and enforce type:

extension UICollectionView {
    func register(type: UICollectionViewRegisterable.Type) {
        register(type.cellNib, forCellWithReuseIdentifier: type.cellIdentifier)
    }

    func dequeueCell<CellType: UICollectionViewRegisterable>(at indexPath: IndexPath) -> CellType {
        guard let cell = dequeueReusableCell(withReuseIdentifier: CellType.cellIdentifier, for: indexPath) as? CellType else {
            fatalError("UICollectionView should dequeue a cell of type \(CellType.self)")
        }
        return cell
    }
}

Registering the cell becomes really easy:

override func viewDidLoad() {
    super.viewDidLoad()

    // Configure collection view
    collectionView.register(type: HomeCell.self)
}

To dequeue the cell, the extension is using generics, so we can’t let type inference do the work here, and have to specify the type of the cell for the code to compile:

func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
    let cell: HomeCell = collectionView.dequeueCell(at: indexPath)
    // TODO: configure cell
    return cell
}

That’s it! Here is the final code:

import UIKit
protocol UICollectionViewRegisterable {
static var cellIdentifier: String { get }
static var cellNib: UINib { get }
}
extension UICollectionView {
func register(type: UICollectionViewRegisterable.Type) {
register(type.cellNib, forCellWithReuseIdentifier: type.cellIdentifier)
}
func dequeueCell<CellType: UICollectionViewRegisterable>(at indexPath: IndexPath) -> CellType {
guard let cell = dequeueReusableCell(withReuseIdentifier: CellType.cellIdentifier, for: indexPath) as? CellType else {
fatalError("UICollectionView should dequeue a cell of type \(CellType.self)")
}
return cell
}
}

SwiftLint & SwiftFormat

These two tools are now part of my tool belt when creating an iOS project, I don’t see how I can go back working without, and I recommend them for any type of project.

SwiftLint

Automatically enforce Swift style, conventions and best practices. It’s a good idea to just install it when creating a new project and treat all warnings and errors as they come. Everything can be configured or disabled using a .swiftlint.yml file at the root of the project.

Repository: https://github.com/realm/SwiftLint

SwiftFormat

You have a preferred style for formatting your code, your teammates eventually have a different preferred style when formatting their code, and you find yourself spending too much time arguing about the format and/or asking others to update their code during reviews over format issues?

It’s helpful to agree on a common coding style with your team, and it’s even better if you can enforce it. SwiftFormat to the rescue, it enforces the coding style by automatically formatting the code.

I personally installed it for it to run during each build, the overhead is small and I don’t have to think about formatting anymore.

Repository: https://github.com/nicklockwood/SwiftFormat