JD Gadina 🦄

@macmade
262 Followers
95 Following
560 Posts
Lead Developer for DigiDNA's iMazing - https://imazing.com
Talking about code, operating systems, electronics and astrophotography.
http://xs-labs.com - he/him 🦄
Pronounshe/him
Websitehttps://xs-labs.com
GitHubhttps://github.com/macmade
AstroBinhttps://www.astrobin.com/users/macmade/
Il y a quand même des gens fragiles dans le train.
Peut-être que je devrais renommer mon WiFi "AntiConnard", histoire d'essayer d'instaurer un dialogue...
#sbb #cff

On my blog: “I seriously dislike the experience of using a Mac with Liquid Glass. The UI has become the star, but the drunken star, blurry, illegible, and physically unstable.”

https://inessential.com/2025/08/25/tough-season.html

inessential: Tough Season in the Apple Fields

Sturgeon Moon - Doing what I can without my telescope and shooting through scaffoldings.
Canon EOS R7 + Canon RF 100-400 IS USM.
800mm, f16, 1/32, ISO 100, 10% of 100 frames.
#canon #canoneosr7 #eosr7 #astro #astrophoto #astrophotos #astrophotography #astrophotographer #spacephotography #astronomy #spaceexploration #nasa #universe #space #deepsky #deepspace #solarsystem #moon #lunar #moonlovers #moonphoto #moonphotography #moongram
Unfortunately, I lost access to my balcony as my building is currently being renovated. This should last until early next year. In the meantime, here's a shot of the full Moon through the safety nets on the scaffoldings.
#canon #canoneosr7 #eosr7 #astro #astrophoto #astrophotos #astrophotography #astrophotographer #spacephotography #astronomy #spaceexploration #nasa #universe #space #deepsky #deepspace #solarsystem #moon #lunar #moonlovers #moonphoto #moonphotography #moongram
as if working with String in Swift + iOS frameworks wouldn't be painful enough, the String UTF8 is not reliable now, either.

SysAdmins, if you haven’t noticed iMazing Profile Editor version 2 release yet, Bradley Chambers, 9to5Mac’s go-to voice for Apple IT and system administration certainly has, and he’s highlighting Total App Setup as a key innovation for automating macOS app configuration 🏆
iPE 2 also brings visionOS support, improved payload import/export, and MCX compatibility — making it the most capable iPE to date.

Our post: https://imazing.com/blog/imazing-profile-editor-2-release
9to5Mac's take: https://9to5mac.com/2025/06/21/imazing-profile-editor-2-is-still-the-swiss-army-knife-app-for-apple-it-admins/

#MacAdmins
#iMazing
#AppleIT
#ConfigurationProfiles

So AppKit controls are now just wrappers on some custom/private SwiftUI views on macOS 26 Tahoe? 😱 Why Apple? Why? 😭 #apple #wwdc #wwdc25 #macos #tahoe #appkit #cocoa #development #swift #swiftui
×
So AppKit controls are now just wrappers on some custom/private SwiftUI views on macOS 26 Tahoe? 😱 Why Apple? Why? 😭 #apple #wwdc #wwdc25 #macos #tahoe #appkit #cocoa #development #swift #swiftui
@krzyzanowskim Yup, basically everything NSControl. Meaning all the pubic APIs from AppKit related to customization/drawing are now broken, even though we were relying on that since Mac OS X 10.0. Performance-wise, it also means that an app will now beachball when trying to render ~50 controls. But hey, we now have liquid glass...
@jnadeau @Gte
@macmade @jnadeau @Gte is that the case though? NSHostingView ain't performance nightmare in small doses if there's not much state management in it. at least that doesnt raise a rerformance flag for me at first glance.
@krzyzanowskim @jnadeau @Gte IMHO the culprit is not NSHostingView, but the way SwiftUI does the rendering. Don't get me wrong, I really enjoy SwiftUI. But moving from AppKit/CoreGraphics drawing to SwiftUI indeed has a heavy performance cost.

@macmade @krzyzanowskim @Gte Performance cost in which part of the work? In typical usage it assembles pretty cheap layer subtrees, and if you force it down a context drawing path it’s just issuing draw commands into a CoreGraphics context, nothing too exotic.

We are missing some caches in front of the context drawing path, so every redraw is currently happening tabula rasa, so that’s currently more expensive than it ought to be.

@macmade @krzyzanowskim @Gte (And please let us know if any cell API contracts are broken. Maintaining them is an important part of this work.)
@jnadeau @krzyzanowskim @Gte Thanks a lot for the reply. I know this one has always been cursed since its introduction... but... NSSegmentedControl ?
@jnadeau @krzyzanowskim @Gte Also NSTextField, especially working with the field editor. Public APIs are broken, positioning of the field editor is no longer possible by adjusting the frame that is passed to the standard methods. Internally, you discard the argument and compute the position using the private method "_editingBoundsForBounds:", that assume standard control sizes.
@macmade @jnadeau @Gte right. for all the cases where AppKit is broken, but we learned how to workaround it, this new situation with SwiftUI black box is not improvement. I guess the only choice is to accept worse UX, or start reimplementing things :-( I hope no more such cases. as we knownthere are rough cases, not fixes since last ui revamp

@jnadeau @krzyzanowskim @Gte I finally had time to create radars for the most annoying issues I've encountered so far, if you're interested in following : )

FB18367921 - Custom NSSegmentedCell - Drawing is ignored
FB18367503 - NSTextField - Field Editor can no longer be positioned
FB18366576 - Empty Views Prevent Click Events

@jnadeau @macmade @krzyzanowskim @Gte Just to make sure I get this right: You were throwing out years of optimization (caching is HARD) for what gain? By gain, I only care about better user experience or better experience for developers *outside* of Apple.

Does this change provide a better user experience (faster UI would be an example)?
Does this change fix more bugs than it adds? Are the new bugs easier to work around?

If any of these question is not a strong yes, it’s just change, not gain.