Point-Free

We have a data race on our hands, which is exactly what Swift concurrency is supposed to solve for. Let’s figure out how we managed to get into this mess, and then we will get our feet wet with an isolation tool that predates Swift concurrency: locking.

https://www.pointfree.co/episodes/ep358-isolation-legacy-locking

In Swift 5 mode it is all too easy to write code that crashes at runtime due to simultaneously mutating some state from multiple threads.

Isolation is Swift's answer to solving this problem, and it's the focus of our newest series of episodes: https://www.pointfree.co/episodes/ep357-isolation-what-is-it

The Swift proposal for actors uses a 'BankAccount' type to explore how actors work.

We think it's a bit too simplistic to really understand how actors compare to older styles of isolation, and so this week we explore a more complex example.

👉 https://www.pointfree.co/episodes/ep357-isolation-what-is-it

Have you tried SQLiteData yet?

https://github.com/pointfreeco/sqlite-data

What is “isolation” in Swift? And why does understanding it matter? It turns out many frustrations developers encounter in Swift concurrency evaporate when they internalize the concept.

These videos are going to go beyond basics, so let’s get into it: https://www.pointfree.co/episodes/ep357-isolation-what-is-it

Composable Architecture 2.0 and SQLiteData work together like salt and pepper. You treat persisted models as simple values that live in your feature’s state, something that just isn’t possible in SwiftData.

And all of TCA’s powerful testing tools just work! You play a script of user actions to your feature and get to exhaustively test how your feature changes over time by describing it in simple mutations.

Watch our preview of these tools today: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

Swift’s ownership tools are not only for library users. They also help authors stay disciplined. When we lend a valuable resource to a user’s closure, we wrap it in ~Escapable so it cannot live longer than that closure.

Get all the details here: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

Swift’s ownership tools don’t just help our users. They also help library authors keep themselves honest. When we lend a precious resource to a user’s closure, we wrap it in ~Escapable so it cannot outlive that closure.

Learn all about it: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

Swift’s ownership tools don't just help our users. They also help us as library authors to keep us honest. When we lend a precious resource to a user’s closure, we wrap it in ~Escapable so it can’t outlive that closure.

Learn more:
https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

Swift's ownership tools allow us to restrict how users of our libraries interact with dangerous objects, such as a raw database pointers. They should never escape from a database transaction, and now this is enforced by the compiler.

Learn more: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

By using almost every advanced Swift concurrency tool, we can fully control how database changes are sent to observers, all without slowing down the writer actor!

Learn more in this week's episode: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

You may have heard that actors cause you to make everything async, but that's not true!

In this week’s episode, we show how to support an async database read (using a database pool without blocking) while still keeping a synchronous read option.

https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

By embracing ~Copyable/~Escapable and controlling isolation we can add incredible safety and performance to a legacy C API! We also preview how these tools make testing a Composable Architecture 2.0 + SQLiteData app feel like magic: https://www.pointfree.co/episodes/ep356-beyond-basics-superpowers

You should be leveraging Swift isolation, ~Copyable, and ~Escapable types!

Doing so not only enforces correctness, but gives you better ergonomics and performance, for free!

Watch our brand new video series to dive deep into the topic so you can best take advantage of these features: https://www.pointfree.co/episodes/ep355-beyond-basics-isolation-copyable-escapable

When you add time-based asynchrony to a Swift feature, good luck testing it! You’re often led to literal Task.sleeps in your suite, making it slow and flakey all at once.

But did you know it’s possible to make Task.sleep completely synchronous, without a single thread hop?

See how a “nonisolated(nonsending)” clock can make asynchronous work like Task.sleep completely synchronous: https://www.pointfree.co/episodes/ep355-beyond-basics-isolation-copyable-escapable

Swift Testing has amazing parallelization, but most apps can’t take advantage of it because their models are all MainActor-isolated.

But Composable Architecture 2.0 lets you run features on any actor, which can speed up large test suites many times over.

Did you notice? This week’s episode is completely 🆓!

In it we demonstrate how to execute dynamic SQL queries based on actions the user takes. It works great from an @Observable model (and SwiftUI view, of course), and it's also animatable!

👉 https://www.pointfree.co/collections/tours/tour-of-sqlitedata/ep348-tour-of-sqlitedata-querying

Anyone who has used SwiftData knows all too well that the its amazing tools do not work outside of SwiftUI views.

SQLiteData, on the other hand, works basically everywhere, including @Observable models and even UIKit!

Learn more: https://www.pointfree.co/collections/tours/tour-of-sqlitedata/ep348-tour-of-sqlitedata-querying

Supporting CloudKit sync for SQLite is a daunting task. There are edge cases and nuances to be aware of, and the risk of introducing subtle bugs that cause data loss is very real.

Here’s the most important technique we used to build this feature…

Debugging the library by literally running multiple devices and editing data to see how it synchronizes is an absolute time suck. So we built our own in-memory version of CloudKit containers and databases so that we could interact with “CloudKit” in a testable and controllable manner.

This allowed us to write hundreds of tests for many intricate and subtle syncing situations (and turn bug reports from our beta users into failing tests), all without running on a real device or interacting with CloudKit:

• What happens when two devices edit the same record at the same time?

• What happens when a device receives a child record from CloudKit before it receives the parent record? Can foreign key constraints be enforced?

• What happens if a device receives a record from another device running an older version of the schema? Do we lose that data or can it be preserved until the device upgrades to the new schema?

• What happens on first launch of an existing app that has just added CloudKit synchronization? Can we upload all of the existing, local data to CloudKit?

• What happens to the user’s data when they are logged out of iCloud?

• What happens when a user writes to a shared record for which they do not have permissions?

• What happens when one device adds a child record to a parent record and another device deletes the parent record?

• What happens when a record in a shared zone is moved to another zone? Do all associated descendant get moved to the new zone too?

Whenever we wrote a passing test, we could immediately confirm the fix on-device using the live iCloud servers in place of our in-memory CloudKit.

And to be honestly, this is barely scratching the surface of what problems we came across while working on this and what we needed to write tests for.

See the full test suite here:

https://github.com/pointfreeco/sqlite-data/tree/main/Tests/SQLiteDataTests/CloudKitTests