Want early access? Drop your email: tally.so/r/rj6Ldp

A close-up of the Bezel app toolbar showing a new mouse cursor icon used to toggle iPhone control on and off.

Just added this little icon to the Bezel toolbar. Small step, but a big one. It unlocks controlling any iPhone straight from your Mac. Keyboard, mouse, any iPhone. One step closer to a first preview.

getbezel.app

Bezel paywall showing the lifetime purchase option in the App Store

You could already buy a Bezel lifetime license on our website. Now it's also available as an in-app purchase on the App Store. Same deal either way.

Film clapper board held up in an office

Got some new hardware to test audio/video sync timing.

Until now Tom and I have been clapping our hands and counting takes out loud. About time for an upgrade.

Check it out: github.com/nonstrict-hq...

We kept hearing from developers who wanted to use RecordKit in Mac App Store apps but couldn't because of sandbox restrictions.

So we built RecordKit Sandboxed. Same recording SDK, same API, fully compatible with the App Store sandbox.

We made sure to mention it in our RecordKit docs: nonstrict.eu/recordkit/gu...

Tip about Core Audio system audio recording permissions on macOS 26

Recently added system audio recording support to RecordKit through Apple's Core Audio APIs. Turns out that since macOS 26, you don't need explicit system audio recording permission if you already have screen recording permissions. Might be neat to know if you work with this API.

Full guide here: recordkit.dev/guides/echo-...

Echo cancellation just shipped in RecordKit. Building a meeting recorder? Remote audio leaks into the mic and Whisper transcribes it twice or produces garbled output. One enum fixes it. Aggressive mode for clean STT, balanced for playback.

Taking a peek at the dark side. Picked up this little ThinkCentre PC to see what Windows development looks like in the age of AI agents. 👀

Playing 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 • Mirror any iPhone on your Mac The best way to display and record any iPhone, iPad, and Apple TV.

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: getbezel.app

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.

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!

Often this is because you try to introduce actors or make things Sendable. It's fine to use actors to protect shared mutable state.

Once you get the easy issues out of the way, you'll probably hit the more complex app logic, libraries and APIs using closures, dispatch queues, you probably have entangled state. This all might make it hard to apply the basic fixes, they only give you more errors.

First of, WWDC videos (new and old), and content creators like Donny, Matt and Antoine create awesome content. Make sure to read up with that first to get to know the principles and how all this concurrency stuff works.

You're probably struggling with Swift Concurrency, I definitely was, especially when you turn on Strict Concurrency Checking. So Tom and I shared our learnings in a talk on AppDevCon last week.

Read on for the gist on how you can approach Swift Concurrency without going crazy.

Had a great time speaking at AppDevCon in Amsterdam taking a deep dive into Swift Concurrency and Actors. Lovely to share some of our experiences and best practices.

Maybe fine tune your AI to reply a little less on the same person, I think this is the 3rd time you (or your AI for that matter) replies to my post with the same kind of reaction plugging your app.

That worked pretty well, I know what we need to have and can read the code. So if it looks of I can iterate on it with Claude and throw sample code at it. That works pretty well for me!

On iOS I invested a little more in the timeline stuff, because I'm not super experienced with it myself I gave Claude a lot of Apple example code and a good description of the logic we needed.