@lulabay Sort of. That's a different issue, stemming from the same root cause. One that's famous and integral to an un-fixed cocos2D-iPhone, which hyperPad is based upon. I've supplied them with sufficient info on the fix, they've said they can't (or won't) do it, despite it being something universal, and without side effects.
At the core of cocos2D-iPhone is a reliance on the unreliable, and uncertain flipping flags of a thing called CADisplayLink.
The solution I've shared, for this problem, will likely fix the audio and timing issues prevalent in iOS 12, as iOS 12 far more aggressively asserts control over (and more variance upon) CADisplayLink. Ultimately CADisplayLink will be completely untethered from any connection to device reality as it's used for all manner of frame rate efficiency variance efforts within iOS.
ProMotion displays are coming to iPhones sooner rather than later.
The solution, base the game loop on absolute time, and do own calculations of when a frame should be ready to present. Every other engine does this, as does every fixed version of cocos2D-iPhone. Or, you can do a hybrid approach, get ready to draw then wait for a CADisplayLink call, which many others do. Relying on CADisplayLink, though, causes the problem, as it's not regular, nor reliable.
This causes a race condition, wherein memory/objects aren't released until the OS senses memory pressure, at which point you see that stutter.
The two creators of hyperPad maybe forced to make a fix for iOS 12 that relies on Mach (absolute) time. It's not hard, and somewhere on these forums I've even posted the code to do it.
