Steven Huang

@mariani1
112 Followers
209 Following
407 Posts

Former long-time engineer and manager on the #iOS #Music UI team. #Yahoo!, #iPod, #Openwave, #Geoworks, and others before that.

Dabbles in photography and building plastic models. Learning Swift and related technologies.

LinkedInhttps://www.linkedin.com/in/shuang886/
GitHubhttps://github.com/shuang886
Codeberghttps://codeberg.org/shuang886
Bloghttps://shuang886.duckdns.org/steven

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 Sam Lazarus, @dduan, @holly, 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 👏🏻)

Tsk, Apple, there’s not dwelling on past glories, and there’s just forgetting your roots:
Didn’t this just used to be called #WWDC?

RE: https://social.coop/@ogeer/116579470188463231

Thank you all for making this a room for a bridge from Free Software to Ethics in AI!

Here are the notes (CC0):

https://civic.ai/software-freedom-as-civic-care/

I'm incredibly pleased to announce that the microcode for the Intel 80386 has been decoded.

It was a group effort by a bunch of talented people to extract and correct the physical bits, but the major work of decoding them was done by reenigne - you may know him from such incredible PC demos as 8088 MPH and Area 5150, as well as being the person who decoded the 8088 microcode previously.

Please, check out his writeup.

https://www.reenigne.org/blog/80386-microcode-disassembled/

#retrocomputing #vintagecomputing #microcode #reverseengineering

80386 microcode disassembled « Reenigne blog

@Cdespinosa Came across this on social-medium-that-shall-not-be-named. Have you seen it before?
I’m glad that Apple is finally recognizing some of the third-party writers who have played a critical role in enabling the Apple developer ecosystem, but they really need to think hard about their embarrassing reliance on third-party documentation.
But these two things are related - language choice, and how far down you need to know. Because I do think that whatever language you use, you should know the "next level down". When you're writing code, you should be able to fairly simply translate in your head to the language below it.

Some reading for the weekend:

Implementation details of Apple's lossy texture compression format.
https://www.ludicon.com/castano/blog/2026/04/metal-lossy-compression-format/

Enjoy!

Metal Lossy Compression Format

The Apple Lossy compression format was introduced in the A15 and M2 chipsets (which share the same GPU generation) and it enables sampling and rendering to textures with a 1:2 compression ratio. The format is transparent to the application: the GPU handles compression and decompression automatically

Ignacio Castaño