If you have ever created a binding using the get:set: initializer, you may want to reconsider. Doing so can hurt SwiftUI’s ability to animate your view. Luckily there is a better way. You can leverage @dynamicMemberLookup and subscripts to derive new bindings in a way that allows SwiftUI to propertly track where the binding came from.

You may have heard that “mocks are bad” and that they cause you to test the mock rather than your application’s actual feature. That doesn’t have to be the case. It is totally fine to mock a dependency to a system that you do not control, such as the file system. You do not need to test that saving and loading with that dependency works, but you should test how your application behaves when it tries to load or save data. For example, if loading data throws an error, do you show an alert to the user?

There is a common pattern in the SwiftUI community of defining a logicless, inert view that just holds onto plain data. This makes it easy to preview how the UI looks, but because it does not exercise any of the behavior of the view it is merely a mirage. Learn why you might not want to adopt these “inert” views in your codebase.

We often need to perform async work when there is no async context, such as in SwiftUI button action closures. In such cases it seems that you have no choice but to spin up an unstructured Task, but you may have heard that doing so it bad. So what are you to do? Well, there is an easy answer…

Did you know that Swift runs on more platforms besides just Apple’s devices? It can run on Windows, Android, web browsers, and Linux (Swift even powers this very website!). This clip demonstrates how to get a basic Swift app running in the browser, from beginning-to-end.

Reference types are very different from value types in Swift. They are an amalgamation of data and behavior that can be mutated at any time and from any place in your code base. It can be very tricky to conform such types to the Equatable and Hashable protocols, and in this clip we show one such example.

In this clip from our livestream we discuss the differences between tree-based and stack-based navigation. In the former, each feature defines an enum of destinations that can be navigated to, forming a tree-like structure, and in the latter all destinations are collected at the root feature and represented by a flat array.

In this clip from our livestream we discuss the pros and cons of tree-based and stack-based navigation.

A short excerpt from episode #216 on Point-Free entitled Modern SwiftUI: Navigation. In this excerpt we describe the safety vs ergonomics tradeoffs in using closures in order to facilitate communication between parent and child domains in SwiftUI.

This is the outro of episode #218 where we discuss how adding complex effects to our app made it a lot more interesting, but has also made the code base more difficult to work with. Previews no longer work as well as they used to because things like the Speech framework don’t work in previews. And tests are going to be difficult to write due to accessing the file system and Speech framework, and using timers is going to slow down our test suite. The solution to these problems is to control your dependencies!

Exhaustive testing is one of the best features of the Composable Architecture, but it’s also not always appropriate to use. There are times, especially when testing the integration of many features together, that you only want to assert on a small subset of what is happening in your features, and for those times we’ve got just the right tool.

In this clip we show how easy it is to test the integration of many features in the Composable Architecture. In particular, we test the behavior for when a user ends a meeting early and discards the meeting. We want to show that the record meeting feature is popped off the stack, and that a new meeting was not inserted into the data source.

A short retrospective from the end of episode #206 where we reflect on why the new dependency management system is so powerful, and why it fits so naturally with the Composable Architecture.

Init accessors are a new feature in Swift 5.9, and they allow you to write initializers that set computed properties in the type even before all of the stored properties are set. This was a necessity in order to make macros work as seamlessly as possible.

Do you think it’s possible to define a function of the form (Never) -> A for any type A? That seems impossible since Never is a type in Swift that cannot be constructed. It has no values whatsoever. Well, it is possible to construct such a function, and it’s a little absurd.

In our episode on the observable architecture we demonstrated a technique for integration testing using our snapshot testing library. However, we aren’t snapshotting images. We are snapshotting logs produced by the feature so that we can verify that they are doing the minimal work possible.

We have released a number of open sources libraries to fill gaps in Swift and SwiftUI that ideally would be provided by Apple. So we are begging Apple… Sherlock us, please!

Learn how type inference can be improved in Swift’s result builders by making use of generic result builders and buildExpression. This is a sample of some of the advanced topics you will learn on Point-Free that are not covered anywhere else.