First, an overview

There are three types of local state in SwiftUI:

1. State that’s only controlled by this view
2. State that’s only controlled by a parent
3. State that’s controlled by both this view and its parent

There’s also external state with environment variables and observables, but I’m going to ignore these in this post for brevity.

State controlled by this view

If you have some local state to keep track of, this is easy:

struct MyView: View {
  @State private var toggleSelected = false
  ...

This state can now be changed by MyView which will rerender whenever toggleSelected is edited. This state can be passed down to child views, but a parent cannot edit this state.

State controlled by a parent

Often, you want a parent view to control a variable without letting the child view edit it. This can be done with a simple instance variable.

struct MyView: View {
  let text: String
  ...
}

struct ParentView: View {
  @State private var text = "hello"

  var body: some View {
    MyView(text: text)
  }
}

At first glance, it may appear that text is immutable since it’s declared with let. However, whenever text on the parent changes, it will call body again and recreate a new instance of MyView with a new text value. This allows the parent to control the state of a child without allowing the child to edit this value.

State controlled by both the parent and child

And finally, sometimes you want state to be controlled by both the parent and the child. For this, you use a binding:

struct MyView: View {
  @Binding var text: String
  ...
}

struct ParentView: View {
  @State private var text = ""

  var body: some View {
    MyView(text: $text)
  }
}

Now, both the parent and child can change the value of text and they share this value. If either the parent change the value of text both views will rerender.

A need for something different

In my app, ZenDen, there’s a feature where you can reassign a task to someone else in your home. This view needs to keep track of which person is selected but it only actually changes if you tap save. So, it makes sense that only the child keeps track of this state. When you tap save, you can simply inform the parent view of this change through a completion block.

Here’s the code so far:

struct ReassignView: View {
  // Called with the selected assignee and keep it fair on save
  let saveTapped: (String, Bool) -> Void
  @State var selectedAssignee = "Anyone"
  ...
}

But there’s a product problem here. Currently, the view will always initialize selectedAssignee with Anyone . But, I wanted to set an initial value which is the current assignee for the task. So, if the task is currently assigned to me, I want the reassign view to pop up and show Peter as the selected assignee. I want to initialize the child’s state with an initial value. You’d think this would be easy by simply passing it in the initializer:

struct ReassignView: View {
  @State var selectedAssignee = ""

  init(assignee: String) {
    selectedAssignee = assignee
  }
}

Sadly, this just doesn’t work. No matter what you pass in as assignee, selectedAssignee will always be initialized to empty string. I can only speculate why this is the case, but it seems like @State can only be mutated outside of the init. Luckily, there’s a workaround:

struct ReassignView: View {
  @State var selectedAssignee: String

  init(assignee: String) {
    _selectedAssignee = State(initialValue: assignee)
  }
}

_selectedAssignee is a trick to access the wrapper object instead of the string. It has the type State<String> and here, it’s initialized with the assignee. Now, when it’s first initialized, the parent can control the initial value. After that, the ReassignView will control the value of selectedAssignee.

But wait, there’s a bug?

Consider the following code:

// in the parent
var body: some View {
  ReassignView(assignee: "Peter")
}

1. The parent creates the ReassignView with the initial value “Peter”
2. The ReassignView changes its internal state to “Alice”
3. The parent is rerendered for some reason (e.g. some unrelated state has changed)
4. init will be called on ReassignView and the assignee will be set back to “Peter”

Won’t this cause a bug?

Actually, no, it won’t. To understand why, we need to understand how SwiftUI injects state into View objects. Although SwiftUI is closed source and the documentation is currently non-existent, it seems to follow this sequence of events:

1. Call init on the View
2. If there’s stored state for this view, set all the @State properties
3. Call body on the View

So, even though in init, we set the initial value of selectedAssignee, this is always overridden before body is called if it’s previously been set. In this case, selectedAssignee will indeed be initialized with the value “Peter”, but it will be changed to “Alice” before body is called.

But wait, isn’t this an antipattern?

The main problem I have with this approach is that it’s not clear to the parent view that this is the behavior. The initializer looks identical to an initializer when the state is controlled by the parent. Consider these two side by side:

Text(myText)
ReassignView(assignee: myAssignee)

If myText changes, then the text will rerender on screen. However, if myAssignee changes, it will not update the ReassignView. Since this new view behaves differently from the stock SwiftUI views, one might consider this an antipattern.

I’ve adopted the convention of prefixing all of these initializer arguments with initial so the initializer becomes:

ReassignView(initialAssignee: myAssignee)

SwiftUI is still new and so it’s up to us (the community) to define conventions like this. Let me know in the comments what you think of this convention and if you have other ideas.

Other ways to accomplish this

Instead of this approach, you could simply make selectedAssignee a binding. However, this feels like it leaks implementation details to the parent since it doesn’t need to ever read this value. It also now needs to worry about resetting this value at the correct time (whenever a new ReassignView is presented). Ultimately, I think this makes it a worse approach.

You could also avoid setting the State with a default value:

struct ReassignView: View {
  let initialAssignee: String
  @State private var storedAssignee: String? = nil
  private var selectedAssignee: String {
    get { storedAssignee ?? initialAssignee }
    set { storedAssignee = newValue }
  }
}

However, this still falls to the same antipattern problems as my approach and requires significantly more boilerplate.

Phew…that was crazy…

Welcome to SwiftUI! 😛 It’s fun.

We’ve just released our new app — ZenDen, and it’s written entirely with SwiftUI. If you have any questions about writing a production app in SwiftUI, let me know in the comments. I’m planning on writing a few more posts on SwiftUI, so let me know what to write next.

We wrote ZenDen to reduce the stress caused by organizing household tasks. The mental load of organizing a home often unfairly falls on one individual when most of this organization can be automated.

We’re always trying to improve, so let us know if you have any feedback on the app.

Thanks to Felix Lapalme for helping review this post.

All you never wanted to know about state in SwiftUI was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing your own networking stack is easy! One of the main advantages of owning your stack is that it’s simple to add additional features. You can pick and choose what you add depending on the specific needs of your application. You don’t need your stack to support every feature anyone could think of, but if you own your code, you can easily add in features when appropriate.

In this post, I’ll show a few examples of extending an existing stack. You may find some examples useful, while others may inspire you to add something else. Specifically, we’ll add:

• A DataConvertible protocol which will make returning non-models possible
• The ability to cancel requests
• Support for downloading files to disk
• Background tasks

What we have so far

In part 1, we built a simple networking stack which could handle GET and POST requests which also handled model parsing, status code errors and threading.

1. It creates a URLRequestfrom a Requestable object
2. It creates a task and starts it
3. In the completion block, it checks for errors and then parses the Data into a model

You can view the full starter code here, but here’s a condensed version:

class Network {
  static let shared = Network()

  let session: URLSession = URLSession(configuration: .default)

  private let queue = DispatchQueue(label: "Network", qos: .userInitiated, attributes: .concurrent)

  func send<T: Model>(_ request: Requestable, completion: @escaping (Result<T, Error>)->Void) {
    queue.async {
      let urlRequest = request.urlRequest()

      // Send the request
      let task = self.session.dataTask(with: urlRequest) { data, response, error in
        let result: Result<T, Error>

        if let error = error {
          // First, check if the network just returned an error
          result = .failure(error)
        } else if let error = self.error(from: response) {
          // Next, check if the status code was valid
          result = .failure(error)
        } else if let data = data {
          // Otherwise, let's try parsing the data
          do {
            let decoder = JSONDecoder()
            result = .success(try decoder.decode(T.self, from: data))
          } catch {
            result = .failure(error)
          }
        } else {
          Log.assertFailure("Missing both data and error")
          result = .failure(NetworkError.noDataOrError)
        }

        DispatchQueue.main.async {
          completion(result)
        }
      }

      task.resume()
    }
  }
}

Data Convertible

One problem with the current stack is that network requests always return a Model. This is the main use-case, but what if the network request doesn’t return anything? Or it returns binary data such as an image?

You have a couple of options. You could write a separate send function for each use-case, but you’d end up with a lot of duplicated code. Instead, let’s try a protocol-oriented approach:

protocol DataConvertible {
  static func convert(from data: Data?) throws -> Self
}

protocol RequiredDataConvertible: DataConvertible {
  static func convert(from data: Data) throws -> Self
}

extension RequiredDataConvertible {
  static func convert(from data: Data?) throws -> Self {
    if let data = data {
      return try convert(from: data)
    } else {
      throw DataConversionError("Missing data")
    }
  }
}

For most types, it’s useful to convert non-optional Data, so there’s a wrapper protocol, RequiredDataConvertible for convenience. We can change our send function to:

func send<T: DataConvertible>(_ request: Requestable, completion: @escaping (Result<T, Error>)->Void) {
  // ...
  } else {
    do {
      result = .success(try T.convert(from: data))
    } catch {
      result = .failure(error)
    }

And now, we can make any type we want adhere to DataConvertible.

extension Data: RequiredDataConvertible {
  static func convert(from data: Data) throws -> Data {
    return data
  }
}

// You can use this to return no data
struct Empty: DataConvertible {
  static func convert(from data: Data?) throws -> Empty {
    return Empty()
  }
}

You could also easily add support for strings, images, dictionaries, arrays, or anything else your app may need.

Sadly, making Decodable is a little trickier as you can’t simply extend Decodable to be DataConvertible. Data is also Decodable, so you end up with ambiguous types. To get around this, we need to use type erasure:

struct DecodableConvertible<T: Model>: RequiredDataConvertible {
  let model: T

  init(_ model: T) {
    self.model = model
  }

  static func convert(from data: Data) throws -> DecodableConvertible<T> {
    let decoder = JSONDecoder()
    let model = try decoder.decode(T.self, from: data)
    return DecodableConvertible(model)
  }
}

And then we need to add another send method to Network:

func send<T: Model>(_ request: Requestable, completion: @escaping (Result<T, Error>)->Void) {
  return send(request) { (result: Result<DecodableConvertible<T>, Error>) in
    // We want to return T, so we should map to the inner model
    completion(result.map { $0.model })
  }
}

Effectively, we’re creating a wrapper struct to hold the inner model. Then, we return this struct from the network stack and map out the inner model. The type erasure technique is common, and you can learn more about it here.

By the way, this type erasure is the reason why we need the Model protocol (remember how we used that instead of Decodable for the models?). Now, if you pass in a Model as a return type, it will use the DecodableConvertible struct, but if you pass in Data, it will use the extension on Data to do the conversion. That may seem like a lot to follow, but if you’re confused, try checking out the code and use Decodable instead of Model.

Cancelling Requests

NSURLSession allows cancelling of requests, but currently, our network stack does not. We can’t simply return a URLSessionTask because our stack is completely asynchronous (which is a good thing). There’s a solution though — we just need to write a class to handle canceling before the request is sent.

class NetworkTask {
  private var task: URLSessionTask?
  private var cancelled = false

  private let queue = DispatchQueue(label: "com.peterlivesey.networkTask", qos: .utility)

  func cancel() {
    queue.sync {
      cancelled = true

      // If we already have a task cancel it
      if let task = task {
        task.cancel()
      }
    }
  }
  
  func set(_ task: URLSessionTask) {
    queue.sync {
      self.task = task

      // If we've cancelled the request before the task was set, let's cancel now
      if cancelled {
        task.cancel()
      }
    }
  }
}

This class simply saves the cancel request and once the task is set, it will cancel it immediately. The only thing to remember is to use a DispatchQueue to keep everything thread-safe. Then, just update the send function:

func send<T: DataConvertible>(...) -> NetworkTask {
  let networkTask = NetworkTask()
  queue.async {
    // ...
    task.resume()
    networkTask.set(task)
  }
  return networkTask
}

Though that session task is set asynchronously, we can immediately return our empty task since it can be cancelled at any time.

Adding Background Tasks

When your app goes to the background, usually all network tasks are cut off. This creates a really bad user experience. If users switch apps quickly, they’ll see error messages when they return to the app. Luckily, Apple provides a really easy API to solve this, and you can add it directly into the stack for every request. Just add to your send method:

func send(...) {
  let backgroundTaskID = UIApplication.shared.beginBackgroundTask(expirationHandler: nil)
  // ... after all the main logic, when you finish:
  DispatchQueue.main.async {
    completion(result)
    UIApplication.shared.endBackgroundTask(backgroundTaskID)
  }
}

File Download Support

File downloading is similar to downloading data, but it has a slightly different API. You could simply copy-paste your existing code and change the necessary lines, but I prefer to share the code.

This is a little tricky, but possible with some creative closures. First, we need to change our send method slightly and also make it private (because this API isn’t exactly user friendly):

private func send<DataType, ReturnType>
(_ request: Requestable,
 taskCreator: @escaping ((URLRequest, @escaping (DataType?, URLResponse?, Error?)->Void)->URLSessionTask),
 dataConvertor: @escaping (DataType?) throws -> ReturnType,
 completion: @escaping (Result<ReturnType, Error>)->Void)
 -> NetworkTask {

Let’s decode what’s happened here:

• There’s an additional generic parameter: DataType
• The first parameter is still just the request
• The second parameter is a closure which converts a URLRequest and completion block into a data task
• The third parameter is a closure which converts a DataType into a ReturnType
• The final parameter is the completion block

Now, let’s convert our original send function to use this helper function.

func send<T: DataConvertible>(request, completion) -> NetworkTask {
  return send(
    request,
    taskCreator: { session.dataTask(with: $0, completionHandler: $1) },
    dataConvertor: { try T.convert(from: $0) },
    completion: completion
  )
}

The second parameter creates a data task from the session object. This is just a one-liner. The third parameter simply calls the DataConverible convert function.

We can write a similar function to wrap download requests:

func download
(_ request: Requestable,
 destination: URL,
 completion: @escaping (Result<Empty, Error>)->Void) -> NetworkTask
{
return send(
  request,
  taskCreator: { session.downloadTask(with: $0, completionHandler: $1) },
  dataConvertor: { try self.moveFile(from: $0, to: destination) } },
  completion: completion)
}

This function takes a request and a destination URL and downloads a file to that location. The second parameter creates a download task instead of a data task. The third parameter takes the temporary URL returned by the download task and moves the file from that location to the passed in location.

Now, you just need to update the send code to use these task creator and data convertor tasks. This is relatively simple, but if you’re interested in the details, you can check out the full code here.

Other Ideas

Remember, you don’t need to add any of these features if it’s not appropriate for your app. These are only examples of things you may want to add.

When building the Navigator app, I added even more features including redirect handling, unzip support for files, and parsing custom errors. (If you’re interested in working with a stack like that, they’re hiring).

The key takeaway here is that if you own your network stack, it’s yours. You can mold it into whatever your app needs.

This project and article will need to evolve as Swift and Foundation change. If you have any suggestions, comments, improvements, bugs, please let me know in the comments or submit a PR to the Github project.

Thanks to Alice Avery and Kamilah Taylor for reviewing this post.

Adding Advanced Features to your Network Stack in Swift was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing your own networking stack has several benefits. To name just a few:

• Avoids a 3rd party dependency which will need upgrading
• More understandable code (since you wrote it!)
• More extensible
• Easier to debug, add logs, and add performance monitoring
• Much easier to add advanced functionality
• Allows you to parse errors from your backend into a specific model
• Makes it easy to support custom error handling such as 401 or 500 status codes

Plus, it’s now just really easy! In this article, I’m going to go over the basics. By the end of this post, you’ll have a network stack that can easily send GET and POST requests with model parsing with little boilerplate.

let request = Request(path: "users/1")
Network.shared.send(request) { (result: Result<User, Error>) in
  switch result {
    case .success(let user):
      print(user)
    case .failure(let error):
      print(error)
  }
}

In a follow-up post, I’ll show how you can upgrade this simple network stack with more advanced features such as background tasks, file downloads, cancelable requests, and more.

Setup

First, let’s create a new file, Network.swift and add a singleton accessor, a session variable, and a basic send function:

class Network {
  static let shared = Network()
  let session: URLSession = URLSession(configuration: .default)

  func send(_ request: URLRequest,
            completion: @escaping (Result<Data, Error>)->Void) {}
}

The send function takes a request and a completion block which returns a Result with either data or an error. Now, let’s fill this in with a simple implementation:

Log.verbose("Send: \(urlRequest.url?.absoluteString ?? "")")

let task = session.dataTask(with: request) { data, response, error in
  let result: Result<T, Error>
  if let error = error {
    // First, check if the network just returned an error
    result = .failure(error)
  } else if let data = data {
    result = .success(data)
  } else {
    Log.assertFailure("Missing both data and error from NSURLSession.")
    result = .failure(NetworkError.noDataOrError)
  }

  DispatchQueue.main.async {
    completion(result) 
  }
}

// Make sure to call resume on the task or nothing will happen!
task.resume()

Most of the code here is straightforward, but you’ll notice a couple of interesting things about this implementation:

1. I created a simple NetworkError enum for some basic errors.
2. I’ve added some Log statements to the code. This is one of the benefits of your own networking stack! You can add your own Log statements where you see fit. Here’s my implementation or previous post on assertions in code.

Models

This send function works fine, but it isn’t much better than just using URLSession directly. In most cases, we don’t want Data returned, but a model. So, let’s add a Model protocol and add support for parsing.

protocol Model: Codable {}

It’ll become clear in a future post why we create this empty protocol instead of using Codable directly. Just trust me for now.

func send<T: Model>(_ request: URLRequest, completion: @escaping (Result<T, Error>)->Void) {

...

} else if let data = data {
  do {
    let decoder = JSONDecoder()
    result = .success(try decoder.decode(T.self, from: data))
  } catch {
    result = .failure(error)
  }
}

Simple. We just change the send function to be generic and add the JSONDecoder handling. When we call this function, we’ll be returned a model to immediately use in application code.

Better Requests

The URLRequest object is a little verbose to use, so instead, let’s create a wrapper object to make creating requests easier. Instead of using inheritance, I prefer a protocol-oriented architecture:

protocol Requestable {
  func urlRequest() -> URLRequest
}

struct Request: Requestable {
  let path: String
  let method: String

  init(path: String, method: String = "GET") {
    self.path = path
    self.method = method
  }

  func urlRequest() -> URLRequest {
    guard let url = URL(string: "BASE_URL") else {
      Log.assertFailure("Failed to create base url")
      return URLRequest(url: URL(fileURLWithPath: ""))
    }

    var request = URLRequest(url: url.appendingPathComponent(path))
    request.httpMethod = method

    return request
  }
}

extension URLRequest: Requestable {
  func urlRequest() -> URLRequest { return self }
}

This new Request object includes the base url for your server so you can simply specify a path and a method. We can also easily make URLRequest adhere to Requestable in case we do want to make requests to other servers.

Updating our send method to use this new protocol is trivial:

func send<T: Model>(_ request: Requestable, completion: @escaping (Result<T, Error>)->Void) {
  let urlRequest = request.urlRequest()
  ...

Post Requests

When sending a POST request, you often send JSON data as part of the request. Of course, we don’t want to format that ourselves. How about using a Model? Let’s add a PostRequest struct:

struct PostRequest<Model: Encodable>: Requestable {
  let path: String
  let model: Model

  func urlRequest() -> URLRequest {
    guard let url = URL(string: "BASE_URL") else {
      Log.assertFailure("Failed to create base url")
      return URLRequest(url: URL(fileURLWithPath: ""))
    }

    var request = URLRequest(url: url.appendingPathComponent(path))
    request.httpMethod = "POST"

    do {
      let encoder = JSONEncoder()
      let data = try encoder.encode(model)
      urlRequest.httpBody = data
      urlRequest.setValue("application/json",
                          forHTTPHeaderField: "Content-Type")
    } catch let error {
      Log.assertFailure("Post request model parsing failed")
    }

    return urlRequest
  }
}

Now, you can send models up to the server as POST requests. For example:

let newUser = User(id: 2, name: "Peter")
let request = PostRequest(path: "/users", model: newUser)
Network.shared.send(request) { (result: Result<Empty, Error>) in
  print(result)
}

Status Code Errors

One gotcha of URLSession is that it doesn’t handle status code errors. Luckily, adding logic to parse the status code is easy. And in the future, you could also handle specific status codes like unauthorized errors.

struct StatusCodeError: Error {
  let code: Int
}

private func error(from response: URLResponse?) -> Error? {
  guard let response = response as? HTTPURLResponse else {
    Log.assertFailure("Missing http response")
    return nil
  }

  let statusCode = response.statusCode

  if statusCode >= 200 && statusCode <= 299 {
    return nil
  } else {
    Log.error("Invalid status code: \(statusCode)")
    return StatusCodeError(code: statusCode)
  }
}

Next, add this check to the send function:

if let error = error {
  result = .failure(error)
} else if let error = self.error(from: response) {
  result = .failure(error)
} else if let data = data {
  ...

Threading

And for the last touch, let’s make this a bit more performant. URLSession already runs all networking operations on a background thread, and our model parsing for Get requests is on a background thread. But, when urlRequest() is called, it may cause some JSON parsing to run on the main thread. I recommend wrapping everything inside of send inside of an async block. With that change, send won’t do any work on the main thread.

Getting the Code

If you’d prefer to just copy-paste code into your own project, you can find all the code for a full network stack (and a few examples) in this Github project. The code for this article is shown in SimpleNetwork.swift.

See It in Action

I wrote a similar network stack to this in the Navigator app, which helps make your meetings more productive. Of course, you can’t actually see the network stack…but hopefully, you can feel the elegant code through the app 😉. And, if you’re interested in working with code like this, they’re hiring.

Next time…

This post just outlines the basics of getting a lightweight network stack up and running. With some customization, this should be enough for most apps. In the next post, I’ve included some more advanced features that really show the power and benefit of building your own stack.

This project and article will need to evolve as Swift and Foundation change. If you have any suggestions, comments, improvements, bugs, please let me know in the comments or submit a PR to the Github project.

Thanks to Alice Avery and Kamilah Taylor for reviewing this post.

Writing an Elegant and Extensible Network Stack in Swift was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are many different ways of making an app work offline, each with advantages and drawbacks. There’s no magic bullet that will work every time, so it’s up to you to carefully weigh your options. Sometimes, the best solution may be a combination of several different technologies!

The main solutions available to make the app work offline are:

• A database, such as Core Data or Realm
• A denormalized cache, such as PINCache or NSURLCache
• A normalized model, cache such as Rocket Data
• Saving data to the file system

There are many different ways to implement an offline mode, and you should always try to select the right tool for your app. But first, why should you make your app work offline?

Why is offline important?

First of all, speed matters. 40% of users abandon pages which take more than 3 seconds to load. People expect apps will be responsive and snappy. If they see a loading spinner for too long, they’ll just leave your app and open up one of the many other attention grabbers on their phone. But, if your app works offline, it will be fast even in poor network connectivity.

Second, Business2Community estimates that 15% of the app usage at any time in the US is offline, and in international markets, this is likely to be even higher. You users may be on a plane, in a cafe with a flaky connection, or on the subway, and their internet could be coming in and out. If your app doesn’t work in these conditions, they will simply stop using your app.

Caches vs. Databases

When implementing an offline solution, the first step is to decide between a cache or a database. Databases can be powerful, but are overused by developers. Caches are simpler and are a better fit for many applications.

The most common database solutions are Core Data and Realm, though many people prefer to use SQLite directly. You define models, load data from the network, and insert it into your database. Then, your view controllers listen to queries on the database and update whenever the data changes.

When implementing a cache, you load data from the cache and the network in parallel. The cached data doesn’t need to be structured and can simply be a serialized version of the data from the network. This means that loading data from the network and the cache look identical from a code perspective. There are many open source implementations of caches; PINCache and NSURLCache are two common options.

Databases are good if:

• You can download all of the data for a user and store it locally without using too much disk space.
• You can easily write logic that limits the data used on the device.
• You need to be able to do simple, local searches over thousands of records.

Caches are good if:

• You cannot download all the data for a user and need a simple eviction strategy.
• You’ve already written logic to download data from the network and want to add in an offline mode without rewriting your application.
• You want a simpler, lightweight, and flexible solution.

The problems with databases:

• They are notoriously difficult to get right. You should expect to spend a decent amount of developer time dealing with crashes in this part of your application.
• You need to write models and migrate them whenever something changes.
• Deleting models to free up space is really difficult as it’s impossible to tell which models are currently in use by screens.

Despite the downsides and overuse of databases, for some applications, it’s a great option. For example, a database would work well for a podcast player. You can download a reasonable number of upcoming episodes, and it’s easy to know when to delete models (once the user finishes an episode). Another example is a saving a game, as the user will never want to have a saved game deleted (unless they delete it manually).

On the other hand, a social media application would be much better suited with a cache. It’s impossible to download all the content for a user, and as they browse, a database would get larger and larger. In a similar vein, a news reader application would be much better with a cache. As the user browses new articles, a database wouldn’t stop growing. A cache easily stores everything you’ve recently viewed and automatically purges older articles. Additionally, you never need to migrate models or worry about data faults.

Normalized vs. Denormalized Data

There are two main ways to store data in a cache — using normalized or denormalized data. Most application data can be visualized as a tree-like structure. It has a root model and then several child models (which then in turn could have more child models). When caching this data, you could simply store the entire tree as one entry in the cache. This will look something like this:

This is the simplest way to use a cache. You can implement it with just a few lines of code and it’s easy to pick unique ids for objects (for instance, you could store each object by the URL you used to fetch it).

However, you’ll notice that the author object is inserted twice into the database as a nested object. This means if you update the article with id=3 with an updated author object, next time you read article with id=42, you’ll get the old author. If this type of consistency is important, you could consider ‘normalizing’ your data before you cache it. This means ripping apart the tree into submodels and caching each model under a unique id. For example:

Note that this is not a database! Each entry is still a blob of unstructured data keyed by an id. This means you still won’t need migrations when models change and eviction is simple. However, implementing this system is not simple as you also need to write logic to reconstruct models and have unique ids for each submodel.

Note: because of the overhead of storing the dotted line ‘pointers’ above, this solution actually doesn’t use less space than a denormalized cache. See the ‘Additional Tips’ section for more info.

I’ve previously written about using this strategy for the LinkedIn App, and the code that powers consistency amongst models is open-source. Using this solution, adding offline behavior was easy for new pages, and we never had to migrate models or clean up large databases.

Downloading Data from a Server

There are a few options for retrieving data from the network and the cache or database.

The simplest is to always retrieve data from the cache and network in parallel. If the cache returns first, call your completion block with the cached data. Then, once the network finishes, call the completion block with the new data. This allows you to contain most of the caching logic in the network layer and all the view controllers need to do is display the data.

However, this approach will sometimes call the completion block twice. For some apps, this may be problematic, so you could consider only using the cached data if the network is slow. You only display the cached data if the network fails or takes too long to load. I’d recommend setting the timeout for this to be short. Remember that when offline, requests will often timeout after a minute instead of erroring immediately.

Another solution is to place your cache or database between your view controllers and network. In this ‘reactive’ model, you immediately retrieve models from the database and listen for changes. Once the network request finishes, it edits the database and the view controller automatically updates with the changes. This approach has been well-documented. It’s a simple mental model, but listening to model changes in all view controllers is sometimes not trivial and leads to a lot of boilerplate code.

Finally, you can use a database sync solution such as Realm Platform or Firebase. With these platforms, you host a version of the database on your server and changes are automatically synced to clients in a data-efficient way. These solutions implement a lot of complexity, but this complexity is hidden in a black box and has nontrivial requirements on how you structure your server.

Uploading Data

When users change data in an application, it’s difficult to decide how this should work in low network connectivity. The simplest way is to show a spinner and wait for the request to finish. You can block the UI and if necessary, alert the user that something failed with a banner or alert. However, this is isn’t the best user experience. I still cannot believe that iMessage won’t allow me to send messages when offline.

A common solution to this problem is to create a queue for offline tasks. If a request fails because of low connectivity, add it to a disk-backed queue and try again when you are connected to the internet. While this sounds simple in theory, in practice, there are a lot of edge cases you need to consider:

1. How many times should you retry a request?
2. Is the ordering of requests important?
3. If a request finally fails after a number of retries, how do I inform the user?
4. How do I let the user know that a request is pending and hasn’t yet synced?

On top of all this, you need to revert the data if an upload fails. Consider the following flow:

1. The user likes something on their phone which is offline.
2. The user likes the same thing on their laptop which is online.
3. The phone connects to the internet, and downloads new data for this item (which says it is liked).
4. Next, uploading this like on the phone fails for some reason.
5. The phone reverts the item to no longer be liked.

Notice how the phone ends up in the wrong state! Even worse, since the phone doesn’t know it’s not in the right state, it may not refresh this from the network. When reverting data, you can’t simply take the opposite of an action. You need to revert to the last thing the server told you was correct. This means you now need to store both your current state and the last seen server state.

These problems are still solvable. When I was at Superhuman, we built an architecture we called a ‘modifier queue’ that solved all of these edge cases. You can read more details on this on the Superhuman blog.

Likely for your app, you don’t need to go as far as implementing a modifier queue. Uploading data is difficult, and you should think through which use cases you care most about and concentrate on those being great experiences.

Consistency

Once you’ve edited your cache or database locally, you may need to update multiple screens in the app. This is a deep topic that is way beyond the scope of this post, but here are a few techniques to consider:

• Listening to Database Changes
  Most databases offer the ability to listen to models changing. If you’re using a database instead of a cache, this is likely the simplest solution.
• Delegation
  If a change only affects a couple of view controllers in your app that have a relationship, you can simply use a delegate to propagate the change. Though you can only use this if the change doesn’t appear elsewhere, this is a very simple solution and you shouldn’t overlook it if it just works.
• An Event Bus
  One of the simplest ways to implement changes to a cache is to use an event bus system to notify all listeners of changes. You simply listen to changes to a certain id and if it changes, reload data from the cache and refresh the view. NSNotificationCenter is the first party solution, but I’d recommend looking at some open source projects that offer a better API as well as typesafe notifications. SwiftNotificationCenter and SwiftEventBus are two popular examples.
• Rocket Data
  Rocket Data manages the consistency for immutable models and is specifically designed to work well with a cache. It simply listens to changes on certain ids and notifies you when a model has changed. It’s a more powerful solution than the event bus and allows you to use immutable models, but also requires more work to set it up. For more information, see my talk on Rocket Data or the docs.

Combining Techniques

I recently added an offline mode to my Chess Tactics App. I had three use cases for offline usage, each with slightly different requirements:

• Users should be able to view all pages in the app offline if they’ve visited them recently.
• Users should be able to explicitly save puzzles to view offline. These should never be evicted.
• The main feature of the app presents a random puzzle to the user curated for their skill level. This should work offline.

Instead of picking one architecture and trying to fit all of these use cases to it, I decided to pick three different offline techniques!

For viewing arbitrary pages, I simply added a key-value store cache keyed off the URL for the request. I chose a denormalized cache since I didn’t have many submodels in my requests, and submodel consistency isn’t important to my application. Even though I had already coded the entire app, adding this was trivial and only took a couple of hours.

For saving puzzles, I used a structured database. I never wanted these evicted and there was no chance that the user could save too much data since an individual puzzle is only a few KB. A structured database also allows the flexibility to sort or filter these puzzles in the future.

For presenting a random puzzle to the user, I also used a database, but instead of using a structured database, I simply used an NSData blob to store the JSON. In the background, the app downloads about 200 puzzles and stores them. If the user is offline, the app selects one randomly (an operation that is difficult with a cache), presents it to the user, and then deletes it. Using a database fit my needs as I could easily control its size. Storing the data as a blob instead of using separate fields allowed me to simplify my code and avoid any additional parsing logic. Contrary to popular belief, storing data as blobs is very fast with a database as long as the blobs are small.

When selecting a random puzzle offline, my view controller never used database models directly. Instead, I parsed the data blob into an in memory model before passing it to the view controller. This way, my view controller was completely isolated from any disk storage logic, and I could safely delete these models at any time.

For uploading data, I implemented a simple queue to upload user rating changes. Since the app is read-heavy, I decided it wasn’t worth it to implement other POST requests. The app simply shows a message saying: ‘your rating will update when you are online.’

The key point here: you shouldn’t force every feature to use the same offline solution. By combining different techniques, you can provide a better user experience and reduce development time.

Conclusion

If nothing else, I hope you remember that there are many different solutions for making an app work offline. Don’t just start banging your head against a Core Data implementation immediately because it’s what you’re familiar with; think hard about the problem you’re trying to solve before selecting the best solution.

For many apps, a cache is a better choice, because it’s a simpler solution. It offers an easy method for eviction, it doesn’t require model migrations, and doesn’t crash all the time.

Regardless of your chosen technology, you also need to consider how you are going to upload changes and keep your app consistent as part of your offline strategy. And finally, you shouldn’t box yourself into just one technology. Often, a combination of different techniques will be the best solution.

Additional Tips

Where should you save data?

iOS actually provides a cache directory for storing cache data. However, this directory is cleared if the device is running low on space. This is a great thing if it’s actually a cache, but not if you’re relying on this data for basic functionality. You can also put files in the tmp folder for even shorter lived files.

Offline Detection on iOS is very Flaky

Apple offers a reachability API that notifies you when connection to the internet changes in some way. However, this API is flaky and you shouldn’t rely on it for infrastructure logic. Internally, it never actually makes network requests. It just tells you when the hardware could connect to the internet. You can use this API for UI to show to the user, but you should never avoid sending a request because of this API — the only way to know if you’re actually able to reach your server is to try the request. Jared Sinclair recently wrote a good article on this.

Normalized Caches Don’t Use Less Data

As I mentioned earlier, normalized caches don’t necessarily use less data than denormalized caches. Though they don’t duplicate models, there is overhead to store data separately. Consider the following trivial example:

// Denormalized data
{ id: 'parent', child: { id: 'child' }}

// Normalized data
{ id: 'parent', child: 'child' }
{ id: 'child' }

Notice how in the second example, the id of the child model is duplicated meaning that the total bytes used by the normalized data in this instance is actually higher. This seems small, but if you have a lot of small, nested models, it really adds up quickly. When working on the LinkedIn app, we found that normalized data took up about 5–10% more space than denormalized data. Because of this, we decided to send denormalized data over the network where size matters.

Of course, this is dependent on your specific dataset. There’s a tradeoff here, so measure before you decide!

The Fastest Cache is SQLite!?

Ironically, the fastest cache I’ve found that’s readily available for iOS development is actually SQLite. You can simply create a model with three fields: id, data, and timestamp. After creating an index on id, lookup and storage is faster than the NSFileManager solution used by many open source solutions. As far as I know, there’s no open source library that implements this API and eviction logic, but if you’re interested in creating one, let me know. I’d be interested in contributing.

The Many Offline Options for iOS Apps was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

I wanted to dive into the game theory of ‘Bullshit’ so I wrote a short application to simulate the game. I coded several different strategies, played them against each other thousands of times, and worked out the win rate of each strategy.

You can try playing against the best strategies yourself here. It’s tough! Hopefully, the rest of this post will help you win.

The Rules

I picked ‘Bullshit’ for this experiment because the rules were simple and easy to code. There are several other games which employ similar strategies of lying to gain an advantage (such as Coup), but they are more complex.

‘Bullshit’ is played with a standard deck of 52 cards. First, you deal out all the cards in the deck. Then, each turn is played as followed:

1. Player 1 places any number of cards face down in a stack and claims they are all aces. They must play at least one card, so may be forced to lie.
2. Any player can call bullshit if they don’t believe player 1.
3. If player 1 lied, then they pick up all the face-down cards, including any that were put down on previous turns. If player 1 told the truth, the bullshit-calling player picks up all the cards. If no-one called bullshit, then play just continues.
4. Either way, it’s player 2’s turn and they add cards to the stack claiming they are all 2’s.
5. The game continues like this, incrementing the card each turn all the way to the king and then restarting with the ace.

The game is over when one player gets rid of all their cards. You can see more details on the rules here.

Methodology

1. First, I wrote a script to play the game out with certain strategies. Each player has two complementary strategies encoded: a ‘bluffing’ strategy that dictates how they play, and a ‘calling’ strategy that determines when they call bullshit on other players.
2. For each strategy, I played it against three other players with random strategies 5,000 times and saw how often it won.
3. I then removed the bad strategies and ran the experiment again so that poor strategies didn’t skew my results.

The code is all open source: https://github.com/plivesey/bs. Please submit suggestions for other interesting strategies!

Bluffing Strategies

Here are all the strategies I decided to test. Remember, if a strategy performs poorly, it’ll get removed and I’ll run the test again.

The Saint — never lies unless forced. For example, if they have to play an ace, but have no aces, they will be forced to lie.

The Dabbler — lies 10% of the time.

The Coin Flipper — lies 50% of the time.

Mr. Pathological — always lies.

The Pusher — always lies when they have a single of one card.

The Game Theorist — calculates the expected value of lying based on the chance bullshit is called and only lies if it’s worth it.

The Closer —doesn’t lie if they can finish the game without doing so. Otherwise, plays as the game theorist would. For example, if they are required to play an ace and have an ace, a five and a nine, then they can guarantee finishing in three turns. In this case, they will never lie. If they had an ace, a two and a five, then they won’t be able to finish so will play as the game theorist would.

The Comeback Kid — lies with much higher percentages when losing and never lies when winning.

The Comeback Closer — plays like the comeback kid unless they can finish off the game without lying.

The Pathological Closer — always lies unless they can finish the game without lying.

Calling Strategies

The Believer — never calls bullshit.

Once in a while — calls 10% of the time.

Two-face — calls 50% of the time.

The Accountant — keeps track of how much people lie or tell the truth. Every time someone lies, double the percent chance of calling on them, and every time someone tells the truth, half this chance.

The Salty One — calls every so often only on the winning player.

The Skeptic — calculates the chance the player actually has the card they claim and calls if this is lower than 25%.

Nervous Norbert — calls the player to the right if they would have to lie on the next turn. This will hopefully clear the discard pile to lessen the risk of needing to lie.

The Collector — calls out players if the number of cards played plus the number of the same card that the collector has in their own hand equals four. This means that even if the called-out player is telling the truth, the collector gets four-of-a-kind.

The Salty Accountant — plays like the accountant, but calls much more often on the leader than other players.

Tactics

There are a couple of tactics that every player uses since it’s always advantageous.

First, if the current player has no cards remaining, you should always call bullshit on them. Otherwise, you will immediately lose.

Second, when lying with a card, you always want to lie with your ‘worst card.’ Your ‘worst card’ is the card which you won’t get a chance to play without lying for the longest time. This is actually trivial to calculate. When this strategy is used against three players that instead pick a random card, the player with this strategy wins 63% of the time!

The Initial Results

After over 120,000 simulated games, I got some initial results.

When bluffing, the more you lied, the more you lost.

• The Saint (avoid lying) won 51% of games (remember, since there are 4 players, the expected value is 25%).
• Mr. Pathological (lies 50% of the time) only won 2% of games.
• Surprisingly, the Closer (who didn’t lie if they could finish without lying) didn’t do well (9%).
• However, the Comeback Closer (who lied when losing) did much better (43%).
• The Game Theorist (who lied if bullshit wasn’t called much) also didn’t do as well as I expected (28%).

When deciding when to call people out, less was more.

• Players who never called bullshit won 42% of their games.
• Players who called 50% of the time only won 10%.
• I was surprised that the Accountant (who keeps track of how much each player lies) didn’t do well at all. This is probably because you don’t get too many opportunities in one game to see if someone is lying and gathering this information is expensive.
• The Salty One, which only ever called on the leader, also did well — winning 38% of their games.

You can see all the results here.

The Best of the Best

After a couple of rounds removing the worst-performing strategies, I whittled it down to the best four bluffing and four calling strategies.

The best bluffing strategies were the Saint and the Comeback Closer.

• The Saint was the better of the two; however, it did poorly (winning only 15%) against the believer (who never calls bullshit).
• The Believer (who never called bullshit) ended up being the best calling strategy (winning 39% of games).

You can see the full results of round 2 and 3 here.

This caused me to try to work out the best bluffing/calling combination strategies. I tested a few different combinations based on the results of my previous runs and found the best combination strategies:

1. Comeback Closer + The Believer (only lie when losing and never call)
2. The Saint + The Believer (never lie and never call)
3. Comeback Closer + The Salty One (only lie when losing and only call on the leader)

These three strategies in general did well, but had specific strengths and weaknesses when played against each other. This led me to create a ‘metagame’ for the best strategies.

The Metagame

Surprisingly, Urban Dictionary gives the best definition I could find for the metagame:

The highest level of strategy in many complex games, metagame refers to any aspect of strategy that involves thinking about what your opponent is thinking you are thinking.

The best combination strategy is the Comeback Closer (when bluffing) and Believer (when calling). However, if everyone you’re playing against uses this strategy, the best counter is to always lie and never call bullshit. Obviously if no one is going to call bullshit, you should always lie. This strategy is best beaten by a combination of the Comeback Closer and the Salty One (who calls bullshit every so often on the leader). Hence, we’re left with the following triangle:

Every experiment so far has also examined playing games in isolation. The metagame is even more important when playing multiple games with the same people. You can try to determine other player’s strategies and pick countering strategies.

Of course, you should only play the metagame if your opponents are! If your opponents are using random strategies, you should simply avoid lying and never call. Against random strategies from above, this combination wins 69% of games!

Conclusions

Anecdotally, I’ve never played a game where every other person was using the ‘never call’ strategy. People hate being lied to. So, psychologically, it’s really difficult not to call bullshit on someone playing a pair with a fake smirk on their face. Outside simple card games, this instinct to hate liars is a good one.

As we’ve seen here, the best strategy is to never call people out for lying. But, since no one is incentivized to stop other people from lying, this strategy allows others to lie without repercussion — a tragedy of the commons. No one is individually incentivized to stop other people from lying, which allows people to lie. Sadly, in the game ‘Bullshit,’ the heroes who stand up to the liars are often the ones to lose the game.

Therefore, if you simply avoid lying, never call, and make sure to discard the right card when you’re forced to lie (see the Tactics section above), you’ll have great winning chances.

Now you know the best way to win, why don’t you try playing against these strategies? I wrote a simple web application where you can play against a few of the best strategies: https://plivesey.github.io/bs/. Let me know if you find ways to consistently win!

Thanks to Brad Svenson, Nate Eborn, Alice Avery, Kyle and Ethan Goldblum for reviewing this post.

Kyle is the author of a fantastic game theory blog — https://www.notjustagametheory.com/.

The Game Theory of ‘Bullshit’ was originally published in Game of Theories on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reporting Assertions

Assertions are conditional checks that ensure that your code is working as expected. Likely, you already have a few in your codebase. They check conditions which should never fail, and if they do, it’s signifies a critical bug in your code. However, assertions are removed in production and have no effect in the real world. On every project I’ve worked on, I’ve added a custom Log type which makes assertions report the error in production. Most crash reporting frameworks have the ability to report non-fatal errors, so implementing this is trivial. Here’s an example using Crashlytics:

enum Log {
    static func assert(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String, file: StaticString = #file, line: UInt = #line) {
    #if DEBUG
        Swift.assert(condition(), message(), file: file, line: line)
    #else
        if !condition() {
            let domain = message()
            let error = NSError(domain: domain, code: domain.hashValue, userInfo: nil)
            Crashlytics.sharedInstance().recordError(error)
        }
    #endif
}

    static func assertFailure(_ message: @autoclosure () -> String, file: StaticString = #file, line: UInt = #line) {
        Log.assert(false, message, file: file, line: line)
    }
}

In DEBUG, the assert works as it normally does and crashes your app. But in RELEASE builds, it creates an error and reports it to Crashlytics. This will show up like a normal crash but with a non-fatal label. It even includes a stack trace!

This has been invaluable to responding quickly to bugs. A new non-fatal exception tells me that my code is behaving in an unexpected way. With a stack trace, iOS versions, and the frequency of the problem, I can start trying to reproduce the problem and fix it. Now, I’m responding to bugs before users report them or write bad reviews.

Property Tests

I’d argue that this use of assertions is a form of property testing. To write a property test:

1. You define certain properties which must hold for a certain function.
2. Then, you feed the function random input.
3. If the properties hold, then the test passes.

With assertions, instead of writing these tests explicitly, your users generate the input! Your assertions define the ‘properties’ that should always be true. Though your users don’t generate purely random input, the input is often diverse and unexpected. The best part is — these tests don’t require writing any real tests!

If you’re interested in property testing, check out LayoutTest — a framework which enables you to easily write property tests for your views. The library generates random JSON data and inflates your views with it. Then, you assert properties on your view (such as spacing is correct and no views are overlapping).

When to Assert

Assertions are underused in most iOS apps and frameworks. Incorrect assumptions about how a function will be used are a common cause of subtle bugs . My general rule is:

If there is no else statement, there should be an assertion.

For example:

guard let x = x else {
    return
}

What if x is nil? Do we need to show an error to the user? Will some infrastructure silently fail? Often, x should just never be nil. In this case, I’d add an assertion to the else statement:

guard let x = x else {
    Log.assertFailure("x is unexpectedly nil")
    return
}

This is easy to add and also helps document assumptions in the code. Here, my assumption is clear: x should never be nil.

I also add assertions for:

• Verifying function parameters are correct
• Reading from dictionaries with ‘known keys’ such as NSNotification userInfo
• Log.assert(Thread.isMainThread, "Not on the main thread!")
• Opening a critical database or file fails

Shouldn’t I Let Assertions Crash in Production?

I know some of you are thinking: ‘when you hit an assertion, your program is in an unknown state, so it’s better to crash than continue.’ In theory, this may be true, but in practice, I’ve never found it to be valid. It’s often trivial to provide a degraded experience to the user. An empty screen is better than a crash. And since you’ll be able to react quickly to the problem, a fix will be out soon. If you are developing a security framework or banking application, crashing is maybe acceptable. But for most applications, it’s unnecessary to burden your users with your mistakes.

But, I Don’t Hit Assertions When Developing

You may not hit many assertions when you are developing, but you’d be surprised at what states your users manage to get your app into. You probably don’t test your app on every device, in every network condition, with every operating system, and with every account. I have seen many assertions fire in production which I’ve never seen before in development.

Are you using a different system to track errors? Do you have other ideas for improving assertions? Let me know in the comments!

Thanks to Sanket Firodiya, Alice Avery, Kamilah Taylor, Melissa Huang, Joe Fabisevich, and Kyle Sherman for helping review this post.

Assertions in Production was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. It has a surprising but understandable solution.
2. It makes you consider what it means to be rational and logical.

The puzzle has a logical solution, but wanted to test whether actual humans would come to that solution by simulating the puzzle in real life with seven participants. But first, if you haven’t heard it before, you should spend some time to solve it yourself.

The Puzzle

Seven pirates have 100 gold coins to split amongst themselves. They have chosen an interesting way of splitting the pot.

1. The first pirate gives a proposal for how many pieces of gold each pirate will receive.
2. Then, everyone (including the first pirate) votes yes or no on this proposal.
3. If 50% or more of the pirates approve the proposal, it’s accepted and the process is over.
4. Otherwise, pirate 1 is killed and pirate 2 proposes a new way of splitting the gold and pirates 2–6 vote on the new proposal.
5. If the vote fails again, pirate 2 is killed and pirate 3 proposes a solution. It continues like this until a vote passes.

You can assume:

1. These are no normal pirates! Not only do they plunder the high seas, but they also have PhDs in mathematics and you can expect them to behave hyper rationally.
2. Each pirate wants to stay alive and get as much gold as they can. They have no ethical concerns about killing other pirates.

How should pirate 1 propose splitting the gold to maximize their gold?

Hint #1
Hint #2
Hint #3

The answer is below this awesome gif of a cat pirate.

Solution

Pirate 1 should propose giving 1 gold to pirates 3, 5, and 7 and keep 97 gold for themselves. This may surprise you, so let me explain.

First, let’s look at the simplest version of the problem. If there were just two pirates left (#6 and #7), then pirate 6 would just keep 100 gold for themselves. Since there are only two votes, pirate 7 cannot override this decision. So, pirate 7 knows that if it gets to this point, then they will get nothing.

If there are three pirates remaining, pirate 5 could offer pirate 7 just one gold for their vote. Since one gold is better than none, pirate 7 will vote yes, and the vote would pass 2 against 1. So, if it gets to three pirates, it will be split 99–0–1. We can continue this pattern for four pirates. Pirate 4 only needs one vote to get 50% of the votes, so can offer just 1 gold to pirate 6. Pirate 6 would accept since they would get nothing if it got down to three pirates. If we follow this logic all the way to seven pirates we get:

2 pirates: 100–0
3 pirates: 99–0–1
4 pirates: 99–0–1–0
5 pirates: 98–0–1–0–1
6 pirates: 98–0–1–0–1–0
7 pirates: 97–0–1–0–1–0–1

This solution seems too imbalanced to be correct, but it’s the logical conclusion of all pirates acting rationally and trying to maximize their own gold. There’s no way for pirates 2–7 to get any more gold alone by voting a different way. In game theory, this is known as a Nash Equilibrium — no player has anything to gain by changing strategies. Changing the results would rely on collusion between two or more pirates (and pirates aren’t the most trustworthy bunch

The Experiment

The correct answer is logical, but perhaps real humans wouldn’t reach the same conclusion. So, I got seven friends together and asked them to do the puzzle in real life. They played the game three times:

1. In the first game, there would be public discussion, but no private messaging.
2. In the second game, there would be no public discussion or private messaging — only voting.
3. In the third game, players could private message each other.

Everyone playing the game knew and understood the correct answer to the problem. They were all smart and rational people playing to win. The rules were the same as the riddle (except of course, we didn’t kill anyone if their vote failed; they just didn’t get any gold).

Hypothesis

As I mentioned earlier, the decision to vote yes or no by each player reaches a Nash Equilibrium, so no player is incentivized to vote differently. However, pirate 1’s strategy doesn’t produce a stable Nash Equilibrium. The equilibrium is stable if it is resilient to small mistakes. In this case, if pirate 3, 5 or 7 make a mistake and vote the wrong way, it has dramatic implications for pirate 1. So, if I were pirate 1, I’d mitigate this risk by:

1. Giving an additional pirate some gold
2. Giving each pirate a bit more than 1 gold (around 5 should do it)

The less discussion there is, the more power the first pirate will have. So in round 2, I thought that pirate 1 could probably get away with taking 97 gold. But in rounds 1 and 3, I thought that they’d only get away with about 80 gold and splitting the rest amongst four other pirates. Regardless, I thought pirate 1's vote would always pass, they would take the majority of the gold, and the games would be short.

Oh, how I was wrong…

The Games

In game 1, pirate 1 quickly proposed a vote that exactly followed the puzzle before too much could be discussed (keeping 97 gold for themselves). And then, everyone voted no.

Suddenly, the game had completely changed. Now, instead of the proposing pirate having all the power, they had all the fear. After pirate 1’s vote failed, pirate 2 ended up successfully proposing a split which only gave them 30 gold. They were now convinced that the equilibrium was extremely unstable and needed to give significant gold to three other pirates to get just two votes.

In game 2, there was no discussion allowed. Pirate 1 clearly felt the fear of being in the first position and proposed an insane 10 gold for themselves and 15 gold to each other pirate. In this case, pirate 1 is actually getting less gold than the other players. I thought they could have easily asked for more, but the vote only passed with the minimum required four votes.

In game 3, there was a public discussion as well as private messaging. This game was nuts and I must leave out a lot for succinctness. First, pirate 1 proposed a 37/21/21/21 split which failed. The player who turned down 21 gold ended up getting nothing at the end of the game, and hence, the theme of the last game was hubris. In several cases, players backchanelled with other players and voted no thinking they’d end up with a better deal. Then, they’d see their plans backfire and end up with nothing.

In the second round, pirate 5 was granted 30 gold, but had an offer for 31 gold if they voted no. Again, hubris took over and they voted no, only to end up with nothing at the end of the game. The game finished in the 4th round with a 60/40 split between pirates 4 and 7.

Conclusions

In all three games, pirate 1 never got the 97 gold the brainteaser promised. In fact, it was the worst position to be in (two deaths and 10 gold). Fear and hubris quickly overtook the cold logic of the puzzle to produce a dynamic game in which every player thought they had a shot at winning more. The number of pirates also made reasoning through strategy difficult. With 3–4 players, the optimal strategy quickly becomes clearer, but with seven pirates, it seemed like anything could happen. Hence, the game relied much more on short-term tactics, fear, hubris and a bit of luck.

The theoretical solution to the problem is logical, but are the pirates really behaving rationally? The problem assumes that the pirates are emotionless, greedy algorithms who grab as much gold as they can. But people may be willing to take a risk if they don’t value a single gold coin highly. If the value of a coin is low, then the difference between 1 coin and 0 coins may be inconsequential. In this case, pirates may be tempted to vote no on the first round to see if other pirates feel similarly.

The theoretical pirates also appear heartless and have no concept of fairness. In the real life experiment, players voted no and forfeited gold to punish an ‘unfair’ result. This persuaded other pirates to ‘behave’ and propose more even splits. This bias toward fair outcomes suggests that aren’t always happy with the logical, mathematical solution. Sometimes, the optimal solution is not a human solution.

Thanks to the seven pirates — Brad Svenson, Hari Arul, Camilo Cabrera, Jason Zhang, Charles Huyi, Patrick Costello, and Dawson Zhou.

The game was a lot of fun to play — let me know if you try the game yourself!

Thanks to Alice Avery And Dawson Zhou for helping me review this post.

Pirates with PhDs was originally published in Game of Theories on Medium, where people are continuing the conversation by highlighting and responding to this story.

A couple of months ago, my chess puzzle app was struggling to retain new users. I loved the app, and many of my users did too, but, most people who downloaded the app wouldn’t use it more than once. So, I decided to build an onboarding experience for all the lost users.

Today’s users are more discerning than ever, have more options, and have shorter attention spans. When you look at your product, you may see a useful, beautiful, fun app which is great at solving a specific problem or need. But when new users see your product, they see a menu with too many options, a login screen trying to steal their email address, and a learning hurdle they need to overcome.

I followed five steps which got me to an onboarding experience I was proud of:

1. Dissect your current onboarding
2. Make your users successful ASAP
3. Bucket your users
4. Test it on real users
5. Measure your success

1. Tear it apart

It’s hard to critique your own work, but it’s a valuable skill to foster. I was inspired to take this step seriously by useronboard.com. The site has done incredible teardowns of many famous products and does a fantastic job showing what works and doesn’t work when onboarding new users. I’d highly recommend going through several of their slideshows before taking a look at your own product.

So, here is my teardown of my old app with all its flaws. I hope you find it brutal enough.

There’s obviously a lot to improve, but the top things I decided to fix were:

1. Persuade the user the app is worth their time before asking them to sign up.
2. Set up each user for success, not failure.
3. Minimize choice when users first use the product.

2. Make your users successful ASAP

Great products aren’t just powerful; they make people feel powerful. Your product should transform your user into a better version of themselves. This could be making them more productive, more informed, or simply happier. You need to identify the earliest moment that people feel this emotion.

For us, this action was completing a difficult puzzle correctly. Chess is a hard game, so this is no easy feat. But when users overcome this challenge, they realize they’ve become something new — a smarter chess player. This transformation will persuade them to keep using the app.

Currently, the app requires users to sign in before even attempting a puzzle. Instead of this, I rewrote how login worked to allow people to play puzzles without signing up. I only ask them to sign up after they’ve successfully completed a puzzle. But, the order of these actions is only half the problem. As I said, chess is a difficult game, and many users aren’t yet capable of completing a difficult puzzle. If the app gave them a difficult puzzle immediately, they’d be set up to fail.

3. Bucket users

When an experienced player comes to the app, they want to be challenged. But, if the first puzzle the app gives users is too difficult, beginners will fail. So, I had to design different experiences for beginners and experts. This is the first screen for a fresh install:

A couple of things to note:

1. This screen has only three options so the user won’t be overwhelmed for choice.
2. Users are often nervous about picking wrong and then having to restart. The help text at the bottom should help these users realize that this decision won’t ruin their experience if they pick slightly wrong.

Likely, your user cohorts will be different. If you’re a music discovery app, you might bucket users into those who are looking for specific music and users who want to explore new music. For a reading app, you may split your users into fiction readers, nonfiction readers or other genres. Just make sure you don’t make the mistake that Apple Music and many other apps make which overload their users with options. People are way more willing to enhance their profile after they see value than before. You should bucket them just enough to get them to that key experience you’ve identified.

If a user is a beginner, they start with some interactive lessons which teach them how to solve chess puzzles. If the user is advanced, they go straight into tough and interesting puzzles.

4. User Testing

Once you’ve built a first version of your onboarding, you need to test it on some real people! You’ll be shocked at how difficult people find things which you think are easy. The best way to do this testing is in person. You won’t understand how people are using your app unless you actually watch them. Find some friends who haven’t used the app, sit down with them and ask them to start using the app. Likely, they will quickly ask you questions on how things work or what they should be doing. Resist the urge to help them! Instead, simply reply with more questions like:

“What would you do if I weren’t here?”

“Do you see a way of answering that with the product?”

Every time they ask you a question, it shows a weakness in your onboarding flow. New users have no loyalty and will quickly revert to using other apps at the first sign of trouble. Candy crush is just a few taps away and you only have one chance to convert each person. On one of the user tests I did, I wrote down twenty-nine places the user could have dropped out! Each problem was just a small fix such as writing clearer copy or adding a tooltip.

5. Measure success

When you release your new experience, you’ll want to see how much better you’re app is doing. You should identify a few metrics which you expect to improve after the release. For my app, I wanted to improve 1-day and 7-day churn as well as have more users attempt at least one puzzle. You don’t need to overdo it here and track every user action as they onboard. Just track a few key flows and try to find where users drop off.

We’ve only just released the new update, so I don’t have much data yet. Early results suggest that day 1 retention has approximately doubled. I’ll update this post once we have more to share!

Update: It’s been a little over two weeks since we released the new version and day 1 retention has remained bullish (increasing by about 2.5x). However, day 7 retention has only increased by about 50%. This is still a great improvement, but I think I can do even better. Since most of my work concentrated on the first few days, this isn’t that surprising. Next, I should look at keeping the user engaged a week or more after they’ve used the product.

Try it for yourself

If you’re looking for ideas, want to learn something new, or just have some fun, check out what we’ve done. You can download the new Chess Tactics & Lessons on the App Store, and let us know what you think of the onboarding process in the comments.

Thanks to Alice Avery, Nick Snyder, Islam Sharabash, Judy Logan, Ryan Blunden, and Joe Kramer for your help on this post.

5 Steps to a Better Onboarding Experience was originally published in Device Blogs on Medium, where people are continuing the conversation by highlighting and responding to this story.

HORSE is a popular basketball game where players take turns attempting the same shot. With two players, the game works like this:

1. Player A attempts any basketball shot.
2. If they make it, then player B has to make the exact same shot. Otherwise, it’s player B’s possession.
3. If player B misses, they acquire a letter. Either way, Player A gets to shoot again.
4. Letters are acquired in order: H-O-R-S-E. Once a player acquires all five letters, they are a horse and lose the game because horses can’t play basketball.

It’s a simple game, but strategy isn’t well understood by most players. I wanted to dig into the metagame of HORSE and work out if there are optimal ways to play using game theory, strategy, and a little math. Of course, being better at shooting will always be advantageous, but let’s take a look at the decisions you can make.

The Setup

There’s only one element of strategy in the game — shot selection. You could take a free throw, a layup, or a left-handed, eyes-closed, 3-pointer skyhook. Conventional wisdom is to take a shot that you’re good at but that your opponent will probably miss. For instance, Steph Curry can just attempt three-pointers and watch his opponent miss.

For a given shot, there’s a probability that you make the shot and a probability that your opponent makes the shot. Given these values, we can calculate the expected value of the number of letters your opponent will get on your possession (or the average number of points on each possession if you were to play it many times). The best strategy maximizes this expected value. Remember, in HORSE, a possession lasts until you miss. So, you could have multiple shots per possession.

E = expected number of letters your opponent gets on your possession
p = probability that you make the shot you select
o = probability that your opponent makes the same shot

In order to give your opponent a letter, you need to make a shot and your opponent needs to miss their shot. The probability of this is:

p(1 - o)

This is also the expected value of letters your opponent gets on one shot. But, if you make it, then you get to shoot again. The expected value of future shots is the probability you make the first shot multiplied by the expected number of letters your opponent gets on a possession (since if you make your shot, you’re in the same situation as if you just started).

p * E

To get the expected value of letters your opponent gets in an entire possession you just add the expected value of the first shot and the expected value of future shots.

E = p(1 — o) + p * E

Then, we can solve for E:

E — p * E = p(1 — o)

(1 — p)E = p(1 — o)

E = p(1 — o) / (1 — p)

Now, we have a formula for the expected value of a possession based on the chance you can make a shot and the chance your opponent makes the same shot.

A Basic Scenario

Let’s assume both players have the same skill and ability for all shots. So, if Player A has a 40% chance of making a shot, then Player B also has a 40% chance of making that same shot. This is a big assumption and is never true in practice, but it’ll reveal whether shot selection makes a difference. We’ll look at some more complex scenarios later.

Player B’s strategy is to repeatedly take shots with a 50% make rate. Let’s look at the expected value of that strategy.

E = p(1 — o) / (1 — p)
Solving for p = 0.5 and o = 0.5

E = (0.5)(1 – 0.5) / (1 – 0.5)

E = 0.5

Since the expected value is 0.5, on every turn for Player B, Player A will get on average half a letter. This means Player A is likely to get H-O-R-S-E in 10 turns.

Optimizing for Player A

Let’s generalize this for any shot and try to find the optimal strategy. In this scenario, p = o (the probability you each make a shot is equal), so we can just substitute it in the formula:

E = p(1 — o) / (1 — p)

E = p(1 — p) / (1 — p)

E = p

The expected value of a certain shot is equal to the probability of making that shot. To maximize E, you just need to maximize p. This means you should always choose the easiest shot you can! Just keep taking layups and hope your opponent misses before you do.

If you keep taking a shot that has a 99% chance of making your shot, the expected number of letters your opponent will get per possession is 0.99 which means your opponent will lose in about 5 possessions. So this strategy is twice as good as selecting a 50% shot. Just keep attempting layups, and you will have an optimal strategy.

What if you are much better at shooting three-pointers?

The previous scenario assumed equal abilities, which, of course, is never true. Let’s assume that you’re playing against Steph Curry who dominates three-pointers. Steph has a 40% success rate, and you have 10%. You both have a 99% chance of making a layup (probably low for Steph, but let’s go with it). Since Steph is 4x more likely to make a three-pointer, surely that’s a better shot to take, right? We know that the expected value for the layup is 0.99. The expected value for the three-pointer:

E = p(1 — o) / (1 — p)

E = (0.4)(1 – 0.1)/(1 – 0.4)

E = 0.6

If Steph Curry were to shoot three-pointers, you’d get on average 0.6 letters per turn. But, he’d be getting 0.99 letters per turn! So, even if you have a much better chance (4x) of making that three, the layup strategy is still better! It turns out that keeping possession (making your shot and shooting again) is much more important than ensuring a better shot than your opponent.

So wait…did I just ruin HORSE?

Personally, I was disappointed by my results. It looks like I’ve reduced a great game to a layup competition which stretches on for hours. So, I feel obligated to try to fix the game. I have three suggestions:

1. Don’t allow the player to keep the ball if they make their shot

The main problem is that the player with the ball keeps the ball if they make it. Let’s take a look at what would happen if we remove this rule. This means the expected value is simply:

E = p(1 — o)

If you have two identical players, then this simplifies to p(1 — p) and the graph for p vs E looks like this.

E is maximized at 0.25 when p is 0.5, so the optimal strategy is to take shots with a 50% make-rate. That’s already sounding like a better game. If you’re four times more likely to make a three-pointer (like Steph Curry in our previous example), then E becomes 0.36. This better outcome would reward being a better three-point shooter. With this rule change, we’re much closer to making the strategy result in a fun game. But sadly, low percentage shots are still not a good idea — meaning your patented 360º, underhand, off-the-backboard, ten-foot jumper is still far from optimal.

2. Set different point limits for different shots

If you assign more letters to harder shots, there would be a higher incentive to try shooting them. For instance, if you make three-pointers worth double (two letters instead of one), then the expected value from our earlier example becomes 2 * 0.6 = 1.2, making it slightly better than the layup strategy where the expected value is 0.99. You could also ban easy shots (requiring a minimum distance).

However, these approaches are not practical. Assigning a letter value to every shot is difficult and subjective. Also, some shots close to the basket are difficult even if they’re close (e.g. shots from behind the backboard).

3. Just play the game

Maybe the best solution is to ignore everything in this article and just play the game. Is it really that important to win HORSE? Maybe you should play for the beauty of the game. Maybe you shouldn’t subject your friends to 200 layups in a row. You could optimize by taking the easiest shot every time, but maybe the real goal is to become the legend who makes that behind-the-back, eyes-closed, half-court shot.

If you have any better ideas for how to fix HORSE, please let me know in the comments.

Thanks to Alice Avery, Brad Svenson, Hari Arul, Ranee Bhutani, and Alastair Livesey for your feedback and comments.

The Game Theory of HORSE was originally published in Game of Theories on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post describes several techniques to debug closed source libraries such as UIKit.

As we’ve pushed iOS to its limits, we’ve found some inscrutable runtime bugs. In order to solve these, we’ve had to dive into the deepest internals of UIKit.

Since UIKit is closed source, we can’t place breakpoints or view the code. However, as we’ll see, nothing in Objective-C is really private.

In this post, we’ll cover:

• Reading private variables
• Swizzling to see property changes
• Watching memory to observe instance variable changes

Most of these examples are based on UIKit, but the techniques apply to any private Objective-C framework.

Reading Private Variables

Look at the Runtime Headers

The UIKit source code is not public, but we can read its runtime headers (.h files) to see method and variable names. The method names hint at their implementation, and importantly allow us to call them.

A few sites index the runtime headers. For example limneos.net, which can also search specific iOS versions.

If we are having trouble with a certain property or method in a class, we can search the header file for related methods.

Calling Private Methods

Once we find an interesting private method, it’s useful to print the result from the debugger. For instance UITableView has a private method: -(id)_delegateActual. We can’t run this in Swift, because Swift does not allow the calling of private methods:

(lldb) po tableView._delegateActual()

error: <EXPR>:3:1: error: value of type 'UITableView' has no member '_delegateActual'

However, in Objective-C, we can run arbitrary selectors on any object. We can get the pointer for the object, and then run an expression in Objective-C:

(lldb) po tableView
<UITableView: 0x7ff960053200; frame = (0 0; 375 812); clipsToBounds = YES; gestureRecognizers = <NSArray: 0x604000249e40>; layer = <CALayer: 0x60400003f880>; contentOffset: {0, 61}; contentSize: {375, 1320}; adjustedContentInset: {88, 0, 34, 0}>

(lldb) e -l objc -O -- [0x7ff960053200 _delegateActual]
<TableViewExperiments.ViewController: 0x7ff95ec1d7d0>

In this example:

• e is short for expression which runs code and prints out the result
• -l sets the language to Objective-C
• -O specifies that this is an object, so the command should dereference the pointer before printing it out

If you’re printing a primitive, simply omit -O.

(e -l is useful in other contexts too. e -l Swift allows you to run Swift code even when your stack frame is Objective-C.)

Reading Private Instance Variables

Let’s say we find a private instance variable that we want to read. In modern Objective-C, properties are much more common than instance variables; we can simply use the above technique to run the private getter or setter methods backing the property. However, in UIKit, instance variables without properties are common and so are much harder to debug.

Recently, we were interested in the _firstResponderIndexPath property on UITableView. This property appears to be set whenever a cell in UITableView becomes the first responder. To read this variable, we can’t use the above trick because _firstResponderIndexPath is an instance variable:

(lldb) e -l objc -O -- [0x7ff960053200 _firstResponderIndexPath]

error: Execution was interrupted, reason: Attempted to dereference an invalid ObjC Object or send it an unrecognized selector.

The process has been returned to the state before expression evaluation.

However, nothing is really private in Objective-C. We can use the runtime to access any instance variable, even if it is private. First, we need to query the class for the Ivar object. Then we can query the instance for the value of this instance variable:

(lldb) po object_getIvar(tableView, class_getInstanceVariable(UITableView.self, "_firstResponderIndexPath")!)!

<NSIndexPath: 0xc000000000600016> {length = 2, path = 0–3}

Swizzling

It is useful to call and read private methods, but it is often more useful to see when these values change. Swizzling allows us to add breakpoints, examine the stack, and get clues on how features are implemented.

We want to know when a property on an object is changing. The easiest way to do this is to swizzle the setter. Swizzling is an Objective-C runtime technique to exchange method implementations. We replace the existing method with a new method, print the new value, and then call the old method. We effectively insert some debug code between the call site and the actual implementation of the method. The confusing part is this: in order to call the old method, we must call the new method’s signature, since we’ve exchanged their names. It looks like this:

extension UIScrollView {
    class func swizzleZoomScale() {
        let originalMethod = class_getInstanceMethod(self,
            #selector(setter: minimumZoomScale))
        let swizzledMethod = class_getInstanceMethod(self,
            #selector(swizzle_setMinimumZoomScale(_:)))
        method_exchangeImplementations(originalMethod!,
            swizzledMethod!)
    }

    @objc dynamic func swizzle_setMinimumZoomScale(_ scale: CGFloat) {
        print("new value: \(scale)")

        // It looks like we're entering an infinite loop,
        // but exchangeImplementations has switched the method’s 
        // names. So this method signature now maps to
        // the original minimumZoomScale implementation

        self.swizzle_setMinimumZoomScale(scale)
    }
}

In this case, we wanted to know when the minimum zoom scale changed. First, we call swizzleZoomScale() exactly once (for example, from UIApplicationDelegate). Then, we put a break point in the swizzle_setMinimumZoomScale. Whenever setMinimumZoomScale is called, the breakpoint will hit. We will then have a full stack trace to examine where and why the zoom scale changed.

Swizzling Private Methods

If we are trying to swizzle a private method, the above code won’t work; it cannot find the selector we want to replace. There’s an easy fix though. We just create an Objective-C category on the object and add it to the interface. We don’t need to implement it; we just need to let the compiler know it exists.

@interface UITableView (Private)

- (void)_applePrivateMethod;

@end

With this, we’ll be able to swizzle _applePrivateMethod.

Watching Memory

If we want to know when a property changes, we can simply swizzle the setter. However, many UIKit variables are not backed by properties but are instead set directly. Swizzling won’t help in this case; we must watch memory directly.

We can listen to any variable with the watchpoint command in lldb:

(lldb) watchpoint set variable self.counter

This will hit a breakpoint whenever counter changes value. However, this doesn’t work for private instance variables, since self.counter would not be accessible. To get around this, we can find the memory address of the instance variable.

Consider again the private instance variable _firstResponderIndexPath. This is set when a cell in UITableView becomes the first responder. First, we ensure the value is not nil, and then we print it out:

(lldb) po tableView
<UITableView: 0x7fefb482da00; frame = (0 0; 375 812); clipsToBounds = YES; gestureRecognizers = <NSArray: 0x604000249e40>; layer = <CALayer: 0x60400003f880>; contentOffset: {0, 61}; contentSize: {375, 1320}; adjustedContentInset: {88, 0, 34, 0}>

(lldb) po object_getIvar(tableView, class_getInstanceVariable(UITableView.self, "_firstResponderIndexPath")!)!

<NSIndexPath: 0xc000000000400016> {length = 2, path = 0 - 3}

This is useful, but it’s not the memory we want to watch. To find the correct address, we need to understand how Objective-C puts classes on the heap. When we have a pointer to an object, that memory points to the start of a blob of memory with information on that instance. The first word contains the isa pointer, and after that are the instance variables of the class (see more in Apple’s documentation). It looks like this:

At some offset from the UITableView pointer is the memory representing _firstResponderIndexPath. Its value is the pointer to the IndexPath. When _firstResponderIndexPath changes, it will look like this:

The memory at 0xc0000000000400016 won’t change since it’s an immutable object; there’s no point watching that. Instead, we want to watch the memory at a specific offset from our UITableView pointer. This will always be the same offset, but we need to find it. Let’s look at a memory dump around this pointer.

To view memory in Xcode, go to Debug → Debug Workflow → View Memory. Set the address to the pointer for the UITableView (in this case 0x7fefb482da00) and set the number of bytes to 4096. Now, we need to search for the value: 0xc0000000000400016. Using Cmd+F, we can see it highlighted in the middle of the dump:

Notice that memory is laid out backwards in this view, so the value reads 16 00 40 00 00 00 00 C0. Using the memory location values on the left, we can see that this value is at address140667502387512 (0x7fefb482e138).

Let’s try watching this address. (Note: this command doesn’t work if you’re in a Swift frame. To make it work, change your stack frame or use the pause button.)

(lldb) watchpoint set expression -- (void*)0x7fefb482e138
Watchpoint created: Watchpoint 1: addr = 0x7fefb482e138 size = 8 state = enabled type = w

new value: 0xc000000000400016

In the app, let’s do something which we think will change this value. In this case, we set a different cell to be first responder. As soon as we do this, the breakpoint hits and we can see a backtrace. Often the breakpoint will hit twice: once when the value is set to nil, and again when the new value is set.

Finding the exact offset can be difficult, but we need only do it once. The instance variable is always at a constant offset. In this case, the table view was at 0x7fefb482da00 and the instance variable was at 0x7fefb482e138. The offset here is 1,848. We can now take any UITableView pointer and add 1,848 to get the pointer for the instance variable _firstResponderIndexPath.

(lldb) po tableView
<UITableView: 0x7ffd0d027800; frame = (0 0; 375 812); clipsToBounds = YES; gestureRecognizers = <NSArray: 0x600000053e60>; layer = <CALayer: 0x60000002f800>; contentOffset: {0, 93}; contentSize: {375, 1320}; adjustedContentInset: {88, 0, 34, 0}>

(lldb) po 0x7ffd0d027800 + 1848
140724821720888

(lldb) watch set expression -- (void *)140724821720888
Watchpoint created: Watchpoint 1: addr = 0x7ffd0d027f38 size = 8 state = enabled type = w

new value: 0x0000000000000000

Conclusion

Every ambitious project will encounter critical bugs in runtimes and frameworks. Sometimes, as with UIKit, those libraries will be private and closed source. Normally, this would be game over.

However, by reading private variables, swizzling property changes, and watching the right parts of memory, we can almost always find workarounds. We’ve successfully used these techniques to track down some otherwise showstopper bugs!

— Peter Livesey, Lead Engineer, Superhuman

At Superhuman we’re rebuilding the email experience for web & mobile. Think vim / Sublime for email: blazingly fast and visually gorgeous.

Thank you to Akram, Marin, Colin, and Cezary for reviewing drafts of this post.

If you love solving interesting problems in elegant ways — join us! Learn more or email us.

Advanced Swift debugging for UIKit was originally published in Superhuman on Medium, where people are continuing the conversation by highlighting and responding to this story.