Lovely hearing the interplay between
@mathijskadijkand
@tomlokhorst while they were explaining Swift Actors, how to use them and—more importantly—when not to use them! With live coding too!
The first in a recurring "MainActor all the things" theme on this topic 😂
#SketchNotes #AppDevCon @appdevconPlaying around with the cursor following the curvature of the window exactly. Instead of the 90 degree cursor macOS supports by default. Quite interesting how natural and smooth it feels.
Bezel now calculates a custom corner radius for the device frame that you use, makes it easier to grab and resize the corner of the device.
Hope that reduces a bit of frustrating while giving a demo of you app to an audience and trying to make the device look a bit bigger.
Try it yourself here: https://getbezel.app
Use the power tools when you know you need them, but not just because they're there. I've made that mistake over and over again, but always ended up so much happier with the simple solution in the SDK I'm working on and our app Bezel.
But once again, think twice before using an actor (or even a mutex). It's so much simpler to see if you can have that state live on the MainActor. It's so much more often possible then you might think, even if the work is heavy the state change can happen on main.
Or if you have a big part of your app that works together on state, but can't be on the MainActor. Then you can make your own Global Actor, that removes the requirement to write one big actor. Enabling to split up your code.
If you have mutable stated, shared over isolation domains that can't live on the MainActor and you can await to access it. Actors might be a good option. Then they also have cool tricks, like using DispatchQueue which makes it easy to use queue based APIs
Also; Keep the complexity of shared mutable state and Sendables contained as much as you can. Don't respond to compiler issues by making more types Sendable. See if you can contain it as much as possible. Most types shouldn't be more complex then being nonisolated(nonsending).
The async/await nature of an actor and Sendable requirements have a huge impact on your codebase. So even if you have shared mutable state an actor is sometimes impractical. Learn about Swift Mutex as different tool that can also do the job if you must share state over domains.
However often you don't want (and also shouldn't) make state shared and mutable. You're just trying to make a compiler issue go away, actors are hardly ever the right tool to use. You're first response should be whether it can just live on the MainActor instead, much easier fix!
Bruno Scheele
