In this tutorial, we'll see how we can use protocols to make custom view subclasses more generic. The benefit is that they'll be easier to test and reuse, and our code will be easier to read and maintain.
In Part 1 we saw how to install Vapor and create an Xcode project using the default `api` template. That project comes with a lot of code demonstrating the basics of building an API in Vapor. It uses SQLite as the database and a `Todo` model and controller as an example. Our app will eventually use PostgreSQL . . .
Vapor is a web framework for Swift. It runs on macOS, iOS, and Linux, and can be used to build websites, web applications, and APIs. Frameworks like Vapor make it possible to build entire products in Swift, including a backend, web app, marketing site, and Apple device app (iOS, macOS, tvOS, watchOS).
The `Hashable` protocol in the Swift Standard Library allows us to use our own custom types as a key in a dictionary or as a member of a set. Conforming to `Hashable` where appropriate can make our code safer and improve performance. However, it's important to understand how `Hashable` and `Equatable` work together . . .
In the last tutorial, we saw how to generate code coverage reports using the new `xccov` tool. Part of that process is using the `xcodebuild` command to build a project with code coverage enabled. We ran that command directly in Terminal, but we could also run `xcodebuild` in a Swift script. The problem is `xcodebuild` takes time, and . . .