I really like this design pattern, and am pleased that Apple is advancing the idea.
But there are a couple of things I am not crazy about in this particular implementation.
It seems wedded to the idea of a variable deltaT.
Variable delta Ts are usually a bad idea. It results in non-deterministic gameplay outcomes. Where identical circumstances, identical user inputs and so on, produce different gamplay outcomes because of frame rate. In my experience this can be a) bad or b) very bad.
I am guessing the intention is to solve the problem of variable frame rates.
A better solution is to decouple simulation from rendering. I would suggest having a fixed gameplay tick, (using an integer tick time) and decouple rendering from gameplay by using interpolation.
This is roboust. Graphics run as fast as the hardware can allow, while gameplay is deterministic. (there are other benefits too).
A good way to do this is have all gameplay logic work using an integer: TickTime
While the renderer uses a float: RenderTime.
The current entity and component solution, as written, also makes it harder to write client/server network code.
In a modern client/server implementation it becomes useful to roll back time (and state) and retrospectively change state and resimulate.
So a network-friendly entity/component would include a function to record states to a ticktime-based recorder and then re-update from a recent tick value.
I'd suggest allowing:
setTickRate(ticksPerSecond:Int)
updateForTickTime(tickTime:Int)
Just a suggestion.