I think these are rather strange things.
The idea is strongly inspired (mainly 1: 1 mapping and “theft”) from cocos2D, where they were used as a way to avoid direct interaction with the game loop, state and time (sort of). Actions provide a kind of modularity and abstraction for processing both time and the creation and use of activity, as well as a very primitive approach to their conclusions.
You can see how similar actions of SpriteKit and SceneKit relate to original ideas when reading here: http://python.cocos2d.org/doc/programming_guide/actions.html
As a result of the diverging and developing nature of their creation, someone forgot to give them awareness of their condition, despite the fact that they affect some aspects of the state of the nodes. It would be almost ideal to understand that an Action object has a “running” state. But as far as I know, they do not.
Instead, you can check if Node has this action, and if so, then it assumes that the action is being performed.
Despite the fact that most of the actions do something for a long time, you also cannot ask them about how far they went through their duration, nor what values they just fired, or sent forward. But there are actions that do this, in particular, to cope with the fact that this is absent for all actions, means that if you want it, you need to use a special action that provides this.
And such a recursion on and back for oneself for objects that were supposed to be innate is the most annoying part of the actions that was not thought out from the point of view of someone familiar with the timeline and key frames.
In general, and in the end: you can not query the status of the action, its progress or the value that it just used or will use the following. This is absolutely ridiculous.
I do not know how this was missed in the various evolutions of Actions ... they are the developers of time and modular activity. It seems so logical to include a report on the status and progress, which ... well, I don’t know ... it’s just strange that they don’t.
So, to answer your question:
You can use completion handlers that call some code when the action completes, set values or call other functions, or clear stuff or whatever.
The actions of a sequence are in SCNAction.sequence ..., which is a way to start an action sequentially, and internally use some actions that trigger blocks of code when you want to trigger customization of what you need, when you need, in the sequence of actions. All could have been avoided if there were transparency in the values that currently have actions of both time and properties ... but ...
You can also use some special actions that have some idea of the value they are editing due to the changes made to them. I am familiar with the possibilities of installing float in SKEaseKit , but you can probably do it (if you are much better than an encoder than me) in SceneKit and SpriteKit. SKEaseKit hides a couple of action-changing values that are very useful.
I use it, for example, like this, where this mess changes the value from 0 to 1 for the duration (time), in this case linearly, and each frame (hopefully) updates the .xScale Node on which this moveAction is executed:
let growAction = SKEase.createFloatTween( start: 0, ender: 1, timer: time, easer: SKEase.getEaseFunction(.curveTypeLinear, easeType: .easeTypeOut), setterBlock: {(node, i) in node.xScale = i} )