Sam Lazarus

SwiftUI @ Apple, usually on bluesky: I’ll still check dms here on occasion though, and tend to return every year for WWDC.

[Sam Lazarus @slazaruseth]

@squeakytoy Your regularly scheduled societal fire programming will be back after these WWDC-related breaks

[Sam Lazarus @slazaruseth]

@DanielBerezhnoy Yes! These were some incredibly challenging problems to tackle. @ricketson_ did a very lovely little writeup on how much had to happen for this project to come to life: https://t.co/cyIAN5II2R

[Matt Ricketson @ricketson_]

SwiftUI’s new type-checking enhancements (`@ContentBuilder`) and lazy `@State` are the culmination of literally years of careful effort behind the scenes to solve some of the biggest everyday pain points in SwiftUI development.

At this point, there are millions of lines of SwiftUI result builder and state code shipping in production. With these changes, every one of those lines of code will suddenly compile differently, improving both compilation and runtime performance, and most developers *will never even notice*.

That doesn’t normally happen. Maintaining binary, source, and backwards compatibility across releases imposes strict limitations on how SDK APIs can evolve. If you think of a better way to compile some library DSL syntax after shipping it publicly, you’re usually out of luck.

These enhancements were only possible because of dedicated engineers on the Swift and SwiftUI teams working closely together, sweating the subtlest of details, and persevering through countless dead-end experiments and fraught internal deployments.

Their reward? That future developers will *not* see some type-check error or performance hitch, and will *never* have to know that it ever worked any differently.

But that’s wonderful. We love it. The joy is in the doing.

Thank you @slazaruseth, @daniel_duan, @hollyborla, Pavel Yaskevich, and others from the Swift and SwiftUI teams for getting these enhancements over the finish line! (I’m no longer at Apple but can’t help but brag about these talented people 👏🏻)

[Sam Lazarus @slazaruseth]

Super proud to have worked on this! It's one of those things that will hopefully be invisible now that it's fixed, but anyone who has hit this before knows just how meaningful this work is.

[Donny Wals 👾 @DonnyWals]

Swift 6.4 will ensure SwiftUI view bodies show "the compiler could not typecheck this in reasonable time" less often for large views 😍

#wwdc

[Matt Ricketson @ricketson_]

SwiftUI’s new type-checking enhancements (`@ContentBuilder`) and lazy `@State` are the culmination of literally years of careful effort behind the scenes to solve some of the biggest everyday pain points in SwiftUI development.

At this point, there are millions of lines of SwiftUI result builder and state code shipping in production. With these changes, every one of those lines of code will suddenly compile differently, improving both compilation and runtime performance, and most developers *will never even notice*.

That doesn’t normally happen. Maintaining binary, source, and backwards compatibility across releases imposes strict limitations on how SDK APIs can evolve. If you think of a better way to compile some library DSL syntax after shipping it publicly, you’re usually out of luck.

These enhancements were only possible because of dedicated engineers on the Swift and SwiftUI teams working closely together, sweating the subtlest of details, and persevering through countless dead-end experiments and fraught internal deployments.

Their reward? That future developers will *not* see some type-check error or performance hitch, and will *never* have to know that it ever worked any differently.

But that’s wonderful. We love it. The joy is in the doing.

Thank you @slazaruseth, @daniel_duan, @hollyborla, Pavel Yaskevich, and others from the Swift and SwiftUI teams for getting these enhancements over the finish line! (I’m no longer at Apple but can’t help but brag about these talented people 👏🏻)

[Sam Lazarus @slazaruseth]

@_take_hito_ Handling that protocol agnostic case is what the overloads which return TupleContent and just the generic parameter Content are for. Those are the code overloads which get selected for > 27.0

[Sam Lazarus @slazaruseth]

@_take_hito_ Fun fact: it’s even a bit cooler than those headers suggest. Those overloads are only used for backwards compatibility. When compiling > 27.0, instead it just returns something which conforms to *no* protocols, and conditional conformance’s are used to ensure type safety

[Sam Lazarus @slazaruseth]

@FloWritesCode Worth noting: ContentBuilder and ViewBuilder are equivalent under the hood, so you don’t need to migrate away from ViewBuilder to get the improved typechecking.

I do still recommend using the new name though; it’s more accurate now that it supports more than just views

[Sam Lazarus @slazaruseth]

@Frizlab @d_date Hmm, strange! Please file feedbacks anywhere you're still hitting this error, and especially if it appears in new places.

We'd love to take a look and see if there's something going on in that particular case which we can improve!

[Sam Lazarus @slazaruseth]

Fun QOL change that didn't get much press: Swift Charts code got some *major* performance improvements! This change required a *massive* re-architecture of the framework, so highly recommend trying out your charts to feel the perf and submitting feedback if any issues pop up!

[Sam Lazarus @slazaruseth]

@DemirciJohn @daniel_duan The improvements we're shipping this year were in the works before this thread (it's been a long, huge effort!) but it was definitely invigorating to see people affirming how important an issues it was while working on it!

[Sam Lazarus @slazaruseth]

@DonnyWals This work was a really great combination of a huge effort to evolve the shape of SwiftUI without breaking source or binary compatibility, + an incredible effort to improve typechecking performance from everyone working on the compiler. Super glad we could make this happen!

[Sam Lazarus @slazaruseth]

@_julianschiavo It's a life subtweet, but also yes

[Sam Lazarus @slazaruseth]

Needing to get X premium to edit my tweets is incredibly sobering. I guess they're just gonna be sub optimally phrased, and I need to live with that.

[Sam Lazarus @slazaruseth]

Cannot stress enough how useful these skills are. I highly recommend both using them for agentic coding, but for human reading. There's lots of great information in these skills for people too!

[Luca Bernardi @luka_bernardi]

Today, Xcode ships with agent skills for SwiftUI (with the ability to export them to use with any agent). These skills will help you and your agent create modern, idiomatic, and performant SwiftUI and make the best use of brand-new APIs.

We have synthesized best practices of years of adoption for SwiftUI with context and explanation to help you build amazing and powerful apps.

Let us know what you think!

[Luca Bernardi @luka_bernardi]

Today, Xcode ships with agent skills for SwiftUI (with the ability to export them to use with any agent). These skills will help you and your agent create modern, idiomatic, and performant SwiftUI and make the best use of brand-new APIs.

We have synthesized best practices of years of adoption for SwiftUI with context and explanation to help you build amazing and powerful apps.

Let us know what you think!

[Sam Lazarus @slazaruseth]

I'm also gonna be in the one on Thursday evening, but I'll post more about that closer to Thursday. Gotta take every opportunity to post multiple times, I'm only on this website one week every year 😛

[Sam Lazarus @slazaruseth]

I'll be answering questions along with my lovely colleagues in the SwiftUI Beginner Group Lab bright and early tomorrow morning. Highly recommend stopping by, we've got a stellar panel lined up for ya!

https://t.co/wOcYFdCPs9

[Zhiyu (Apollo) Zhu ⚙️ @zhuzhiyu_]

State Macro 🥳

[Sam Lazarus @slazaruseth]

Hi Twitter! I’m back for my annual WWDC visit. Happy WWDC!