Trusted by teams
Point-Free is a video series exploring advanced topics in the Swift programming language, hosted by industry experts, Brandon and Stephen.
We dissect some of the most important and interesting topics in Swift programming frequently, and deliver them straight to your inbox.
We cover both abstract ideas and practical concepts you can start using in your code base immediately.
Download a fully-functioning Swift playground from the episode so you can experiment with the concepts discussed.
We transcribe each video by hand so you can search and reference easily. Click on a timestamp to jump directly to that point in the video.
We are going to take a Swift feature into the browser. We will set up a WebAssembly application from scratch, show how to run and debug it, and even set up some basic UI. And then we will integrate our existing model into it, all powered by the magic of Swift’s Observation framework.
It’s time to go cross-platform! We will take a feature written in Swift and use it in vastly different situations, including not only SwiftUI and UIKit, but beyond Apple’s frameworks and ecosystems. We will start with a baby step and introduce our feature to a third party view paradigm, Airbnb’s Epoxy.
We finish building a modern UIKit application with brand new state-driven tools, including a complex collection view that can navigate to two child features. And we will see that, thanks to our back-port of Swift’s observation tools, we will be able to deploy our app all the way back to iOS 13.
We show how the @Shared property wrapper, unlike @AppStorage, can be used anywhere, not just SwiftUI views. And we show how @Shared has some extra bells and whistles that make it easier to write maintainable Xcode previews and avoid potential bugs around “string-ly” typed keys and default values.
“Sharing” is a brand new library for sharing state throughout your application and to external systems like user defaults, the file system, and more. We start our tour of the library by comparing it to a tool that inspired its design: SwiftUI’s @AppStorage.
We conclude our introductory series on SQLite by showing how to live update SwiftUI views powered by database using GRDB’s “value observation.” Along the way we will tackle quite a few Swift 6 concurrency issues, and we will tie things in a bow by showing how the SwiftUI environment can vastly simplify how our application is powered by SQLite.
SwiftUI is Apple’s declarative successor to UIKit and AppKit, and provides a wonderful set of tools for building applications quickly and effectively. It also provides a wonderful opportunity to explore problems around architecture and composition.
The Swift language has grown over the years and become more and more powerful. It now boosts a comprehensive static type system (generics, existentials…), a suite of concurrency tools (actors, dynamic isolation…), and most recently even ownership capabilities (consuming, borrowing, non-copyable types…). In “Back to basics” we will focus on just one part of the language in order to uncover the deep theory behind that feature as well as provide concrete advice for writing real-world code.
Architecture is a tough problem and there’s no shortage of articles, videos and open source projects attempting to solve the problem once and for all. In this collection we systematically develop an architecture from first principles, with an eye on building something that is composable, modular, testable, and more.
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.
Three recent @pointfreeco episodes were so interesting I stayed in the treadmill 3x as long as usual and watched them all in a row! Walking may be challenging later/tomorrow... 😮
Through videos you constantly introduce ideas and patterns only to later reformulate them into more general ideas. This is awesome and helped me understand a lot of programming concepts. Well done!
Their content pushes the boundary of my knowledge, and it's fun to watch!
Watching the key path @pointfreeco episodes, and I am like 🤯🤯🤯. Super cool
After diving into @pointfreeco series reading Real World Haskell doesn’t seem all that intimidating after all. Major takeaway: the lesser is word “monad” is mentioned the better 😅
This is surely one of the best shows for Swift folks out there! The content and explanation is at a really high bar!
tfw you are excited for a 4 hour train ride because you'll have time to watch the new @pointfreeco episode 🤓🏔🚂 #MathInTheAlps #typehype
So many concepts presented at #WWDC19 reminded me of @pointfreeco video series. 👏👏 So happy I watched it before coming to San Jose.
Due to the amount of discussions that reference @pointfreeco, we added their logo as an emoji in our slack.
Our free plan includes 1 subscriber-only episode of your choice, access to 64 free episodes with transcripts and code samples, and weekly updates from our newsletter.