Top-notch video tutorials for Swift developers

The first step to use Mastodon is to select your instance. You can browse a public timeline of that instance or you can log into that instance to see your own timeline. In this episode we will create a simple instance selection UI. We'll then use animated transitions to switch to the timeline view. Gui teaches us a new tip about debugging animations.

If you're using CocoaPods already, then mixing with Swift Packages can prove to be infeasible. You can create your modules as internal pods as well, however there are a few gotchas. In this episode I will cover how to do this, how to link up local pods and create example projects for demo UI and running tests, as well as how to overcome some of the rough edges you might experience.

Now that we've seen how to setup a feature module, we'll also need to decide how best to share a feature's resources and deal with dependencies.

In this episode we create a modularized setup where our modules are Swift Packages and brought into the main app using Xcodegen and local path references to the packages.

One thing that can be a pain when splitting modules up into separate projects is maintaining the Xcode projects themselves. Not to mention the fact that as team sizes grow, merging changes in project files gets exponentially more painful. In this episode we will look at using Xcodegen to have a repeatable project generation that you can use to create consistent Xcode projects without much fuss.

Breaking your code into discrete modules will surface a problem if your code is tightly interconnected. Once you've defined your module boundaries you now are forced to not cause bidirectional dependencies. In this episode we will look at some strategies for breaking apart dependencies into abstractions first using protocols, then using protocol witnesses. We can then depend on those abstractions in our isolated module projects.

One way of achieving modularization is to build frameworks using nested Xcode projects. This has the benefit of having everything in one place and can easily build the entire thing. You can also zero-in on a single project and just work from there if you want. Each sub-project can have its own tests, sample application, etc.

In this episode we will talk about the overview and motivation for a modular project architecture. Why split things up? I'll talk about the problems we face, what benefits we may achieve, and how can we approach the problem.

Managing dependencies can be a pain. Unless you're using shared instances accessible everywhere, you end up having to pass along dependencies from class to class. One strategy for decoupling your types from external dependencies is to create protocols and "inject" the actual concrete implementations at runtime. This enables you to test them easily and also isolates library-specific APIs from the rest of your application. This can make switching between libraries more feasible. In this episode we'll take a look at a library called Resolver that does this. Technically it implements Service Location rather than Dependency Injection, but the result is similar.

So far in this series we've been using CloudKit directly from our controllers. This can be somewhat limiting. It requires you to be online or everything fails, we may want to add a caching layer, or we might want to use CloudKit as a network synchronization layer, rather than a primary data store. In this episode we'll examine an architecture that will allow you to decouple your view controllers from CloudKit as a first step to achieving more flexibility with your CloudKit implementation.

In the refactoring series, Soroush mentioned a protocol he uses to make initializing view controllers from a storyboard as easy as adopting a protocol (and completely type-safe). In this episode we will build this using Swift protocol extensions. The end result is something you can easily carry with you from project to project.

This episode wraps up the refactoring series by implementing the transition to the PhotosViewController. Ben and Soroush talk about the overall process and benefits of coordinators as a pattern to clean up view controllers and organize logic around how your app is stitched together.

Moving on to the next segue in our storyboard, this time Ben and Soroush tackle the Add Review flow. They discuss naming of delegates, the ideal place to perform logic such as preparing a model to be saved and where mutations to the model live. They end up with a view controller that is completely decoupled from the AddReviewViewController and a better picture of what the coordinator tends to look like.

In this episode, Soroush and Ben create the first delegate for a view controller in order to pull out the behavior a user might trigger by interacting with the view controller. This delegate conformance is added to our coordinator so this flow logic is in one place (and not in the view controller).

What is the Coordinators pattern, and why is it useful? Soroush and Ben discuss this and then get started refactoring an existing application that uses Storyboards into using Coordinators. We implement our first AppCoordinator and wire it up on launch.