Will
@will-lumley.bsky.social
Mainly a senior iOS engineer, but love to dabble in web development and robotics/embedded-systems in my spare time.
Father to four amazing children, and husband to a beautiful wife.
Checkout my stuff:
https://lumley.io
http://github.com/will-lumley/
Father to four amazing children, and husband to a beautiful wife.
Checkout my stuff:
https://lumley.io
http://github.com/will-lumley/
Hard agree. Combine deserved a graceful evolution, not quiet abandonment. Even a small set of first-party bridging tools or async-friendly operators would’ve gone a long way toward easing the transition.
October 14, 2025 at 1:10 PM
Hard agree. Combine deserved a graceful evolution, not quiet abandonment. Even a small set of first-party bridging tools or async-friendly operators would’ve gone a long way toward easing the transition.
Fair question! And a common gotcha I've had with AsyncStream.
In this case it’s fine, as each call to stream() creates its own independent AsyncStream/Continuation pair, and the actor fans out values to all registered continuations when send(_:) is called.
So yeah it’s multi-subscriber safe :)
In this case it’s fine, as each call to stream() creates its own independent AsyncStream/Continuation pair, and the actor fans out values to all registered continuations when send(_:) is called.
So yeah it’s multi-subscriber safe :)
October 11, 2025 at 1:34 PM
Fair question! And a common gotcha I've had with AsyncStream.
In this case it’s fine, as each call to stream() creates its own independent AsyncStream/Continuation pair, and the actor fans out values to all registered continuations when send(_:) is called.
So yeah it’s multi-subscriber safe :)
In this case it’s fine, as each call to stream() creates its own independent AsyncStream/Continuation pair, and the actor fans out values to all registered continuations when send(_:) is called.
So yeah it’s multi-subscriber safe :)
Why make this?
Because observing an @Observable class from a SwiftUI view is easy, but doing the same from another ViewModel got messy fast. Without @Published, you’re left juggling Tasks and AsyncStreams just to stay in sync.
Because observing an @Observable class from a SwiftUI view is easy, but doing the same from another ViewModel got messy fast. Without @Published, you’re left juggling Tasks and AsyncStreams just to stay in sync.
October 11, 2025 at 3:01 AM
Why make this?
Because observing an @Observable class from a SwiftUI view is easy, but doing the same from another ViewModel got messy fast. Without @Published, you’re left juggling Tasks and AsyncStreams just to stay in sync.
Because observing an @Observable class from a SwiftUI view is easy, but doing the same from another ViewModel got messy fast. Without @Published, you’re left juggling Tasks and AsyncStreams just to stay in sync.
Thank you for the shoutout @weijianduan.bsky.social! I’m really glad it’s managed to help you :)
January 10, 2025 at 11:37 PM
Thank you for the shoutout @weijianduan.bsky.social! I’m really glad it’s managed to help you :)
How embarrassing! Maybe it’s just an issue on my machine then 💀
December 15, 2024 at 6:36 AM
How embarrassing! Maybe it’s just an issue on my machine then 💀
I've always just used GPT-4o, but will give o1 a try after this. Keen to see the difference.
December 9, 2024 at 3:32 AM
I've always just used GPT-4o, but will give o1 a try after this. Keen to see the difference.