Nice to see you got a solution to your problem.
Have a look at what I’ve made for you, if you use it, it’s possible to have the subclass take care of itself, especially managing real-time rotations and size scale.
For advanceSimulationTime, basically you want it to be equal to your lifetime duration, that’s why I used the same variable for it (I hate magical numbers, so it’s better to have them set somewhere easy to manage).
If you use the enum, it’s possible to load many different particles, and have different parameters for each.
I haven’t tried to have multiple physical words before, just setting different physical properties to different nodes … So I guess using a field node can work, but also a state machine with many bitmasks or using GKBehavior … Honestly, endless possibilities and I’m unsure which is the best practice, maybe we get some complex game tutorial 
.
For the particles speed and so, it’s pretty much possible to do that. The easiest way is to have a reference of your frame (aka the distance particles should cross), then do any logical work by using the particles size, speed or time to get the correct parameters.
The code I shared is already in the perfect place for that (didChangeSize:), but you can use other parameters (in a Gundam game, I used player’s touches to increase particles’ birthrate, speed, angle and color blending options, to give impression of an engine thrust, as well as adding a smoke effect … Upon releasing the button, setting everything back to normal state without using advanceSimulationTime().
Hope this helps.
Side note: Maybe continuing the discussion on a separate thread would be better, to not hijack this thread’s main purpose.