Why have a bug tracker if all you are going to do is say behavior is correct? This latest response really grinds my gears. There is a very annoying bug in Sprite Kit. The bug is when changing the pause variable, it inadvertantly changes all of the children pause states as well. Well, let's say i have a ton of particles that have exploded, and my character can freeze time. All particles are now in the paused set. Then the user leaves the app, forcing the scene to pause. When coming back, naturally I want to unpause the scene. Well now all of those particles are unpaused, While my engine is in a time freeze state. I now have to work around this issue, keeping track of the pause manually. This cannot be an intended feature, I can't think of any reason as to why the system needs to change my pause state of the nodes that I set, it should be my decision to change this state. I can see them using this variable to stop nodes If that is how they decide to pause nodes regardless of the state of the parent, but this is not the case. If the parent is paused and the child is not, the child is in a paused state and does not move.
IsPaused bug
If it's any consolation, and I know it's probably not, I sent a critique of the new docs format a few weeks back. The new docs format is a very bad joke.
Too much white space. No logical ordering of anything. No simply referencing to pertinent and and relevant others. The inheritance and traits are at the bottom of each page, uses Symbol like a Ruby programming nodding to the fact Swift is compiled, most everything is incomplete, there's no examples of how to use anything, etc etc.
Response:
"Expected Behaviour".
Oh... joy!
One possible way to solve your problem, and it might take enormous work, would be slowing time rather than a true pause. Slow things to 0.01 of normal time, or something like that. Kind of like the super slowmotion in Inception. It's so slow that it feels like everything is almost paused. This way the system's attempts to pause things during an interruption will behave as intended.
The only other way to deal with this, I can think of, is when the user exits your game, you get a notification you can use to clean up anything you need to sort before the system backgrounds your app. When you get this notification, you could unfreeze time right then, and the system will then refreeze time as part of the process of backgrounding your app/game. But this won't be perfect, there will be a little skip. And you'll need to refreeze time when your app is brought back to the foreground.
Maybe this will work... feel free to admonish me if these ideas won't work.
I already handle this by overriding pause on all of the extension nodes, and never using SKNode. I have a global variable that sets what node is being paused, then in all of the extensions, check if that is the variable, and if not, skip it.
I would like to be able to use SKNode again, which is why I am posting on here to see if anyone has anything better.
Actually, setting speed to 0 may be a better option to use, Thank you for that suggestion, It is an ok work around for now, providing I do not do anything that alters the speed for some reason.