SpriteKit scene used as SCNView.overlaySKScene crashes due to SKShapeNode

Question

Created 9h

Replies 2

Boosts 0

Participants 2

I recently published my first game on the App Store. It uses SceneKit with a SpriteKit overlay. All crashes Xcode downloaded for it so far are related to some SpriteKit/SceneKit internals.

The most common crash is caused by SKCShapeNode::_NEW_copyRenderPathData. What could cause such a crash?

crash.crash

While developing this game (and the BoardGameKit framework that appears in the crash log) over the years I experienced many crashes presumably caused by the SpriteKit overlay (I opened a post SceneKit app randomly crashes with EXC_BAD_ACCESS in jet_context::set_fragment_texture about such a crash in September 2024), and other people on the internet also mention that they experience crashes when using SpriteKit as a SceneKit overlay. Should I use a separate SKView and lay it on top of SCNView rather than setting SCNView.overlaySKScene? That seemed to solve the crashes for a guy on stackoverflow, but is it also encouraged by Apple?

I know SceneKit is deprecated, but according to Apple critical bugs would still be fixed. Could this be considered a critical bug?

Boost

Answer 1

Frameworks Engineer OP

Apple

4h

Hello

The crash you posted is in SpriteKit code, not SceneKit code. However, I'm not certain this is a SpriteKit bug.

A common cause of SpriteKit crashes is accessing/modifying SpriteKit objects outside of SpriteKit's update loop. Even calling methods or accessing properties that look like they don't modify anything (e.g, -frame) can trigger mutation to SpriteKit's internal data structures, which is unsafe if done from multiple threads.

Indeed, while looking through past SpriteKit bugs I found one for the exact function shown in your crash report. The resolution of that bug was in the app, which was found to be updating SpriteKit objects from multiple threads.

I suggest looking through each of the crash reports in the Xcode organizer. Look for reports where multiple thread backtraces contain SpriteKit methods/functions. That should point to locations your code is accessing/modifying SpriteKit objects where it should not be.

-- Justin

0

Answer 2

Nickkk OP

4h

Thanks for your help. Updating SpriteKit from multiple threads is what I suspected too, but the crash shows only one thread accessing SpriteKit in that moment. Although the code in thread 1 does in fact update the path and fillColor properties of a SKShapeNode 6 lines before the one mentioned in the crash report. Could this still be the issue?

0