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 finish a sneak peek of our upcoming Structured Queries library by showing how queries built with the library can be reused and composed together, and how we can replace all of the raw queries in our application with simpler, safer query builders.
Last week we released SharingGRDB, an alternative to SwiftData powered by SQLite, but there are a few improvements we could make. Let’s take a look at some problems with the current tools before giving a sneak peek at the solution: a powerful new query building library that leverages many advanced Swift features that we will soon build from scratch.
We celebrate 7 years with a live stream! We discuss some recent updates around our popular Sharing library; open source SharingGRDB live, which is a new lightweight alternative to SwiftData that is powered by Sharing and GRDB; and we give a sneak peek of an upcoming series and library.
We tackle one of SQL’s most important aspects in our query builder: the WHERE clause, which filters the results of a query. And we will do so in a type-safe manner that prevents us from writing nonsensical queries in Swift even when they are syntactically valid in SQL.
We add sorting to our SQL builder, which will give us a powerful, succinct syntax for controlling the order of results. We will start small but build up to parameter packs and even a custom result builder to get the most flexibility out of our API.
We now have a type-safe syntax for generating SELECT statements using key paths to the columns we want to select, but while this syntax is nice and what many existing libraries use, we can do better. Let’s introduce a more advanced syntax that leverages variadic generics and supports more complex query expressions.
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?
Watch us live write a complex SQL query to load “really important reminders”, and seamlessly integrate that state in our app. The database will automatically be observed for changes so that we can re-execute our query, and the view will immediately update when the data changes.
@pointfreeco ❤️: Thank you! 🧠: … The brain can’t say anything. It is blown away (🤯)!
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... 😮
tfw you are excited for a 4 hour train ride because you'll have time to watch the new @pointfreeco episode 🤓🏔🚂 #MathInTheAlps #typehype
I really love the dynamics of @pointfreeco. The dance of “this is super nice because…” “yes, BUT….”. they clearly show what’s good, what’s not so good and keep continuously improving.
Watching the key path @pointfreeco episodes, and I am like 🤯🤯🤯. Super cool
Honestly, I'm an Android developer, I write applications in Kotlin. My colleague iOS developer told me about your course. And I liked it so I decided to buy a subscription.
The best thing, that happened to me for a while. @mbrandonw and @stephencelis really provide a lot of new information according to #ios development and #functionalprogramming. All info could be used in real production without boring academics.
Just finished the mini-series on enum properties by @pointfreeco! They pointed out what’s missing from enums in Swift and used SwiftSyntax to generate code to add the missing parts. Thanks for your work @stephencelis and @mbrandonw! #pointfree
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 71 free episodes with transcripts and code samples, and weekly updates from our newsletter.