2

When importing the IQKeyboardManager library in my project, after upgrading to XCode 14, I get these warnings in some of the imported classes:

enter image description here After making a copy of 'self', only non-isolated properties of 'self' can be accessed from a deinit.

I am getting this warning in deinit of most of the classes, I am getting this warning in some of the other third party library classes as well. I understand its meaning, but what should be the workaround for this? Any source where we can get an idea for fixing this?

Vikas Saini
  • 483
  • 4
  • 16
  • 1
    What's the question? Swift 5.7 introduces new and better warnings about this and in Swift 6 those warnings will be errors. Do what they say. What you were doing was always wrong. Fix it sooner rather than later. – matt Sep 13 '22 at 12:34
  • 1
    I was very clear while writing the question, I said I understand the meaning of this warning and was asking for any source where I can read about this or any workaround about the same. I am pretty much sure that most of the developers using Swift 5.7 and latest xCode is getting this warning. – Vikas Saini Sep 13 '22 at 12:38
  • Well that's not a legal SO question. – matt Sep 13 '22 at 12:40
  • Why are you writing custom deinits? – Shadowrun Sep 13 '22 at 12:42
  • Looking at your code now that you've posted it, it's even harder to see what the question is. What you're doing in your deinit is both illegal and unnecessary. – matt Sep 13 '22 at 12:43
  • I am using IQKeyboardManager for keyboard handling and there i was getting this warning – Vikas Saini Sep 13 '22 at 12:47
  • Delete the deinits, they're pointless – Shadowrun Sep 13 '22 at 12:53
  • you mean, removing deinits will have no effect on the code. – Vikas Saini Sep 13 '22 at 12:54

2 Answers2

4

In your screenshot I can see you are using the IQKeyboardManager library in your project. The warnings are not about your code, but about the IQKeyboardManager code you have imported.

More context: swift language is changing what is and is not allowed. This specific issue is being discussed on the Swift forum. Depending on the outcome of this discussion, the IQKeyboardManager team may or may not have to change the code.

For now, I don't see a problem if you just ignore the warnings. In the future, the issue will probably be solved for you, either by the Swift team or by the IQKeyboardManager team.

I have also filed an issue on the IQKeyboardManager github.

Mario Huizinga
  • 780
  • 7
  • 14
  • 1
    The IQKeyboardManager team already has fixed the issue. It will be part of the next release (after 6.5.10), but it seems they are not in a hurry with publishing a new version. – Mario Huizinga Oct 10 '22 at 07:40
  • And now the fix for this issue is released in IQKeyboardManager version 6.5.11. – Mario Huizinga Jan 16 '23 at 19:47
2

what should be the workaround for this?

You don't need to set anything to nil in deinit because straight after that, the memory is going to be deallocated and all of the instance variables will be "released" (using Objective-C terminology) before that happens.

Your entire deinit is redundant and can be removed. deinit in Swift is only required to clean up resources that are not managed by Swift, for example, if your object wraps a Unix file descriptor that needs to be closed.

JeremyP
  • 84,577
  • 15
  • 123
  • 161
  • 3
    Not completely true. Context is important. For example, using SpriteKit with multiples scenes with a complex wrapper system around it using other delegates, such as custom UIKit UI & etc DOES require deinit to release the scene from memory 100%. I know for a fact, because I stumbled onto bugs that can NOT be fixed other ways that arise from a a scene still in memory. Deletgates can be the first thing still holding hands with other classes. – Krekin Oct 09 '22 at 15:30
  • Agree with @Krekin. I have a scenario when an observer needs to be removed from the Notification Center. Doing this requires referencing it. I guess Swift 6 would say do that before deinit()... – PKCLsoft Oct 18 '22 at 01:56
  • @PKCLsoft Any reference properties of the object are always released when wthe object is deallocated. Removing an object from the notification centre is not that. So it is a potential use-case. That said, yes, you probably should have done that before you get to `deinit` – JeremyP Oct 18 '22 at 07:53
  • @JeremyP having looked at my case, the class in question is instantiated on app creation via the storyboard (it's a view) and is never really disposed of, so I guess the deinit() will never actually be called, and there is no scenario where the observer would actually be removed. I tend to write deinit() methods by habit and try to catch things like observer removal when I do. Given there was no deliberate action to remove the view in the life of the app, there's no obvious place to remove the observer prior to deinit. It's an interesting scanario but probably not uncommon. – PKCLsoft Oct 19 '22 at 21:37
  • I'm the type of psychopath that writes a "func cleanUp()" method that sets delegates to nil, cleans up arrays, etc.. This method is called in deinit but also manually in situations where I have peculiar situations – Krekin Oct 21 '22 at 17:14