Srđan on iOS & Swift

Why I never subclass UITableViewCell or UICollectionViewCell

Sun, 30 Mar 2025 00:00:00 +0100

Imagine we’re building a mobile shopping app and we are tasked with implementing the products list screen. We’ve got a design specification and we are ready to go.

The obvious implementation

Most iOS engineers will immediately grab a UITableView, subclass a UITableViewCell, and start implementing the specified layout.

struct ProductViewModel {
    let title: String
    let price: String
    let image: UIImage
}

class ProductView: UITableViewCell {
    private let productImageView: UIImageView = {
        let imageView = UIImageView()
        imageView.translatesAutoresizingMaskIntoConstraints = false
        return imageView
    }()

    private let titleLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }()

    private let priceLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }()

    override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
        super.init(style: style, reuseIdentifier: reuseIdentifier)

        setupViews()
    }

    private func setupViews() {
        let labelsStack = UIStackView(arrangedSubviews: [
            titleLabel,
            priceLabel
        ])
        labelsStack.axis = .vertical
        labelsStack.translatesAutoresizingMaskIntoConstraints = false

        let mainStack = UIStackView(arrangedSubviews: [
            productImageView,
            labelsStack
        ])
        mainStack.axis = .horizontal
        mainStack.translatesAutoresizingMaskIntoConstraints = false

        contentView.addSubview(mainStack)

        NSLayoutConstraint.activate([
            productImageView.widthAnchor.constraint(equalToConstant: 40),
            productImageView.heightAnchor.constraint(equalToConstant: 40),

            mainStack.topAnchor.constraint(equalTo: contentView.topAnchor, constant: 16),
            mainStack.leadingAnchor.constraint(equalTo: contentView.leadingAnchor, constant: 16),
            mainStack.trailingAnchor.constraint(equalTo: contentView.trailingAnchor, constant: -16),
            mainStack.bottomAnchor.constraint(equalTo: contentView.bottomAnchor, constant: -16)
        ])
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func configure(with product: ProductViewModel) {
        titleLabel.text = product.title
        priceLabel.text = product.price
        productImageView.image = product.image
    }
}

// some UITableView intialization and setup code, skipped for brevity
// ...

// register
tableView.register(ProductTableViewCell.self, forCellReuseIdentifier: "ProductTableViewCell")

// dequeue
let cell = tableView.dequeueReusableCell(withIdentifier: "ProductTableViewCell", for: indexPath) as? ProductTableViewCell
cell?.configure(with: productViewModel)

This probably feels familiar. After all, this is how Apple taught us to build list layouts.

A new requirement

Everything looks good — until our designer pings us again after a few days and says:

“You know these product items that we have on the products list screen? How hard would it be to show them in a horizontally scrollable layout on the product categories screen? Please find the design specification attached:

A new implementation with more flexibility

At this point, we are thinking to ourselves we should have gone with the UICollectionView in the first place. Yes, it’s a bit more setup to make it work, but UICollectionView offers more flexibility with custom layouts.

So, we reimplement the same layout with a UICollectionView and a UICollectionViewCell.

class ProductCollectionViewCell: UICollectionViewCell {
    // all the same properties
    // ...

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLayout()
    }

    private func setupLayout() {
      // all the same layout
      // ...
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func configure(with product: ProductViewModel) {
      // same configuration logic
      // ...
    }
}

// some UICollectionView initialization, setup, and layout configuration code, skipped for brevity
// ...

// register
collectionView.register(ProductCollectionViewCell.self, forCellWithReuseIdentifier: "ProductCollectionViewCell")

// dequeue
let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "ProductCollectionViewCell", for: indexPath) as? ProductCollectionViewCell
cell?.configure(with: product)

At this point, we are quite happy because the designer can’t surprise us anymore, and we can support any layout they can come up with.

A curveball - an unexpected requirement

Well, the designer does not disappoint and comes back with another request.

“We also need these product items inside an upsell popup. There are just two static product items in the popup. No scrolling.”

We have all the flexibility in the world now, but we also need a lot of boilerplate to spin up a full UICollectionView, just to render two static product items.

Ugh.

Maybe we could just stuff two UICollectionViewCells into a UIStackView. No one will know, right?

Naah, we can’t risk anyone seeing that with our name attached to it in the Git history.

Here is what we are going to do instead.

Unlocking additional flexibility

We will build our product item in a regular UIView:

class ProductView: UIView {
    // all the same properties
    // ...

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLayout()
    }

    private func setupLayout() {
      // all the same layout
      // ...
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func configure(with product: ProductViewModel) {
      // same configuration logic
      // ...
    }
}

Now we can use ProductView in any context and layout we need.

Vertical list? No problem. We’ll embed it into a UITableViewCell:

class ProductTableViewCell: UITableViewCell {
    let productView = ProductView()

    override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
        super.init(style: style, reuseIdentifier: reuseIdentifier)

        contentView.addSubview(productView)

        productView.translatesAutoresizingMaskIntoConstraints = false

        NSLayoutConstraint.activate([
            productView.topAnchor.constraint(equalTo: contentView.topAnchor),
            productView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
            productView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
            productView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor)
        ])
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

// Register
tableView.register(ProductTableViewCell.self, forCellReuseIdentifier: "ProductTableViewCell")

// Dequeue
let cell = tableView.dequeueReusableCell(withIdentifier: "ProductTableViewCell", for: indexPath) as? ProductTableViewCell
cell?.productView.configure(with: productViewModel)

Horizontal list? No sweat, we’ll embed it into a UICollectionViewCell:

class ProductCollectionViewCell: UICollectionViewCell {
    let productView = ProductView()

    override init(frame: CGRect) {
        super.init(frame: frame)

        contentView.addSubview(productView)

        productView.translatesAutoresizingMaskIntoConstraints = false

        NSLayoutConstraint.activate([
            productView.topAnchor.constraint(equalTo: contentView.topAnchor),
            productView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
            productView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
            productView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor)
        ])
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

// Register
collectionView.register(ProductCollectionViewCell.self, forCellWithReuseIdentifier: "ProductCollectionViewCell")

// Dequeue
let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "ProductCollectionViewCell", for: indexPath) as? ProductCollectionViewCell
cell?.productView.configure(with: productViewModel)

Static list with a few items? Piece of cake, we’ll use UIStackView:

class UpsellPopUpProductListViewController: UIViewController {
    private let product1View = {
        let productView = ProductView()
        productView.translatesAutoresizingMaskIntoConstraints = false
        return productView
    }()

    private let product2View = {
        let productView = ProductView()
        productView.translatesAutoresizingMaskIntoConstraints = false
        return productView
    }()

    private let stackView = {
        let stackView = UIStackView()
        stackView.axis = .vertical
        stackView.translatesAutoresizingMaskIntoConstraints = false
        return stackView
    }()

    override func viewDidLoad() {
        super.viewDidLoad()

        view.addSubview(stackView)
        stackView.addArrangedSubview(product1View)
        stackView.addArrangedSubview(product2View)

        NSLayoutConstraint.activate([
            stackView.topAnchor.constraint(equalTo: view.topAnchor, constant: 16),
            stackView.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
            stackView.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16),
            stackView.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -16)
        ])
    }

    func configure(
        with productViewModel1: ProductViewModel,
        and productViewModel2: ProductViewModel
    ) {
        product1View.configure(with: productViewModel1)
        product2View.configure(with: productViewModel2)
    }
}

We can even reuse ProductView within SwiftUI with UIViewRepresentable:

import SwiftUI

struct ProductViewRepresentable: UIViewRepresentable {
    let product: ProductViewModel

    func makeUIView(context: Context) -> ProductView {
        return ProductView()
    }

    func updateUIView(_ uiView: ProductView, context: Context) {
        uiView.configure(with: product)
    }
}

Finally, let’s reduce boilerplate

Embedding a UIView into a cell type every time we need to display a list of items can be a bit repetitive. Luckily, we don’t need to do it manually. We can use generics and create a reusable container cell type:

public class ViewEmbeddingCollectionViewCell<EmbeddedView: UIView>: UICollectionViewCell {
    public let embeddedView: UIView = {
        let view = EmbeddedView(frame: .zero)
        view.translatesAutoresizingMaskIntoConstraints = false
        return view
    }()

    override init(frame: CGRect) {
        super.init(frame: frame)

        contentView.addSubview(embeddedView)

        NSLayoutConstraint.activate([
            embeddedView.topAnchor.constraint(equalTo: contentView.topAnchor),
            embeddedView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
            embeddedView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
            embeddedView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor)
        ])
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Usage of the container cell type is straightforward:

collectionView.register(
  ViewEmbeddingCollectionViewCell<ProductView>.self,
  forCellWithReuseIdentifier: "ProductCell"
)

let cell = collectionView.dequeueReusableCell(
    withReuseIdentifier: "ProductCell",
    for: indexPath
) as? ViewEmbeddingCollectionViewCell<ProductView>

cell?.embeddedView.configure(with: productViewModel)

This same generic pattern can be applied to UITablewViewCell as well.

With that, we have a solution that gives us

full reusability of our list item layout
zero duplication
and minimal glue code.

Summary

Subclassing UITableViewCell or UICollectionViewCell tightly couples our UI to its container. That’s fine until the same UI needs to show up in a new context.

By building our item layouts as standalone views, we gain:

reusability – our UI can be used anywhere, not just in one type of cell.
maintainability – our item layout code always lives in one place regardless of how many different contexts it is used in.

The next time you reach for a UITableViewCell or UICollectionViewCell, consider implementing a plain UIView first.

References

How to add logging to an iOS app in a clean way?

Sun, 30 Apr 2023 00:00:00 +0200

Imagine we are working on a banking app. This iOS app allows users to access their bank account and view a list of transactions.

Since our app needs to be fast and reliable, we’ve decided to log the time it takes to load transactions.

Transactions list before logging

Our feature code is comprised of a view model, an abstract data-loading interface, and a data-loading implementation.

The view model uses the loader to load the data, maps the result to a presentation model, and publishes the new value.

// Feature

class TransactionsListViewModel {
  @Published var transactionItems = [TransactionsListItemViewContent]()

  private let transactionsLoader: TransactionsLoading

  init(transactionsLoader: TransactionsLoading) {
    self.transactionsLoader = transactionsLoader
  }

  func loadTransactions() async {
    let transactions = await transactionsLoader.loadTransactions()
    transactionItems = transactions.map(TransactionsListItemViewContent.map)
  }
}

// Composition

let loader = RemoteTransactionsRepository()
let viewModel = TransactionsListViewModel(transactionsLoader: loader)

// View layer triggers the load

await viewModel.loadTransactions()

Let’s add logging

The most common way to add logging is to have a global singleton logger instance and reference it directly in the feature code.

Here is what this looks like in the code:

// Logger

class Logger {
  private init() {}
  static let sharedInstance: Logger = .init()
  func log(_ message: String) { print("debug: \(message)") }
}

// Date helper to calculate the passed time

extension Date {
  var timeIntervalSince: TimeInterval {
    Date().timeIntervalSince(self)
  }
}

// Feature

class TransactionsListViewModel {
  //...

  func loadTransactions() async {
    let startTime = Date()
    let transactions = await transactionsLoader.loadTransactions()
    let loadingTime = Date().timeIntervalSince(startTime)
    Logger.sharedInstance.log("Transactions loading time: \(loadingTime)")
    transactionItems = transactions.map(TransactionsListItemViewContent.map)
  }
}

In this article, we are more concerned about how to integrate logging into the feature than we are about the implementation details of the logging system. With that in mind, our logger implementation simply prints the message to the console.

Moving our focus to the logging integration point, we notice several drawbacks:

If we want to replace the logger type with a different one, we need to modify the feature code.
If we decide to introduce a 3rd party library for logging, our feature code will directly depend on it.
If there is a requirement to turn off logging for this use case based on context (e.g., tests), it’s impossible to implement it without adding further complexity to the feature code.

Logging within the feature code and depending on a specific logger type makes this design very rigid.

Logger injection

One way to address the direct dependency concern is to hide the specific logger type behind an interface and inject it through the initializer.

Here is what this looks like in the code:

// Logger

protocol Logging {
  func log(_ message: String)
}

extension Logger: Logging {}

// Feature

class TransactionsListViewModel {
  @Published var transactionItems = [TransactionsListItemViewContent]()

  private let transactionsLoader: TransactionsLoading
  private let logger: Logging

  init(transactionsLoader: TransactionsLoading, logger: Logging) {
    self.transactionsLoader = transactionsLoader
    self.logger = logger
  }

  func loadTransactions() async {
    let startTime = Date()
    let transactions = await transactionsLoader.loadTransactions()
    logger.log("Transactions loading time: \(startTime.timeIntervalSince)")
    transactionItems = transactions.map(TransactionsListItemViewContent.map)
  }
}

// Composition

let loader = RemoteTransactionsRepository()
let logger = Logger.sharedInstance
let viewModel = TransactionsListViewModel(transactionsLoader: loader, logger: logger)

This design abstracts the logger type and removes a direct dependency on any logging-related libraries. It is certainly an improvement since we can easily replace the logger implementation with a different one. But the feature code is still polluted with a cross-cutting concern.

Logging Decorator

We can use a decorator pattern to remove the logging from the feature code altogether. With the following design, the feature code is unaffected and unaware of the application’s logging capabilities.

Here is what this looks like in the code:

// Feature

class TransactionsListViewModel {
  @Published var transactionItems = [TransactionsListItemViewContent]()

  private let transactionsLoader: TransactionsLoading

  init(transactionsLoader: TransactionsLoading) {
    self.transactionsLoader = transactionsLoader
  }

  func loadTransactions() async {
    let transactions = await transactionsLoader.loadTransactions()
    transactionItems = transactions.map(TransactionsListItemViewContent.map)
  }
}

// Logging

class TransactionsLoadingLoggingDecorator: TransactionsLoading {
  private let decoratee: TransactionsLoading

  init(decoratee: TransactionsLoading) {
    self.decoratee = decoratee
  }

  func loadTransactions() async -> [Transaction] {
    let startTime = Date()
    let transactions = await decoratee.loadTransactions()
    Logger.sharedInstance.log("Transactions loading time: \(startTime.timeIntervalSince)")
    return transactions
  }
}

// Composition

let loader = RemoteTransactionsRepository()
let loaderLoggingDecorator = TransactionsLoadingLoggingDecorator(decoratee: loader)
let viewModel = TransactionsListViewModel(transactionsLoader: loaderLoggingDecorator)

If you prefer a bit more functional design, here is what that would look like:

// Feature

typealias LoadTransactions = () async -> [Transaction]

class TransactionsListViewModel {
  @Published var transactionItems = [TransactionsListItemViewContent]()

  private let loadTransactions: LoadTransactions

  init(loadTransactions: @escaping LoadTransactions) {
    self.loadTransactions = loadTransactions
  }

  func loadTransactions() async {
    let transactions = await loadTransactions()
    transactionItems = transactions.map(TransactionsListItemViewContent.map)
  }
}

// Logging

func decorateWithLogging(
  loadTransactions: @escaping LoadTransactions
) -> LoadTransactions {
  return {
    let startTime = Date()
    let transactions = await loadTransactions()
    Logger.sharedInstance.log("Transactions loading time: \(startTime.timeIntervalSince)")
    return transactions
  }
}

// Composition

let loader = RemoteTransactionsRepository()
let loggingLoadTransactions = decorateWithLogging(loadTransactions: loader.loadTransactions)
let viewModel = TransactionsListViewModel(loadTransactions: loggingLoadTransactions)

Regardless if the implementation is more object-oriented or functional, the decorator-based design has two significant benefits:

complete separation of the logging as a cross-cutting concern from the feature code
the feature code has no awareness or dependencies on logging-related components

Summary

The decorator-based design gives us increased safety and flexibility.

The increased safety comes from the ability to change the logging behavior without changing the feature components. Notice in the code snippets above how the view model behavior did not change between having no logging and after adding logging with a decorator.

The increased flexibility allows us to move the feature code in a separate framework without dragging any logging dependency with it. We can also have different logging behavior with different decorators for different contexts (e.g., tests).

References

Swift Concurrency Quick Start

Thu, 13 Apr 2023 00:00:00 +0200

If you are new to Swift Concurrency, you are in the right place. Here is everything you need to know in the most condensed form available.

The ideal audience of this post is an experienced programmer familiar with concurrency concepts and interested in learning the Swift Concurrency syntax and APIs.

Get comfy, because we have a lot of ground to cover.

Async/await syntax

Asynchronous functions are defined by adding the async keyword after the parenthesis in the function definition:

func loadIssues() async -> [Issue] { ... }

Asynchronous functions can call other asynchronous functions with the await keyword:

let issues = await loadIssues()

The await keyword marks a potential suspension point. The asynchronous function making this call may or may not be suspended at this point. Suspension in this context means that the function temporarily stops executing. If it is suspended, it will continue execution sometime in the future after the callee returns a result.

Asynchronous functions that can throw an error are marked with async throws:

func loadIssues() async throws -> [Issue] { ... }

Throwing asynchronous functions are called with try await:

let issues = try await loadIssues()

or with one of the other two variants: try? await and try! await.

When you want multiple asynchronous functions to execute concurrently, you assign the result of the asynchronous function call to a constant with async let and then wait for the results later by using await each time you use this constant:

func loadIssues() async -> [Issue] { ... }
func loadProjects() async -> [Project] { ... }
func loadMessages() async -> [Message] { ... }

// these three calls execute concurrently
async let issues = loadIssues()
async let projects = loadProjects()
async let messages = loadMessages()

let allData = await (issues, projects, messages)

let issuesFromAwaitedConstant = allData.0
let issuesFromAsyncConstant = await issues

Methods, computed properties, and subscripts can also be marked with async and async throws:

protocol IssuesStore {
  var issuesCount: Int { get async throws }
  subscript(_ index: Int) -> Issue { get async throws }
  func loadIssues() async throws -> [Issue]
}

class RemoteIssuesStore: IssuesStore {
  var issuesCount: Int {
    get async throws { ... }
  }

  subscript(_ index: Int) -> Issue {
    get async throws { ... }
  }

  func loadIssues() async throws -> [Issue] { ... }
}

let issuesStore = RemoteIssuesStore()
let issueCount = try? await issuesStore.issuesCount
let lastIssue = try? await issuesStore[issueCount! - 1]
let issues = try? await issuesStore.loadIssues()

Continuations

When integrating with an API that still uses completion handlers, you can use the withCheckedContinuation(_:) function:

func loadCurrentUser(completion: @escaping (User) -> Void) { ... }

let currentUser = await withCheckedContinuation {
  (continuation: CheckedContinuation) in
  loadCurrentUser { user in
    continuation.resume(returning: user)
  }
}

It’s your responsibility to make sure the continuation is resumed exactly once. CheckedContinuation will ensure in runtime that it is resumed exactly once. If you want a lower overhead option that doesn’t enforce this rule, you can use the withUnsafeContinuation(_:) function, which works with the UnsafeContinuation. CheckedContinuation and UnsafeContinuation have the same interface, so it’s easy to interchange them.

If the API you are calling can return errors, you can use their throwing equivalents: withCheckedThrowingContinuation(_:) and withUnsafeThrowingContinuation(_:).

The continuation functions can also be used to integrate with delegate-based APIs with separate success and error-handling methods. You can store the continuation object in a local property when calling the API and use it later in the result-handling delegate methods.

class Store {
  func purchaseProduct(withId productId: String) {}
  var delegate: StoreDelegate?
}

protocol StoreDelegate {
  func store(_ store: Store, didCompletePurchaseForProduct product: Product)
  func store(_ store: Store, didFailWithError error: Error)
}

class PurchaseService: StoreDelegate {
  private let store: Store
  private var continuation: CheckedContinuation<Product, Error>?

  init(store: Store) {
    self.store = store
    weak var storeDelegate = self
    store.delegate = storeDelegate
  }

  func purchaseProduct(withId productId: String) async throws -> Product {
    try await withCheckedThrowingContinuation { [weak self] continuation in
      self?.continuation = continuation
      store.purchaseProduct(withId: productId)
    }
  }

  // MARK: StoreDelegate

  func store(_ store: Store, didCompletePurchaseForProduct product: Product) {
    continuation?.resume(returning: product)
  }

  func store(_ store: Store, didFailWithError error: Error) {
    continuation?.resume(throwing: error)
  }
}

Structured and unstructured tasks

Asynchronous functions cannot be called from synchronous functions:

func doSomeAsyncWork() async { ... }

func doSomeWork() {
  await doSomeAsyncWork() // Compilation error: 'async' call in a function that does not support concurrency
}

To call an asynchronous function, we need to use await. Since await requires the program to be able to suspend execution, it can only be used in an asynchronous function.

So how do we enter the initial asynchronous function? Here are the available options:

The static main() method of a structure, class, or enumeration that’s marked with @main (for command-line programs)
SwiftUI view modifiers .task() and .refreshable()
An unstructured task

Let’s unpack that third option.

A task is a unit of asynchronous work. All asynchronous functions run as part of some task. A task can run only one function at a time, but a series of function calls can be executed in one task. When an asynchronous function calls another asynchronous function with await, the called function still runs as part of the same task. When the called function returns, the calling function continues running in that same task until it also returns.

A task can have one or more child tasks. Child tasks can run concurrently with the parent task. A program can consist of a complex tree of tasks. It can be hard to properly propagate cancellations and ensure no loose child tasks are left behind when a parent task completes. That’s why structured concurrency was introduced.

Structured concurrency is an explicit parent-child relationship that allows the Swift compiler to raise errors upfront and Swift runtime to help us manage the tasks. Under structured concurrency, a child task must complete before the parent task completes, and if a parent task throws an error, all child tasks are canceled.

Cancellation is cooperative, so if the child tasks do not comply, the parent task will be blocked and won’t return until all child tasks complete. There is no way for the parent task to force the child task to complete.

Top-level task

Every task tree has a top-level task. When we use SwiftUI modifiers to run asynchronous code or the @main annotation in command line programs, Swift creates a top-level task for us. But we can create and run a top-level task ourselves by initializing a Task:

func doSomeAsyncWork() async { ... }

func doSomeWork() {
  Task {
    await doSomeAsyncWork()
  }
}

This task is unstructured because it doesn’t have a parent task. We can hold a reference to this task and cancel it later if the state of the app changes so that we don’t need the task to complete:

func doSomeWork() {
  let task = Task {
    await doSomeAsyncWork()
  }
  task.cancel()
}

Unless it is cancelled, an unstructured task will outlive the context in which it was created and run until completion independently, even if we don’t hold a reference to it.

We can’t return any values from a task created in the synchronous code since the synchronous code cannot use a suspension point to wait for the result.

func doSomeAsyncWork() async -> String { ... }

func doSomeWork() {
  let task = Task {
    await doSomeAsyncWork()
  }
  let result = await task.value // Compilation error: 'async' property access in a function that does not support concurrency
}

But we can capture references from the synchronous code and modify their state within the task.

class Label {
  var text: String?
}

var label = Label()

func doSomeWork() {
  Task {
    let result = await doSomeAsyncWork()
    label.text = result
  }
}

We can create a new Task within a Task:

func doSomeWork() {
  Task {
    Task { ... }
  }
}

Although this may look like the inner task is a child task of the outer task, that is not the case. These are two unrelated top-level tasks; it just so happens that one creates the other.

We can create a new task within an async function:

func doSomeAsyncWork() async {
  Task { ... }
}

As we established earlier, the async function is already running as part of a task, but the task created in the function is not a child task of the task running this function. It is, again, a new and unrelated top-level task.

Whenever a Task is created, it is a top-level task, regardless if it is created in a synchronous or asynchronous context. That is what makes it unstructured.

Child tasks

An unstructured task is simply a root node of a structured concurrency tree. Any child tasks created under a top-level task fall under structured concurrency rules.

There are two ways to create child tasks:

async let
TaskGroup API

Between the two options, async let is less verbose, but TaskGroup API allows dynamic creation of child tasks and some control over their priority and cancellation.

With the async let expression, a child task is created to run the called function:

func loadIssues() async -> [Issue] { ... }

func useData() async {
  async let issues = loadIssues() // creates a child task
  ...
}

With the TaskGroup API, we can create a dynamic number of child tasks:

struct Document {}

func fetchDocument(from url: URL) async -> Document { ... }

func fetchDocuments(from urls: [URL]) async -> [Document] {
  await withTaskGroup(of: Document.self) { taskGroup in
    for url in urls {
      taskGroup.addTask {
        await fetchDocument(from: url)
      }
    }
    let documents = await taskGroup.reduce([]) { partialResult, document in
      partialResult + [document]
    }
    return documents
  }
}

Each child task in the task group returns the same type - one provided as an argument to the withTaskGroup(of:body:) function. In the example provided, it is a Document. You can use an enum to support different results from individual child tasks.

The task group can return a different result from the individual child tasks. In our example, it is a Document array.

Let’s take a look at how we collected the results from the task group:

let documents = await taskGroup.reduce([]) { partialResult, document in
  partialResult + [document]
}

A TaskGroup is an AsyncSequence. An AsyncSequence is like a regular Sequence but we iterate over its elements asynchronously:

for await element in sequence {
  ...
}

Asynchronous sequences also support many higher-order functions, and that is why we could use reduce() in the earlier example to collect the results.

The order in which the child tasks complete defines the order in which the results will appear in the sequence - the fastest task will produce the first element of the sequence, and the slowest task will produce the last element.

To create child tasks that can throw an error, use the withThrowingTaskGroup(of:body:) function.

Task execution control

Both structured and unstructured tasks have all the control over their execution - they can choose to suspend temporarily or to end execution at some point after they are cancelled.

A task can use Task.isCancelled and Task.checkCancellation() to check if it is cancelled and decide if it wants to continue executing at different stages of its operation.

Task {
  // do some work
  if Task.isCancelled {
    return
  }
  // do some additional work
}

// or

Task {
  // do some work
  try Task.checkCancellation() // throws `CancellationError` if the task is cancelled
  // do some additional work
}

A long-running task can voluntarily suspend itself by calling Task.yield() so that Swift can give other tasks a chance to make progress with their work:

Task {
  for intenseWorkItem in arrayOfIntenseWorkItems {
    doWork(from: intenseWorkItem)
    await Task.yield()
  }
}

A task can also temporarily stop progress by calling Task.sleep() which suspends it for at least a given number of nanoseconds:

Task {
  try await Task.sleep(nanoseconds: 1_000_000_000) // sleeps for a second
}

A sleeping task will resume progress as soon as it gets cancelled. This may sound unexpected, but bear in mind that the cancellation is cooperative in Swift, so the task is woken up on cancellation, and it’s up to the task to complete early if it wants to:

let task = Task {
  // some work
  do {
    try await Task.sleep(nanoseconds: 1_000_000_000) // sleeps for a second
  } catch {
    let cancellationError = error as? CancellationError // cancellationError is not nil
    try Task.checkCancellation() // will complete the task early with CancellationError
  }
  // some more work
}
task.cancel()

Task priority

Tasks can have different priorities that affect the order in which they run. We can specify a priority for a top-level task in the initializer and inspect it within the task:

Task.init(priority: .high) {
  print(Task.currentPriority) // prints "TaskPriority(rawValue: 25)"
  Task.init(priority: .low) {
    print(Task.currentPriority) // prints "TaskPriority(rawValue: 17)"
  }
}

The value of Task.currentPriority may differ from the one assigned to the task on creation if the system escalates the task’s priority to address priority inversion. It’s best to treat the priority as a suggestion for the Swift runtime and not to have expectations of what the value of the Task.currentPriority will be.

Child tasks inherit the priority of their parent task. It’s also possible to define a priority for a child task with the TaskGroup API, but based on my experiments and forum discussions, the resulting priority can be unexpected. The Swift Evolution Proposal recommends not specifying the priority manually for child tasks.

Actors

If there is a shared state in the program that can be accessed concurrently and needs to be protected, we can use an Actor type:

actor Inbox {
  private (set) var messages: [Message]
  func markMessageAsRead(at index: Int) { ... }
}

Actors are like classes but without inheritance. They protect their mutable state with actor isolation. Actor isolation is a collection of limitations on how the actors can be used. In effect, only one task can modify the actor’s state at any moment. This is ensured by requiring the usage of await with access to actor-isolated properties and methods:

let inbox = Inbox()
if await !inbox.messages.isEmpty {
  await inbox.markMessageAsRead(at: 0)
}

All methods, subscripts, computed properties, and mutable properties are actor-isolated by default. If they are not accessing the mutable state, you can allow synchronous access with the nonisolated keyword:

struct User {
  let name: String
}

actor Inbox {
  let refreshRate: TimeInterval
  private let user: User
  ...
  nonisolated var userName: String {
    user.name
  }
}

let inbox = Inbox()
print(inbox.refreshRate)
print(inbox.userName)

Immutable properties are not actor-isolated and can be accessed synchronously.

Actor-isolated methods are reentrants. This means that although only one task can execute isolated methods at any given moment, it is possible for method executions to interleave at suspension points. It is best to design actors with synchronous methods working on mutable state and small asynchronous methods calling these synchronous methods.

Global Actors and the Main Actor

Actors give us concurrent access protection for the state of an individual instance, but sometimes we need this protection for the global state or external resources. Global actors address this need.

A global actor is a globally-unique actor identified by a type. This type is also a custom attribute that can be applied to any declaration. A declaration marked with this attribute is then isolated to this actor, which ensures that only one task may access this declaration at a time.

The primary motivation for introducing global actors is the need to represent the main thread within Swift Concurrency. MainActor is a global actor which ensures that any declaration marked with @MainActor is accessed from the main thread:

@MainActor
func updateUI() { ... }

Additionally, because of global actor inference, declarations that aren’t directly marked with @MainActor can also be isolated to the MainActor unless they are explicitly annotated with a global actor or nonisolated. Swift Evolution Proposal for global actors specifies all the global actor inference rules.

Swift Concurrency and Threads

You probably noticed I hadn’t mentioned threads until the global actors section. That was intentional. Swift Concurrency provides a set of abstractions and APIs which hide the thread management from the developer. And in most cases, the developer doesn’t need to think about threads and how they are managed under the hood. The MainActor is an exception. So let’s take a quick look at how tasks and threads work together.

Swift manages a group of threads called the cooperative thread pool. This thread pool can have as many threads as there are CPU cores multiplied by the number of task priorities. But no more than that. (No thread explosion possible under Swift Concurrency, yay!)

Tasks are scheduled to be executed on the cooperative threads. Tasks can run several asynchronous calls in a row until they get blocked by an infrastructure call or a busy actor. At that point, the task is suspended, and another task gets a chance to run on this thread. There is no guarantee that the code before and after the suspension point will run on the same thread, so later, when the task is unblocked and gets to run again, it might run on a different thread.

Like all asynchronous code, asynchronous Actor methods are executed within a task. A task will run a series of asynchronous actor calls on the same thread as long as it is not suspended for waiting on a result. Switching between actors is called actor hopping, and it is generally very efficient since there is no thread switching under the hood. That is unless the MainActor is involved.

The main thread is not a part of the cooperative thread pool, and actor hopping involving the MainActor requires a thread context switch:

If the asynchronous code is running isolated to the MainActor, and on the main thread as a result, when making an asynchronous call to a different actor, the task will be suspended and scheduled to run on the cooperative thread.
If actor-isolated code is running in a task on the cooperative thread and making an asynchronous call isolated to the MainActor, this will result in the task being suspended and scheduled to run on the main thread.

This behavior can cause performance issues if we are not being careful. Let’s take a look at an example:

actor Incrementor {
  private var counter: Int = 0

  func increment() async -> Int {
    counter += 1
    return counter
  }
}

class IncrementingViewController: UIViewController {
  private let label = UILabel()
  private let incrementor = Incrementor()

  override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Task { [weak self] in
      for i in 0..<100 {
        let count = await self?.increment() // runs on the cooperative thread
        self?.label.text = "\(count!)" // runs on the main thread
      }
    }
}

This example illustrates a real-life situation where you have hundreds of items to update on the screen in a short amount of time, and the data retrieval happens on a non-main actor. The implementation shown in the example makes 200 context switches, which is a significant overhead. Having frequent context switches reduces the performance of the program. Try to avoid repeated actor hopping involving the MainActor.

Leaving the Main Actor

The flow of control in an application starts on the MainActor, and if you want to move the work off the MainActor immediately, there are two ways to do that:

make an actor call
create a detached task

Unlike a Task created with the initializer, which inherits the actor context, a detached task does not:

Task.detached {
  // runs on the cooperative thread
}

Sendable

With Swift Concurrency, we have two ways to keep data safe from concurrent access: tasks and actors. The task’s local scope and actor-isolated declarations are safe areas for mutable state. There is no way for this state to be accessed concurrently. We call these areas concurrency domains or isolation domains.

Data can cross isolation domains when:

a task receives values through arguments, captures values from the outer scope, or returns values
an actor method receives values through arguments or returns values

If the mutable state is passed across isolation domains, there is a risk for data races.

Swift Concurrency provides compiler support to ensure only safe data is passed across isolation domains. Types implementing the Sendable protocol and functions marked with the @Sendable attribute are considered safe.

// Sendable protocol conformance
final class Post: Sendable { ... }

// Sendable function
@Sendable func does(_ string: String, occurIn post: Post) -> Bool { ... }

// Sendable closure
let footer: String = "..."
let appendFooter = { @Sendable (post: String) -> String in
  post + footer
}

The following types can be marked as sendable:

value types
reference types with no mutable storage
reference types that internally manage access to their state
functions and closures

The Sendable protocol doesn’t have any required properties or methods, but it does have semantic requirements that ensure no mutable data is involved. Full requirements are defined in the Sendable documentation.

If a non-Sendable type is passed across isolation domains, the compiler will raise warnings in Swift 5.x, which will become errors in Swift 6.

It’s possible to declare conformance to the Sendable protocol without compiler enforcement:

final class Post: @unchecked Sendable { ... }

With @unchecked Sendable, the developer is responsible for protecting the mutable state within this type by using available access synchronization techniques, such as queues and locks.

Closing thoughts

Alright. That was a lot. Swift Concurrency is no trivial topic. It brings many new and powerful APIs to master. There is more to learn than we covered here, but I hope this gives you a head start.

If you have any questions or inaccuracies to report, please let me know @srstanic. Below you can find all the references I’ve used for this article.

References

Firebase Crashlytics/Analytics, GDPR, and user data management on iOS

Sun, 28 Nov 2021 00:00:00 +0100

Most developers and companies building iOS apps want to have insights into the usage of their apps and get detailed reports when their app crashes. There are many solutions on the market, but Firebase Analytics and Crashlytics services are common choices because they are very well known and can be used for free.

When integrating these services, an important topic to have in mind is user data management and privacy regulations compliance. Depending on your target audience, you might need to comply with the EU General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA). You will also need to adhere to Apple’s Terms of Service.

Before we go further, bear in mind, I’m not a lawyer, and this is not legal advice. If you have access to a legal advisor, please consult with them. Even as I’m writing this article, I still have more questions than answers on this topic. Nonetheless, I think it’s worth sharing my findings and insights as they might help you navigate the integration of Firebase SDKs.

The goal is to integrate Firebase Analytics and Crashlytics services with minimal risk of exposure to government penalties or Apple rejecting your app. What follows is an overview of the legal obligations and technical guidelines for a safe and compliant integration.

GDPR says the following in Article 6:

Processing shall be lawful only if and to the extent that at least one of the following applies:

(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;

…

As the quote indicates, several other bullets can make the user data processing lawful under GDPR, but bullet a) is most likely to be applicable in tracking user behavior and app crashes.

Apple Developer Program License Agreement on data collection

As we all know, Apple has a strong focus on protecting user’s privacy, so it’s no surprise to read the following in Section 3.3.9 of Apple Developer Program License Agreement:

You and Your Applications (and any third party with whom You have contracted to serve advertising) may not collect user or device data without prior user consent, whether such data is obtained directly from the user or through the use of the Apple Software, Apple Services, or Apple SDKs (…) You may not use analytics software in Your Application to collect and send device data to a third party. Further, neither You nor Your Application will use any permanent, device-based identifier, or any data derived therefrom, for purposes of uniquely identifying a device.

This excerpt is from the agreement dated June 2021. For the latest version of the Apple Developer Program License Agreement, visit https://developer.apple.com/support/terms/.

Crashlytics Terms for developers on user data management

In Section 2.6, Crashlytics Terms dated September 23, 2019, says the following:

For Developer’s users in the European Union, Developer shall provide such users with clear notice of, and obtain such users’ consent to, the transfer, storage, and use of their information in the United States and any other country where Google, or any third party service providers acting on its behalf, operates, and shall further notify such users that the privacy and data protection laws in some of these countries may vary from the laws in the country where such users live.

Analytics Terms on user data privacy

In Section 7 titled “Privacy”, Google Analytics for Firebase Terms dated April 17, 2019, says the following:

You will use commercially reasonable efforts to ensure that a User is provided with clear and comprehensive information about, and consents to, the storing and accessing of cookies or other information on the User’s device where such activity occurs in connection with the Service and where providing such information and obtaining such consent is required by law.

Summary of the legal and contractual obligations

It seems evident that the app should provide information about what kind of data will be collected from the device, how and where it will be processed, and the app should allow the user to consent to the described data collection and processing before it happens.

Which data is collected by Firebase and when does the data transfer happen?

Firebase Crashlyics and Analytics by default start collecting user data as soon as the SDKs are activated on the first launch, even if the app does not record any events itself.

Firebase Crashlytics collects:

Crashlytics Installation UUIDs
Crash traces
Breakpad minidump formatted data (NDK crashes only)

Google Analytics for Firebase collects:

Further details on how this data is used by Firebase can be found on Firebase Privacy page.

To avoid data collection without consent, Firebase provides several configurations and APIs that can be used to deactivate and activate Analytics and Crashlytics services. These services should be disabled by default and only enabled once the user has given consent.

From the user experience perspective, a common pattern is to have a privacy policy screen as part of the app onboarding process. This screen should allow the user to review the privacy policy and provide explicit consent to data collection and processing by switching a toggle or tapping on a button.

How to control when Crashlytics collects user data?

Crashlytics can be configured to disable automatic crash reporting by adding an entry to the project’s Info.plist file:

FirebaseCrashlyticsCollectionEnabled: false

After the user gives consent to data collection and processing, the crash reporting can be enabled with

import FirebaseCrashlytics

// in a method processing the transition from the onboarding screen
Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

How to control when Analytics collects user data?

Similar to Crashlytics, Analytics can be configured to disable automatic data collection by adding an entry to the project’s Info.plist file:

FIREBASE_ANALYTICS_COLLECTION_ENABLED: false

After the user gives consent to data collection and processing, the analytics service can be enabled with

import FirebaseAnalytics

// in a method processing the transition from the onboarding screen
Analytics.setAnalyticsCollectionEnabled(true)

To allow the users to change their minds, add an option in the app’s Settings to withdraw consent or give consent again for data collection and processing.

// to stop collecting data
Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(false)
Analytics.setAnalyticsCollectionEnabled(false)

// to start collecting data again
Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)
Analytics.setAnalyticsCollectionEnabled(true)

Conclusion

It is easy to get drowned in the verbose legal documents and technical documentation on user data privacy protection. I hope this article helps you stay above the water and address this boring topic faster so that you can get back to having fun programming. If you have anything to add or you find any inaccuracies in the article, please leave a comment.

Resources

Swift protocol naming guidelines with examples

Wed, 24 Mar 2021 00:00:00 +0100

John Sundell recently wrote an article on the topic of categorizing and naming protocols in Swift. As I was reading it, I realized I had a different take on several ideas shared in the article.

But before I go into the details, I’d like to say that I’m a big fan of John’s work. The first thing I saw from John was his conference talk on system design. Afterward, I started listening to his podcast and reading his articles regularly. I appreciate his efforts to educate the audience about the best practices of programming in Swift. And this post is not about whether he’s wrong and I’m right, or vice versa. This post is about having different perspectives on the categorization of components and naming them. And the difference in opinion on these topics can create a lot of friction in teams. There isn’t always going to be a right and wrong approach to a certain aspect of programming, but there can always be a shared convention within a team working on the same project. And it’s important to have such conventions and consistency in following them because it helps the readability of the codebase. Btw. does anyone still choose tabs over spaces? 🙊

In this particular article, as always, John brings some good points about writing generic code with protocol-oriented design and hiding details of third-party interfaces behind internal protocols. As for the protocol categorization, he suggests four categories of protocols:

Action enablers
Requirement definitions
Type conversion
Abstract interfaces

While it’s a reasonable categorization, I would prefer one that provides more straightforward guidelines on the protocols’ naming.

Protocol categorization and naming

If we look at the Swift API design guidelines, there are two bullets describing the naming of protocols.

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

We can take the capability category, and we can divide it into two subcategories, one where the implementer is a subject performing an action, and the other where the implementer is an object the action is performed on.

In summary, we can define three categories of protocols:

the implementer is something - named with a noun
the implementer is doing something - named with an adjective ending with ing
something is done to the implementer - named with an adjective ending with able or ible

I haven’t yet found short and meaningful names for these categories, but please let me know in the comments if you have some suggestions.

Examples

Now let’s go through some of the examples John provided.

There is a Loadable protocol defined which unifies several types that load various objects or values.

protocol Loadable {
    associatedtype Result
    func load() throws -> Result
}

If we look at what this type does, it performs an action of loading. It is not being loaded itself. The Result is the thing being loaded. Thus an appropriate name for this protocol would be Loading or ResultLoading.

protocol Loading {
    associatedtype Result
    func load() throws -> Result
}

And if we want the result to be Loadable, we can define the protocol that way and make the result type conform to it.

protocol Loadable {
    func load() throws -> Self
}

extension SomeLoadableType: Loadable {
    func load() throws -> Self { ... }
}

But that’s probably not a good idea. A loading operation usually requires some dependencies to a database or a network interface, and the result of a loading operation is typically a data object. And data objects should only contain data and not hold references to the infrastructure components.

The next example discussed is Cachable.

protocol Cachable: Codable {
    var cacheKey: String { get }
}

John argues that this is not a good name because the Cachable protocol doesn’t contain any methods that would perform the caching. But the question is, why should Cachable have any methods to perform caching? The protocol describes something that can be cached and the requirement for that something is to provide a cacheKey. Cachable is a suitable name for it. If this type itself needed to perform caching actions, then a more fitting name for it would be Caching.

The following example is a more complicated one - the Swift.Collection.Sequence protocol from the Swift Standard Library.

public protocol Sequence {
    associatedtype Iterator: IteratorProtocol
    func makeIterator() -> Self.Iterator
}

First, let’s look at the IteratorProtocol protocol. Adding a Protocol suffix to the protocol is easy and convenient, but I have yet to encounter an example where that was the best option. I’ve found that picking from the three categories defined above is a better approach. So how can we improve the naming here?

Whenever I deal with generics, I like to suffix the type parameter name with a Type suffix. That makes it very easy to distinguish between actual types and their placeholders in the generic code, and makes the code more readable. So in the Sequence example, I would propose the following naming.

public protocol Sequence {
    associatedtype IteratorType: Iterator
    func makeIterator() -> Self.IteratorType
}

And following the same convention, let’s update the earlier Loading protocol.

protocol Loading {
    associatedtype ResultType
    func load() throws -> ResultType
}

But getting back to the Sequence example, naming the Iterator as such doesn’t sound quite right, because the Iterator doesn’t fit the is something category. Apple’s documentation summarizes the Iterator type like this:

A type that supplies the values of a sequence one at a time.

The Iterator has a next() method which provides the next item in the sequence. The implementer of this protocol is something that can be iterated. So a more appropriate name for the protocol would be Iterable. And finally the Sequence protocol would look like the following.

public protocol Sequence {
    associatedtype IterableType: Iterable
    func makeIterable() -> Self.IterableType
}

The next example is a ColorProvider protocol described as an interface for a container of colors.

protocol ColorProvider {
    var foregroundColor: UIColor { get }
    var backgroundColor: UIColor { get }
}

Again, I find using a noun here inappropriate because this type is not in the is something category, but in the is doing something category. This type provides colors, so it should be named ColorProviding. There are many examples of type names like Manager, Coordinator, and Generator, where a verb is turned into a noun. When used in protocol names, it would be more fitting to turn these verbs into adjectives - Managing, Coordinating, Generating.

Another example from John’s article is a protocol that describes something that has a title property. This one is tricky. John placed it into the type conversion category suggesting the TitleConvertible name.

protocol TitleConvertible {
    var title: String { get }
}

I get the line of thinking there, but since the title is not a type to which the implementer can be converted, I would look further for a good candidate for this protocol’s name. And I would even say that the fact that something has a title doesn’t justify having a separate protocol. To put it differently, it’s not useful for many different types to conform to the same generic title-requiring protocol, because it’s unlikely that there is going to be generic logic applicable to anything that has a title. But if there is something that is something and also has a title, it might be worth having a protocol for it. For example, a view that has a title could be defined as a TitledView protocol, which extends from a View protocol.

protocol TitledView: View {
    var title: { get set }
}

Conclusion

To reiterate the previous points, I would suggest using the following categorization and naming guidelines for the protocols in Swift:

If the implementer is something, name the protocol with a noun, e.g. Sequence, View, Repository
If the implementer is doing something, name the protocol with an adjective ending with ing, e.g. Loading, Generating, Coordinating
If something is done to the implementer, name the protocol with an adjective ending with able or ible, e.g. Comparable, Codable, Cachable

If you have any thoughts, remarks, or a different viewpoint on any of the above, please let me know in the comments.

Tips for parsing Swift code with SwiftSyntax

Thu, 11 Mar 2021 00:00:00 +0100

I recently worked on a project with a goal to consolidate and standardize localization efforts in a sizeable iOS application written in Swift. This app uses a 3rd party localization service that supports Over-The-Air (OTA) localization. In short, it means that the live app can fetch the latest localizations from the server and there is no need to resubmit the app to the App Store to update the localizations. As a result of this feature, there are no .strings files in the project. All the localization keys and localized values are stored in a proprietary formatted database file used by the 3rd party localization service SDK.

The app has been in development for over 6 years, and presumably, many keys present in the database weren’t used anymore. Having a growing number of unused keys lingering in the database increases the localization costs when entering new markets. So one of the goals was to clean up the unused keys. And the challenge was to figure out which localization keys are currently being used in the app. The only way to know for sure is to find all localization keys referenced in the code. And given that the project has been in development for so long, there was a handful of different patterns for referencing localization keys.

Here is where SwiftSyntax enters the stage. I needed a reliable Swift code parsing tool to collect these localization keys and SwiftSyntax emerged from the research as the best tool for the job.

What is SwiftSyntax and how to use it?

SwiftSyntax is a library for parsing, inspecting, generating, and transforming Swift source code. If you are not familiar with it, the basics of the tool are pretty well covered in these two articles:

SwiftSyntax by Mattt
An overview of SwiftSyntax by Luciano Almeida

To explain how SwiftSyntax works in a single sentence, it builds an abstract syntax tree of the Swift source code and then traverses that tree while letting you react whenever it encounters a type of tree node which interests you.

And to provide an example, let’s take a UIViewController that shows a localized string in its root view.

class ViewController: UIViewController {
    @IBOutlet private weak var label: UILabel!

    override func viewDidLoad() {
        super.viewDidLoad()
        label.text = NSLocalizedString("Hello World!", comment: "")
    }
}

The goal here is to collect the Hello World! string from this code. We can achieve that by implementing a subclass of the SyntaxVisitor class and override one of its visit(_:) methods. The SyntaxVisitor class is the component that walks the syntax tree and the visit(_:) methods provide the hook for your code to run whenever a certain type of node is encountered. The NSLocalizedStringKeyCollector subclass specifically overrides an overload of the visit(_:) method which accepts a FunctionCallExprSyntax node as an argument.

final class NSLocalizedStringKeyCollector: SyntaxVisitor {
    var result: [String] = []

    override func visit(_ node: FunctionCallExprSyntax) -> SyntaxVisitorContinueKind {
        guard
            let identifierExpr = node.calledExpression.as(IdentifierExprSyntax.self),
            identifierExpr.identifier.text == "NSLocalizedString",
            let firstArgumentExpr = node.argumentList.first?.expression.as(StringLiteralExprSyntax.self),
            let localizationKey = firstArgumentExpr.segments.first?.as(StringSegmentSyntax.self)?.description
        else {
            return .visitChildren
        }
        self.result.append(localizationKey)
        return .skipChildren
    }
}

We can use the NSLocalizedStringKeyCollector class to walk the syntax tree and collect any localization keys specified as string literals passed directly into the NSLocalizedString function.

let code = readCodeAsStringFromFile() // reads our ViewController code from a swift file
let collector = NSLocalizedStringKeyCollector()
if let syntaxTree = try? SyntaxParser.parse(source: code) {
    collector.walk(syntaxTree)
    print(collector.result) // prints ["Hello World!"]
}

Tip 1: `Syntax.syntaxNodeType` will help you understand the tree structure

The implementation of the NSLocalizedStringKeyCollector goes into the children of the FunctionCallExprSyntax node looking for a specific structure of nodes. To understand the different types of nodes your code is built from, you will either use autocomplete to explore individual node’s properties, or click-through into the types themselves to explore them. The challenge here is that the syntax node’s properties will often have a generic Syntax or ExprSyntax type, and you will need to know what is the specific node type of the property value. There are many types of nodes and unless you are already very familiar with the full set, it’s going to be hard to guess which specific type you are dealing with.

...
guard
    let identifierExpr = node.calledExpression.as(IdentifierExprSyntax.self),
    identifierExpr.identifier.text == "NSLocalizedString",
    let firstArgumentExpr = node.argumentList.first?.expression.as(StringLiteralExprSyntax.self),
    let localizationKey = firstArgumentExpr.segments.first?.as(StringSegmentSyntax.self)?.description
else {
...

As it’s visible from this snippet, to dig deeper into the tree structure, there are several steps where we need to know the specific node type we want to “cast” into with the .as() method. And this is where the syntaxNodeType property comes in handy. An easy way to find out the type of a node is to print the value of the syntaxNodeType property to the console. But digging through the tree structure node by node can be tedious. Luckily, there is a really cool tool, Swift Abstract Syntax Tree visualizer, which automates this process completely.

Tip 2: Generalize the tree walking logic

I had a handful of syntax visitors and each of them had a purpose of finding some kind of a result, either a string or a certain node type. For each of these visitors, I needed to implement a method that would reset their result, walk the tree, and return the result. After creating a couple of these, I decided to create a generic SyntaxNodeProcessor component that extracts the common logic and provides a unified interface.

class SyntaxNodeProcessor<Result, SyntaxNodeType: SyntaxProtocol>: SyntaxVisitor {
    var result: Result?

    func resetResult() {
        result = nil
    }

    func process(_ node: SyntaxNodeType) -> Result? {
        resetResult()
        walk(node)
        return result
    }
}

The usage of this component doesn’t decrease the amount of code significantly, but it provides consistency and reduces the cognitive load when writing new visitor types. If you have a number of syntax visitors in your code, you might find SyntaxNodeProcessor class useful as well.

The new implementation of the NSLocalizedStringKeyCollector based on the SyntaxNodeProcessor would look like the following.

final class NSLocalizedStringKeyCollector: SyntaxNodeProcessor<[String], SourceFileSyntax> {
    override func resetResult() {
        result = []
    }

    override func visit(_ node: FunctionCallExprSyntax) -> SyntaxVisitorContinueKind {
        guard
            let identifierExpr = node.calledExpression.as(IdentifierExprSyntax.self),
            identifierExpr.identifier.text == "NSLocalizedString",
            let firstArgumentExpr = node.argumentList.first?.expression.as(StringLiteralExprSyntax.self),
            let localizationKey = firstArgumentExpr.segments.first?.as(StringSegmentSyntax.self)?.description
        else {
            return .visitChildren
        }
        self.result.append(localizationKey)
        return .skipChildren
    }
}

And here is how the call site looks when the instance of the reimplemented NSLocalizedStringKeyCollector is used in a loop.

let collector = NSLocalizedStringKeyCollector()
for file in files {
    let code = readCodeAsString(from: file)
    if let syntaxTree = try? SyntaxParser.parse(source: code) {
        print(collector.process(syntaxTree))
    }
}

Conclusion

Parsing Swift code with SwiftSyntax turned out to be much easier than I expected. If you need to parse Swift code, you should consider SwiftSyntax. And if you end up using it, I hope you find the tips in this post useful.

iOS application architecture beyond MVC, MVVM, and VIPER

Tue, 13 Oct 2020 00:00:00 +0200

After years of building, researching, experimenting, and iterating on iOS application architectures, I’ve gathered my learnings and conclusions so far into a single document. This is a document I would love to have had when I first started developing iOS applications.

It goes beyond standard architectural patterns like MVC, MVVM, and VIPER, which you are most likely to stumble upon in the iOS community. It includes powerful insights into architecting long-lasting iOS applications regardless of the architectural patterns used.

You can download it here.

I’m curious to hear if you found it helpful, disagreeable, or both, so please let me know either way. You can leave a comment below or ping me on Twitter.

Rounded border button in Swift and UIKit

Thu, 30 Mar 2017 00:00:00 +0200

Buttons can sometimes be difficult to distinguish from labels in the iOS interfaces with a lot of text. One way to make a button more noticeable is to add a border with a rounded corner to a UIButton view.

Here is a complete RoundedBorderButton class you can use to achieve the same effect:

The class is using @IBDesignable and @IBInspectable attributes to enable you to modify the border properties in the Interface Builder and see the results immediately without running the app.

RoundedBorderButton works best when the button type is set to Custom.

How to create a serial queue with a specified priority in Swift?

Sat, 25 Feb 2017 00:00:00 +0100

To create a serial queue, normally you would write something simple like this:

let queue = DispatchQueue(label: “com.mydomain.myqueue")

If you wanted to define a priority for that queue, you could have done that by retrieving a global queue of the required priority and setting it as a target. But that’s the old way to do it and it doesn’t work in Swift 3. Since Swift 3, once a dispatch queue is activated, it cannot be mutated anymore. Setting a target on an activated queue will compile but then throw an error in run time.

Fortunately, DispatchQueue initializer accepts other arguments besides label and one of them is qos.

let queue = DispatchQueue(label: "com.mydomain.myqueue", qos: .background)

Although Apple documentation states this initializer is available on iOS 10+, I’ve tested it and it also works on iOS 9.

If for whatever reason, you still need to set the target on an already created queue, you can do that by using the initiallyInactive attribute available since iOS 10:

let queue = DispatchQueue(label: “com.mydomain.myqueue”, attributes: [.initiallyInactive])

That will allow you to modify it until you activate it.

References

What's the App Store file size of my iOS app?

Sat, 18 Feb 2017 00:00:00 +0100

I was evaluating some libraries to include in the project and their size was considerably big. So I wanted to know how would that new library affect the size of my app. But I didn’t even know what’s the current size of my app. To find that out, there were a couple of things I checked:

size of the project folder: 41MB
size of the archive that is uploaded to the App Store: 184MB
size of the app stated in the app details in the App Store: 10 MB

Well, that’s kinda weird. What is going on here?

According to the Apple documentation, different artifacts contain different bits of data in different formats:

An App Store submission .ipa is created from an Xcode archive when uploading to the App Store or by exporting the archive for iOS App Store Deployment. This .ipa is a compressed directory containing the app bundle and additional resources needed for App Store services, such as .dSYM files for crash reporting and asset packs for On Demand Resources.
A universal .ipa is a compressed app bundle that contains all of the resources to run the app on any device. Bitcode has been recompiled, and additional resources needed by the App Store, such as .dSYM files and On Demand Resources, are removed. For App Store apps, this .ipa is downloaded to devices running iOS 8 or earlier.
A thinned .ipa is a compressed app bundle that contains only the resources needed to run the app on a specific device. Bitcode has been recompiled, and additional resources needed by the App Store, such as .dSYM files and On Demand Resources, are removed. For App Store apps, this .ipa is downloaded to devices running iOS 9 or later.

In my case, the App Store submission .ipa is 184MB and the thinned .ipa is 10MB. If you want to find out what would be the thinned .ipa size for your app, here is what you need to do:

Export your archive for testing outside the store.
Select “Export for specific devices” and choose “All compatible device variants” from the pop-up menu.
Select “Rebuild from bitcode.”
In the output folder, you will find App Thinning Size Report.txt, which breaks down the compressed and uncompressed file sizes, plus the size of any On Demand Resources, for each device type.

References

https://developer.apple.com/library/content/qa/qa1795/_index.html

Srđan on iOS & Swift

Why I never subclass UITableViewCell or UICollectionViewCell

The obvious implementation

A new requirement

A new implementation with more flexibility

A curveball - an unexpected requirement

Unlocking additional flexibility

Finally, let’s reduce boilerplate

Summary

References

How to add logging to an iOS app in a clean way?

Transactions list before logging

Let’s add logging

Logger injection

Logging Decorator

Summary

References

Swift Concurrency Quick Start

Async/await syntax

Continuations

Structured and unstructured tasks

Top-level task

Child tasks

Task execution control

Task priority

Actors

Global Actors and the Main Actor

Swift Concurrency and Threads

Leaving the Main Actor

Sendable

Closing thoughts

References

Firebase Crashlytics/Analytics, GDPR, and user data management on iOS

GDPR on personal data processing

Apple Developer Program License Agreement on data collection

Crashlytics Terms for developers on user data management

Analytics Terms on user data privacy

Summary of the legal and contractual obligations

Which data is collected by Firebase and when does the data transfer happen?

How to control when Crashlytics collects user data?

How to control when Analytics collects user data?

Conclusion

Resources

Swift protocol naming guidelines with examples

Protocol categorization and naming

Examples

Conclusion

Tips for parsing Swift code with SwiftSyntax

What is SwiftSyntax and how to use it?

Tip 1: Syntax.syntaxNodeType will help you understand the tree structure

Tip 2: Generalize the tree walking logic

Conclusion

iOS application architecture beyond MVC, MVVM, and VIPER

Rounded border button in Swift and UIKit

How to create a serial queue with a specified priority in Swift?

References

What's the App Store file size of my iOS app?

References

Tip 1: `Syntax.syntaxNodeType` will help you understand the tree structure