| Blog | http://www.malcolmhall.com |
It looks like the CloudKit silent notification bug was caused by some sort of token validation added in iOS 26.4 that was dropping notifications from CloudKit. Fixed in iOS 26.4.1 by bypassing the validation for notifications that come from CloudKit
Credit to @blacktop's excellent IPSW diffs: https://github.com/blacktop/ipsw-diffs/tree/main/26_4_23E246_vs_26_4_1_23E254#usernotificationscore
- it does sorting and searching via computed properties called from body instead of in actions.
- It needlessly uses @State var in the App when it could just be a let but neither are the correct way to init the real model and results in real model being init during previews.
- Preview data is implemented in non-standard way.
Nice the Goals tab has a 3D Cover Flow though!
Apple released another shocker of a #SwiftUI sample: Wishlist: Planning travel in a SwiftUI app
https://developer.apple.com/documentation/swiftui/wishlist-planning-travel-in-a-swiftui-app
- uses var instead of let in immutable View structs.
- Uses non-standard State(initialValue:) instead of @.Binding.
- Uses @Observable class with @.State instead of struct for view data (TripEditModel and another named just Model in AddTripView).
- @Environment with @Observable instead of @Entry for a struct (maybe ok)
- Identifiable class Activity implements an id as UUID.
Reported a terrible NSViewRepresentable animation bug which probably is why List and Table are so flakey on macOS.
FB22270146
New blog post! A close look at Tahoe menu icons. With 109 illustrations! https://tonsky.me/blog/tahoe-icons/
idk if i'm the minority in this, but i never liked the "icon for every item in menus"
it's extra noise to me.
Apple always felt like one of the hold outs on this. I could always reference them when I had this design argument.
But now with tahoe, they gave in and I feel increasingly isolated on my island of "exclude icons in context menus"
I also wrote a deep dive on the evolution of the project—from failed KeyPath experiments and memory leak traps to the final "Shadow Storage" design that powers the library today, read it here:
🚀 I just released Swift Streamable Actors v1.0!
If you’ve ever wanted to observe changes to a Swift Actor's state as an AsyncStream without writing 30 lines of boilerplate for every property, this macro is for you.
Key highlights: ✅ 100% Type-safe (no type-erasure/AnyKeyPath) ✅ Memory safe (static factories avoid strong reference cycles) ✅ Clean API: @Streamable does it all.
Check out the code: https://github.com/malhal/swift-streamable-actors
This WWDC 2025 sample is really sad. It uses @State with a class (leaks heap memory) and the class's init is really heavy, creating AV objects.
Also it uses a ViewModel class instead of #SwiftUI @Binding.
The worst thing is it's using @Observable for view data (it's designed for model data) that has a func that has Combine code (pipelines should be in ObservableObject init).
Something has gone badly wrong at Apple that the devs don't know what tools to use for what.
https://developer.apple.com/documentation/AVFoundation/capturing-spatial-audio-in-your-ios-app
🗣️ I do enjoy a good rumor, so I'll share this nugget:
I have heard that SwiftUI has been losing political capital, and credibility, internally at Apple because it has repeatedly failed to meet software engineering goals, and needs. It's no longer thought of as clear default choice for new stuff.
That might explain why it was deemphasized at WWDC compared to the past few years.
Comforting that Apple might finally be waking up to the reality of SwiftUI, 6 years in. Glad I waited that one out 😅
Gui Rambo
Marco Arment
Jim Nielsen
Steve Troughton-Smith