New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-5816] KeyPath-based KVO: Unable to stop observing owned object on deinit #3809
Comments
cc @Catfish-Man |
Hmm. I wouldn’t expect this to be an issue in iOS 11/macOS 10.13 due to KVO changes, but could be important for backwards compatibility. |
Just tested on iOS 11. No issue there. |
Still an issue in macOS 10.12.6 and iOS 10, Swift 4.0 Snapshot 2017-10-09 (a). This makes the new closure-based observe basically unusable for us since we need to be compatible with iOS 10. Only in objects with lifecycle methods (viewDidDissapear and such) can this be workaround by invalidating before dealloc. |
Also, according to the Foundation Release Notes for macOS 10.13 and iOS 11 (https://developer.apple.com/library/content/releasenotes/Foundation/RN-Foundation/index.html), the automatic unregistration of observers on dealloc seem to be subject to some conditions (automaticallyNotifiesObserversForKey). |
It seems like fixed in Swift 5.1 (iOS 11). But this fix leads app to crash with previous iOS workaround (Manually removing observer in deinit). What should I do? Error: `Cannot remove an observer <_NSKeyValueObservation 0x28196ef10> for the key path "textField.selected" from <#{SomeClass} 0x10192a480> because it is not registered as an observer.` |
Definitely this is fixed by apple/swift#20103 |
Environment
Version 9.0 beta 6 (9M214v)
Additional Detail from JIRA
md5: cc033b62e7f6826a74055dc7ea71bfeb
Issue Description:
MyHostObject owns MyObject and observes changes of it's value:
With Objective-C equivalent, MyHostObject would still be able to remove observation from myObject.
This is happening because NSKeyValueObservation holds a weak reference to an object. That weak reference turns to nil too soon. My suggestion is to use unowned or Unmanaged<MyObject> reference.
The text was updated successfully, but these errors were encountered: