Top-notch video tutorials for Swift developers

The built-in way of adding constraints in code requires quite a bit of code and is a bit cumbersome to write. I believe that we should aim to reduce friction when writing code like this to make it easier to add new views and change your layout. SnapKit is a pretty useful dependency that gives you a DSL for making autolayout constraints. In this episode we'll integrate SnapKit into the project and simplify our existing layout code.

If you look at our view controller now, it is full of code that mostly is dealing with constraints, subviews, and overall layout. This is really the job of the view. In this episode we will extract this into a new view class. We'll also introduce a reusable base class that will handle the required view initializer dance for us, making the job of creating custom view classes a bit easier.

Now that we have some streaming output from the ffmpeg process, we can take this and create a custom progress bar. Since this could useful in other utilities we can create it as a separate Swift package and import it using a local file reference.

When dealing with long running tasks it would be nice to be able to gather output as the task runs and not hang until the entire process is done. In this episode we will extract some useful information out of ffprobe, so we can get the total number of frames in a video file, and then kick off ffmpeg to encode the video. We'll use the Subprocess package to provide a simpler interface over gathering output from a pipe as it is sent, rather than waiting for the end.

I use a collection of command line scripts that help me in the production of NSScreencast episodes. Most are written in Ruby, which is a language I know and love, and some are written in bash, which is... a language. I sometimes wonder what these scripts would look like if I were to write them in Swift. So in this new series I'm going to explore rewriting a script that I use to encode videos using Swift. In this episode we'll bring in the excellent Swift Argument Parser library and use it to give us a clean and consistent command line interface to start with.

Foundation has a wonderfully useful support for dealing with measurements like distances, durations, temperatures and more in Swift. The Measurement class combines with a Unit type to constrain the measurements into their own domains. With this you can get functionality like conversion and addition. With MeasurementFormatter we can format these values for display in our UI based on the user's locale. In this episode we will explore how to use this API, how to extend the existing dimensions to add new measurement values, and how to create your own domain of measurements. For this we will model Throughput of Items in the game Factorio.

Property wrappers are turning out to be super useful! In this video we'll look at an open-source library called ValidatedPropertyKit, which gives you property wrappers for validating user input. With it you can check for ranges, non-empty strings, regular expressions, or extend it with your own.

Swift 5.1 introduced a powerful new feature to the language: Property Wrappers. In this video we will take a look at how to write property wrappers and how to use them to simplify code in our apps.

In the last episode we had a bit of an issue... I was trying to store an enum value in UserDefaults, thinking it would automatically use the backing rawValue to store and load the value. Unfortunately this doesn't work. In this episode we fix this issue and extend our solution to also accommodate other data types by leveraging Codable and a custom protocol.

UserDefaults is quite a handy class for storing user user preferences and lightweight data. However the data is keyed by strings and there's no enforcement of any schema or validation of the data you put in it. In this episode we will look at a technique for making strongly typed access to data in UserDefaults so that we can avoid mistakes when typing the key name or the type of data intended to be written to that key.

Before Swift 5 we used to write our own Result type to contain a value or an error (but never both). A lot of 3rd party libraries brought along their own as well. Then Swift 5 came and brought us Result. Not only is it slightly different than the ones we might be familiar with, Swift's Result type also has some useful functionality up its sleeve.

Sending notifications in your apps is a great way to signal events without having tight coupling between the interested parties. However, in practice this means creating notifications using string names, and passing data as an untyped dictionary means there is opportunity for misspellings and misunderstandings in what data will be passed for which notifications. This can lead to bugs and crashes. In this episode we'll look at creating a more Swift-friendly type-safe wrapper around notifications.

You may encounter a scenario where you want to decode some JSON that contains an array of objects that may be of a different type. In this episode we examine such a scenario, where we have a feed that contains an array of posts, but each post object can be of a different kind, such as text, image, or video. We will take a look at how to solve this by introducing a protocol called DecodableClassFamily, and along with a Discriminator that will inform the decoding logic which type it should decode. We'll then take this working example and make a reusable solution using Swift Generics.

We continue our mini-project to create a Swift script that automatically creates migrations for Vapor projects. In this episode we save the generated templates to disk, render a generated extension so that we can add these migration types to the Vapor service, and see the example running end-to-end.

Usually I lean on Ruby or Bash for writing command line scripts, but it is becoming increasingly more viable to use Swift for this as well. In the Vapor series, I wanted to write a little script (in Swift) that would generate migration files for me so I wouldn’t have to maintain this myself. For this, I used the Marathon tool, which helps alleviate some of the machinery necessary to use Swift in this way. And what better way to explore this tool than with this author guiding me along. John Sundell joins me in this episode to use Marathon and Swift to write a useful script for Vapor applications. This is a longer episode, so it is split into two parts. Enjoy!

Sometimes when using a functional style to iterate and transform data we can inadvertently make the performance and memory usage much worse. In this episode we will see how we can take a standard procedural iteration, convert it to a functional style, and then utilize lazy to avoid some of the pitfalls that we sometimes run into.

Swift 4 key paths allow us to refer to properties of Swift types in a dynamic way, enabling us to program against them without knowing the exact property in question. In this episode we will see how they are created, how they are used, and see examples of them in action with Key-Value Observing and Autolayout.

In this episode we cover the dependency inversion principle, which states that high level components should not depend on low level components, but instead they both should depend on abstractions. We will look at two examples of this and leverage dependency injection to decouple classes from concrete dependencies.

In this episode we examine ISP (the Interface Segregation Principle). This one states that a type should not depend on methods from an interface that it will never use. Often times this means that the type probably carries too many responsibilities, but breaking it apart is difficult for other reasons (perhaps too many things depend on it and changing it would be expensive). You can extract smaller interfaces that support the individual responsibilities, but still have the same class adopt it. Doing so opens up opportunities for further refactoring and testing.

In this episode we examine the Liskov Subtitution Principle, which stresses the importance of the strong relationship a type has with its super type. Understanding LSP can help you identify when you are missing an important abstraction, or perhaps when inheritance is being abused as a tool.

The Open Closed Principle (or OCP) states that a class should be open for extension, but closed for modification. The goal is to write classes that are more stable, and don't require constant changes themselves to support every scenario the software encounters. Instead, having a stable class to inherit from can provide a nice extension point for our software to customize it for other needs.

In this episode we'll examine a type that has too many responsibilities and refactor it into multiple types, each with their own responsibility.

This episodes kicks off a new series on SOLID principles for improving at object-oriented design. Writing better code means writing code that costs less to change, which can be a crucial factor in delivering project successfully. In this series we will see how these principles apply to Swift.

In this episode we continue with our caching example, this time introducing a new type that will handle the caching for us, as well as wrapping the response type into a new type that will indicate to the view controller if the response was served from the cache or from the network. We end the episode by implementing Equatable so that our store can avoid needless double callbacks if the data has not changed.