# \[Pitch\] Observation **URL:** \ **Category:** Pitches\ **Created:** [December 14, 2022, 6:07pm UTC](https://forums.swift.org/t/pitch-observation/62051 "2022-12-14T18:07:26Z")\ **Posts on this page:** 1\ **Showing post:** 42
**Author:** ![David\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_smith/32/37508_2.png) [@David\_Smith](https://forums.swift.org/u/David_Smith)\ **Post date:** [December 15, 2022, 10:47pm UTC](https://forums.swift.org/t/pitch-observation/62051/42 "2022-12-15T22:47:36Z")
There's a number of issues we ran into with KVO, all around concurrency: - If you're using locks to protect your state, you want to send KVO notifications outside the lock (recursive locks aren't sufficient because they can just dispatch\_sync to another queue and then deadlock), which means if you send will- and did-change _and_ want to avoid sending change notifications when nothing changed you need to do: - If you're getting the updated value "from the outside" and don't have it cached, then you may simply be unable to do this. This came up with iCloud UserDefaults, where we could get a change notification from another device, and by the time it made it to the client process the old value was gone. - With manual willChange/didChange, it's possible for developers to mis-nest them, like Most of these issues matter _way_ less when you're only using observation for UI updates on the main thread of course. I don't think these are necessarily fatal flaws, but it's worth thinking things through carefully. --- _[View the full topic](https://forums.swift.org/t/pitch-observation/62051)._