I should remember to wait for Xcode beta before installing os beta )

I have the same error with Apple Sample project CoffeeGame so it's not an issue with my project. Also what's weird is that another sample code from Apple using FoundationModels on visionOS runs fine: FoundationModelsTripPlanner

In case my message was not very clear, the issues occur when I run the app on the Vision Pro in Debug. In that case the app takes 50 seconds to load ressources versus 2 when I uncheck "Debug executable" in the scheme.

I have the same issue using ARKit, SceneKit and GameKit access point on iOS 18 :( any fixes?

Hello, I've been struggling for a long time trying to get Grounding shadows to work with occlusion material but I haven't found any solution. What I need is to add occlusion material to reconstructed mesh so that virtual content is occluded by real world. I also need to enable physics on the mesh (I'm working on a game where characters interact with the real world). The grounding shadows work fine when I just add the collision and physics body to the reconstructed mesh. However when I do, there is no occlusion and it breaks the illusion. When I add a model to the mesh entities with occlusion material, then the occlusion works fine however the grounding shadows stop working. Thanks for your time. Gil

Still not fixed in beta 8 ;( And not a single word about swift data in the release notes...

@jhokit ok thanks for the insight on this. I'm also considering reverting to Core Data. At least it seems less dangerous than making a Swift Data/cloudkit data model migration with the risk of loosing user data ;( If this is not fixed for beta 8, I guess I will do the same as you although it's going to be a lot of work...

Still not fixed in iOS18 Beta 7. I'm starting to be really anxious as final version of iOS 18 is approaching really fast and I don't know how to fix this in my app. This is a breaking change from iOS 17 ;(

I have the same issue (even with latest beta 8). Did you find any workaround?

Same here

Hello, We are encountering the exact same issue (main thread lock) with SceneKit displaying SCNNodes with SpriteKit materials. Thread 0 name: Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000001b88e4678 __psynch_rw_wrlock + 8 1 libsystem_pthread.dylib 0x00000001f24cc150 _pthread_rwlock_lock_wait + 84 (pthread_rwlock.c:647) 2 libsystem_pthread.dylib 0x00000001f24d31a4 _pthread_rwlock_lock_slow + 728 (pthread_rwlock.c:761) 3 SceneKit 0x00000001bfccd760 C3DTransactionFlush + 436 (C3DTransaction.c:214) Thread 13: 0 libsystem_kernel.dylib 0x00000001b88e0540 semaphore_wait_trap + 8 1 libdispatch.dylib 0x00000001815b3bf0 _dispatch_sema4_wait + 28 (lock.c:139) 2 libdispatch.dylib 0x00000001815b42a8 _dispatch_semaphore_wait_slow + 132 (semaphore.c:132) 3 Metal 0x000000019bc4a4e4 -[_MTLCommandBuffer initWithQueue:retainedReferences:synchronousDebugMode:] + 188 (MTLCommandBuffer.m:275) 4 IOGPU 0x00000001caecac28 -[IOGPUMetalCommandBuffer initWithQueue:retainedReferences:synchronousDebugMode:] + 108 (IOGPUMetalCommandBuffer.m:39) 5 AGXMetalG14 0x00000001f3b491e4 -[AGXG14FamilyCommandBuffer initWithQueue:retainedReferences:] + 64 (agxa_command_buffer_objc.mm:232) 6 AGXMetalG14 0x00000001f3b4b608 -[AGXG14FamilyCommandQueue commandBuffer] + 52 (agxa_command_queue_objc.mm:24) 7 Jet 0x00000001cb0b54ec jet_context_Metal::ensureCommandBuffer(bool) + 52 (jet_context_Metal.mm:1589) 8 Jet 0x00000001cb0b5454 jet_context_Metal::override_Metal_render_state(id<MTLCommandQueue>, id<MTLRenderCommandEncoder>, jet_framebuffer*) + 176 (jet_context_Metal.mm:696) 9 SpriteKit 0x00000001c02bee0c -[SKSCNRenderer renderToTexture:commandQueue:] + 220 (SKSCNRenderer.mm:313) 10 SceneKit 0x00000001bfd89acc -[SCNTextureSpriteKitSource metalTextureWithEngineContext:textureSampler:nextFrameTime:] + 720 (SCNSpriteKitSource.m:370) 11 SceneKit 0x00000001bfcc3560 kSCNTextureSourceCallbackGetMetalTexture + 64 (SCNTextureSource.m:352) 12 SceneKit 0x00000001bfdf1118 C3DTextureProxyGetMetalTexture + 88 (C3DTextureProxy.c:153) 13 SceneKit 0x00000001bfdc3b60 -[SCNMTLResourceManager(Textures) renderResourceForImageProxy:sampler:engineContext:] + 232 (SCNMTLResourceManager+Textures.mm:658) 14 SceneKit 0x00000001bfd2f5bc -[SCNMTLResourceManager(Textures) renderResourcesForEffectSlot:withEngineContext:] + 132 (SCNMTLResourceManager+Textures.mm:616) 15 SceneKit 0x00000001bfde3c24 __39+[SCNMTLRenderContext registerBindings]_block_invoke_6.540 + 84 (SCNMTLRenderContext.mm:4397) 16 SceneKit 0x00000001bfce85dc _execute(SCNMTLRenderContext*, DrawCommand) + 4656 (SCNMTLRenderContext.mm:3595) 17 SceneKit 0x00000001bfd14720 -[SCNMTLRenderContext drawRenderElement:withPass:] + 648 (SCNMTLRenderContext.mm:0) 18 SceneKit 0x00000001bfcf9e5c _processRendererElement(SCNMTLRenderContext*, __C3DRendererElement*, __C3DFXPassInstance*) + 840 (SCNMTLRenderContext.mm:3053) 19 SceneKit 0x00000001bfd30a08 -[SCNMTLRenderContext processRendererElements:count:engineIterationContext:] + 1120 (SCNMTLRenderContext.mm:2675) 20 SceneKit 0x00000001bfcc0fa4 C3D::DrawNodesPass::_renderEye(long) + 560 (C3DDrawNodesPass.mm:472) 21 SceneKit 0x00000001bfcbb3f4 C3D::DrawNodesPass::execute(C3D::RenderArgs const&) + 248 (C3DDrawNodesPass.mm:273) 22 SceneKit 0x00000001bfcbaac0 C3D::__renderSlice(C3D::RenderGraph*, C3D::RenderPass*, unsigned short&, C3D::RenderGraph::GraphNode const&, C3D::RenderGraph::Stage*&, C3D::RenderArgs, bool, id<MTLCommandBuffer>&) + 1860 (C3DRenderGraph.mm:769) 23 SceneKit 0x00000001bfcfd7fc C3D::RenderGraph::execute() + 5436 (C3DRenderGraph.mm:1354) 24 SceneKit 0x00000001bfcc5c30 -[SCNRenderer _renderSceneWithEngineContext:sceneTime:] + 512 (SCNRenderer.m:5217) Would love to know if a solution was found for Hai. On our side the problem occurs when we add too many objects with a SpriteKit texture. We suspect an issue with the max numbers of command buffers in SceneKit. But we have not found a way to modify the default max (CommandQueue on SceneView is readOnly). Thanks Gil

Hello, Same issue here since iOS14. Still haven't found any workaround ;(

Hello, We are currently working on trying to persist ARWorldMap with mesh information (from Lidar). From what I see, ARMeshAnchors are not persisted in the ARWorldMap (But ARPlaneAnchors are persisted) when saving the worldmap. Is this a bug or is it working as intended? Thanks Gil