SwiftLee Weekly
SwiftLee Weekly #298

Approachable Concurrency · Xcode Instruments & suspension points · Two defeated conference challenges

Join 31,000+ Swift & iOS developers — free, every Tuesday, in 5 minutes.

No spam. One email every Tuesday. Unsubscribe in one click.

This week's blog post

Sponsored

Try Clerk for Swift

Drop in Clerk’s prebuilt SwiftUI views for sign-in, sign-up, and user profiles. Production-ready authentication out of the box, so you can focus on building your app’s core features.

Learn more

Curated from the community

Swift Evolution

Last week's Swift proposal state changes. Review-stage proposals are your chance to influence Swift's future.

What I'm working on

Do iOS Conference & Xcode Instruments

Last week, I've had an incredible time at the Do iOS Conference in Amsterdam. With many great speakers and fantastic conversations with many of the attendees, it's been a blast once again.

I got challenged twice during the conference:

The Soundcloud asked me for permission resetting functionality for Xcode's Simulator. Challenge defeated, it's coming into the next version of RocketSim. Mustafa and Hidde told me they're not using RocketSim's recording feature because they dislike the Simulator bezels. So I got Apple's device assets and worked on improving this. Also, available in the next version, high quality device bezels:

This is just an image with a white background — imagine using a gradient background or capturing recordings with touches. Next level reached, challenged defeated!

New to RocketSim? Check out www.rocketsim.app

It's not only others that challenge me, it's also me that challenges me. For my Concurrency Course, I want to complete the performance module before the end of the week. After completing the first lesson that dives deep into Xcode Instruments for Concurrency, I thought I had achieved the best performance yet.

Turned out, after diving deeper into suspension points, it was not. A line without code was causing a long suspension.

You're reading that right:

Since the task at step 1 started on the @MainActor, the code suspended just as long until the main actor got space to continue. Eventually, the task started, but immediately reached step 2. In other words — we've waited for @MainActor access just to start the task.

You can see it in the image below:

Although both timelines may look similar at first glance, the narrative data reveals clear performance improvements in the after version. We removed an initial suspension of 68.44 ms, and the task creation time dropped from 45.5 ms to 1.05 ms—a reduction of ~98%.

We still incur a final suspension when returning to @MainActor, but this remaining 38.16 ms is significantly lower than the total suspension time in the before version.

For those on the course: these lessons are now available. For all others: a Black Friday deal is coming next week. Simply click here and I'll make sure you get an email as soon as the deal becomes available!

Enjoying this issue?

Join 31,000+ Swift & iOS developers and get the next one in your inbox — free, every Tuesday, in 5 minutes.

No spam. One email every Tuesday. Unsubscribe in one click.