Top-notch video tutorials for Swift developers

One of the benefits we can get by programming to protocols and leaving our concrete implementations isolated, is that we enable swapping out these dependencies for different ones for use during tests. Doing so will require us to restructure our app setup a bit so we can have a completely separate AppDelegate and SceneDelegate for use in testing. With this setup we can control the environment completely. We'll setup mock dependencies that we can verify that the interaction with these dependencies is as expected.

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.

Using Item Anchors we can position decoration views anchored to our layout items. This is could be used to outline or underline items, or in our case to add a little unread indicator badge to our items.

Not every layout will be appropriate for every screen size. In this episode you'll see how you can use the layout environment when constructing your compositional layout to provide a more suitable layout for iPad.

One of the things you'd get for free with UITableView in the grouped style is a nice rounded rect background around your sections. With UICollectionView, you can implement these with background decoration views. We'll see how to set these up in our compositional layout to give the series section a different feel.

Our Diffable Datasource and snapshots are generic over the type of data that we pass to the cells. So how can we make sections with completely different data? In this episode we'll cover one approach which involves defining an enum with associated data for each of the sections. We'll use this to add a Series strip of data mixed in with our collection view.

In this episode we'll make a custom header view to give some of our sections a title. The approach we use here with compositional layout is more flexible than with UITableView. We'll start with a UICollectionReusableView implementation for our header, add the desired item to our layout, and then vend the desired view using the datasource's supplementaryViewProvider.

Diffable datasources provides a great API for driving your collection view updates in a transactional, state-driven way. We no longer have to manually call insert/delete/move rows when the data is changed. Instead, we apply a new snapshot and the changes are made for us, including animations.

First introduced in iOS 13, UICollectionViewCompositionalLayout is an amazing and powerful addition that gives you lots of flexibility when describing layouts. There are a few new types to get used to (namely sections, groups, and items) but they all work together allowing you to keep layout separate from your views and your data.

With UITableView no longer being encouraged for use, we need to replace this behavior with UICollectionView. This is where UICollectionViewListLayout comes into play. Using this layout we can get the familiar table view appearance in plain and grouped styles (as well as additional styles to support sidebars on iPad and macOS). This includes support for sticky headers and footers, swipe actions, and other UITableView behaviors that we've come to rely on.

In this episode we migrate our collection view to use the new cell registration API. Using this API we no longer need to cast dequeued cell types to our custom types. Instead, we set up the registration object with the cell type and the data we'll be passing to each cell. This further reduces the code we have to write in our datasource implementation and gives us more flexibility on how and where cells are configured.

In this episode we review the basic example app and start setting up our collection view in code. We start with the basic flow layout which is most common. Later we'll refactor this to use the newer style, but this episode introduces the series and sets up the foundation we'll build upon.

If you can describe your animation with a small number of parameters that interpolate over the animation, animation is pretty easy. But once you want to combine an arbitrary number of animatable data values, for instance an array of Doubles representing our points, then you have to resort to a custom VectorArithmetic implementation. In this episode we will create an AnimatableVector type that is capable of animating between arrays of Double values. We then use this type to animate between 2 sets of points using our waveform algorithm.

Animating in SwiftUI can seem like magic, until you want to animate something custom. In this episode we'll add animation to our frequency, amplitude, and phase parameters for our waveform by leveraging SwiftUI's AnimatableModifier protocol. We'll see how to implement the animatableData property with one, two, and ultimately all three parameters. We'll cover implicit and explicit animations, as well as the behavior when attempting to mix animations.

I've been working on rendering waveforms using mathematical functions and have found the experience to be both fun and enlightening. In this episode we will develop a method to render arbitrary functions using a Shape, then explore some mathematical concepts that can help us render a nice looking waveform that could be use to indicate activity in sound, speech, or other effects.

Simple animations in SwiftUI are refreshingly easy. However, some animations are deceptively tricky, as we don't have access to completion handlers. Animation is entirely state-based, so if we have an animation where an item needs to move and return to its original state, we need to take a different approach. In this episode we will model a bounce animation using a simple sine function, feeding in the time value t using SwiftUI's linear animation interpolation.

With the introduction of LazyVGrid and LazyHGrid In iOS 14 we now have access to much more powerful grid-based layouts in SwiftUI. In this episode We will examine the different types of layouts we can accomplish with flexible, fixed, and adaptive sizing for our rows and columns. We'll look at how animations work between different layouts, and how to consider larger screen sizes.

A few episodes back we covered how to wrap a UIActivityIndicatorView to show loading progress in SwiftUI. Now in iOS 14 this is built in. In this episode we'll cover the various styles, how to hook it up to a Progress instance, and how to create your own custom progress visualizations.

iOS 14 Beta is now available and one of the new features is Lazy stacks. With a normal stack, all the layout happened at once, which meant poor performance for large lists of content, grids, etc. With Lazy stacks the views are only created when they first come on screen, greatly increasing the usefulness of stacks for large or infinite collections of content.

Anchors are a way we can refer to the absolute positioning of a view at any level in the view tree. This is useful when you want to have one view surround, underline, or point to another element in the view tree. Combined with GeometryReader, you don't need to worry about converting between coordinate systems like you do in UIKit. Anchors work much like other preferences, with some small differences. In this episode we will build a bar graph view, then use anchors to animate an indicator on the selected item in the graph.

Paging between views is something that is not yet provided by SwiftUI, but we can lean on UIViewControllerRepresentable to borrow this behavior from UIKit. Doing so we'll learn about the Coordinator design for handling events via delegates and datasources. We'll also see some of the rough edges you might run into when using this technique.

It can be cumbersome to pass values from parent to child view to configure something. For instance, setting a font for many Text views inside of a VStack. Luckily there is a .font() modifier that can do this for you. How does it work? It sets a value in the Environment using an EnvironmentKey. In this episode we will learn how to leverage the SwiftUI environment to pass values to descendent views, regardless of their depth from where it is set.

Using Preferences we can communicate data, such as the actual size of a view, to any ancestor view. By taking advantage of the reduce function required by the PreferenceKey protocol, we can combine multiple values in whatever way suits our needs. In this episode we will use this technique to size a bunch of sibling views equally by collecting the biggest width and then pushing this value down to subviews with some parent state.

In SwiftUI we use State to push values from a parent to a child. What if you want to go the other way, passing data about a child up to a parent? To do this we can leverage Preferences. In this episode we will see how to define a custom preference key, how to use an overlay with a GeometryReader to measure the size of a view, and then set a preference with the view's size. Then we'll learn how to respond to preference changes in an ancestor view.