You can create a CAAnimation and hand it to -[SCNNode addAnimation:forKey:] on as many nodes as you want. No apparent side-effects. I just couldn’t find this documented anywhere.
If you try to add an animation to an SCNNode that’s not yet part of a scene graph, nothing will happen. It won’t give any indication of failing, and the performance of rendering implies it’s still running them, but there will be no visible effect. So, addChildNode: and then addAnimation:forKey:.
Ugh… SceneKit is both promising and frustrating. It appears to be a very stereotypical case of “version 1” syndrome – nice idea, flaky implementation and very skimpy documentation.
So amongst the many strange, undocumented foibles it has, one in particular is quite egregious. When you add an SCNNode to your SCNView-rendered scene, containing an SCNCamera, the “pointOfView” property of the SCNView is magically updated to point to it. Pretty cool. I’m not sure when – not when it’s added to the scene, that’s for sure… perhaps when the scene next draws, and find it doesn’t have a pointOfView assigned yet?
Anyway, so far so good. What’s not good is when you switch apps and come back to find your camera hasn’t visibly moved – your scene renders as you left it – yet none of your camera controls work anymore. WTF? An hour of NSLogs and lldb tedium later, and I discover that the pointOfView has been “magically” changed to some other node. This other node doesn’t appear in the scene, wasn’t created by me, still has my SCNCamera attached to it – I hope it’s not fighting with my real SCNNode, which still thinks it owns the camera – and has no identity other than the name “kSCNFreeViewCameraName”.
What’s weirdest in all this is that it only happens if you switch apps in a certain way. Command-tab or clicking on another window won’t do it, but clicking on an app in the dock will. WTF?
Update: this only happens if the “Allow Camera Control” property is set on the SCNView. It appears it’s not the changing of apps or focus or anything else that triggers this bug – perhaps better dubbed “a deliberate but poor design choice”, given this new information – but rather a mouse event arriving at the view. I’m not sure how you’re supposed to deal with that… I guess if you’re doing any custom camera work yourself, you’ll just have to turn that property off.