User Profile

I updated Xcode to version 14.3.1 and it still crashes regularly. It seems to be something to do with GIT source control: Thread 16 Crashed:: Dispatch queue: DVTSourceControlGitXPCClient :: Proxy Completion Queue 0 libobjc.A.dylib 0x1a27e7ff4 AutoreleasePoolPage::releaseUntil(objc_object**) + 4 1 libobjc.A.dylib 0x1a27e4b7c objc_autoreleasePoolPop + 256 2 CoreFoundation 0x1a2c1a59c _CFAutoreleasePoolPop + 32 3 Foundation 0x1a3bc8b14 __NSIndexSetEnumerate + 1104 4 Foundation 0x1a3baa024 _NSKeyValueObservationInfoGetObservances + 412 5 Foundation 0x1a3baa150 NSKeyValueWillChange + 176 6 Foundation 0x1a3b9ad18 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] + 464 7 Foundation 0x1a3bc4f10 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 64 8 Foundation 0x1a3bde43c _NSSetObjectValueAndNotify + 284 9 DVTSourceControl 0x10453b480 -[DVTSourceControlWorkingCopy(Operations) updateCurrentLocations:branches:stashes:remoteRepositories:remoteBranches:currentLocation:recentLocations:primaryRemoteRepository:currentState:] + 2264 10 DVTSourceControl 0x1045b2e78 closure #2 in DVTSourceControlWorkingCopy.updateCurrentLocations(completionBlock:) + 1424 11 DVTSourceControl 0x104597cfc closure #1 in DVTSourceControlGitXPCClient.complete(with:) + 60 12 DVTSourceControl 0x104578114 thunk for @callee_guaranteed () -> () + 20 13 DVTSourceControl 0x104578134 thunk for @escaping @callee_guaranteed () -> () + 20 14 libdispatch.dylib 0x1a29cc400 _dispatch_client_callout + 20 15 libdispatch.dylib 0x1a29db97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 16 DVTSourceControl 0x104597c30 DVTSourceControlGitXPCClient.complete(with:) + 228 17 DVTSourceControl 0x104597f78 DVTSourceControlGitXPCClient.complete(with:context:) + 588 18 DVTSourceControl 0x1045ce2ec closure #1 in DVTSourceControlGitXPCOperation.init(proxyObject:identifier:client:context:operationBlock:) + 108 19 DVTSourceControl 0x104578bfc DVTSourceControlXPCOperation.complete(with:) + 92 20 DVTSourceControl 0x104578ed0 closure #1 in closure #1 in DVTSourceControlXPCOperation.operate(with:) + 68 21 DVTSourceControl 0x104578858 closure #1 in DVTSourceControlXPCOperation.execute(from:to:block:) + 84 22 DVTSourceControl 0x104579d30 partial apply for thunk for @callee_guaranteed () -> () + 20 23 DVTSourceControl 0x104578134 thunk for @escaping @callee_guaranteed () -> () + 20 24 libdispatch.dylib 0x1a29cc400 _dispatch_client_callout + 20 25 libdispatch.dylib 0x1a29db97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 26 DVTSourceControl 0x104578434 DVTSourceControlXPCOperation.execute(from:to:block:) + 276 27 DVTSourceControl 0x104578300 DVTSourceControlXPCOperation.execute(from:to:block:) + 120 28 DVTSourceControl 0x104578e5c closure #1 in DVTSourceControlXPCOperation.operate(with:) + 240 29 DVTSourceControl 0x1045b3f28 thunk for @escaping @callee_guaranteed (@guaranteed DVTSourceControlRevisionLocationResultType) -> () + 52 30 CoreFoundation 0x1a2c3c7f4 __invoking___ + 148 31 CoreFoundation 0x1a2c3c668 -[NSInvocation invoke] + 428 32 Foundation 0x1a3b954fc __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 16 33 Foundation 0x1a3b93b68 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 520 34 Foundation 0x1a3b934c4 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 + 188 35 libxpc.dylib 0x1a28c1650 _xpc_connection_reply_callout + 124 36 libxpc.dylib 0x1a28c1540 _xpc_connection_call_reply_async + 88 37 libdispatch.dylib 0x1a29cc480 _dispatch_client_callout3 + 20 38 libdispatch.dylib 0x1a29ea624 _dispatch_mach_msg_async_reply_invoke + 344 39 libdispatch.dylib 0x1a29d3960 _dispatch_lane_serial_drain + 372 40 libdispatch.dylib 0x1a29d462c _dispatch_lane_invoke + 436 41 libdispatch.dylib 0x1a29df244 _dispatch_workloop_worker_thread + 648 42 libsystem_pthread.dylib 0x1a2b78074 _pthread_wqthread + 288 43 libsystem_pthread.dylib 0x1a2b76d94 start_wqthread + 8

Any fix or workaround for this problem yet? Xcode crashes multiple times an hour for me and it's been going on for a month or more. I just installed the latest Venture 13.5 beta hoping it might resolve it, but Xcode crashed again within 5 minutes.

Is there a suggested alternative for on-demand resources in a Catalyst app? This is a really key feature that's missing. Our app size on iOS is quite reasonable but all the resources for the macOS Catalyst app make the download size too big (~2GB). Is there some way to use the Hosted Asset-Packs URL with iCloud? Our app currently does not have any need for our own web server and so we'd like to find an Apple-supported solution. Thanks!

Same here. We first noticed it on June 10th (5 days ago), called App Store Support and they first told us we'd have to file a TSI. I balked at that since it's clearly an App Store problem (we've been submitting updates to this app for over a year) and they said they'd get back to me. So far, no further response from Apple.

Apple hasn't updated USDPython tools in well over a year and this is still broken.

Still no improvement in this week's iOS 14.5 Beta 4 and macOS 11.3 Beta 4. And still no help from Apple on a workaround. Sigh.

Unfortunately, I have not heard of anyone who has found a workaround for this issue and the performance is still terrible in today's iOS 14.5 Beta 3 and macOS 11.3 Beta 3 builds.  The cause of the problem seems to be that SceneKit is (re-)compiling a 4,500 line Metal shader program every time you add a node or light to a scene. MetalKit appears to do the compilation with the GPU but SceneKit invokes MTLDevice.makeLibrary synchronously in a CADisplayLink handler so it actually hangs the whole app UI for about 200-400 msec each time you invoke .addChildNode. The result is app hangs of many seconds if you add multiple model nodes to a scene. MetalKit caches the compilations in the file system, so if your app doesn't change anything, you might get lucky and avoid the hang in future .addChildNodes of the same model, but there seem to be numerous reasons the cache misses or is flushed. See this earlier Forum thread for more discussion of this problem. - https://developer.apple.com/forums/thread/659856

I still have not found a workaround and the performance is still terrible in today's iOS 14.5 Beta 3 and macOS 11.3 Beta 3 builds.

I've also discovered this recently. I've also found that RealityConverter does export all the skeleton animations correctly when the input file is a .GLB or .GLTF. So I've been using the most recent releases of Cheetah3D or Blender to import the .FBX, then export to .GLB then use RealityConverter to export to .USDZ. Not very convenient for lots of models, but at least it seems to work.

arthurfromberlin: Sounds like you're encountering similar problems. You can see it via Instruments / SceneKit by just running a sample app made using the standard Game template in Xcode. BTW: I have tried (and even shipped) many different attempts to use both the synchronous and background versions of the SCNView.prepare method. I have had many problems with both of them. The background version crashes (at least since iOS 13) if the view is removed from the UIWindow (e.g., user changes views). I've debugged this and it's lacking a check for a null window but so far have not been able to convince Apple to fix it (FB7716713 May 27, 2020). Trying to use the synchronous version on a non-main DispatchQueue also crashes randomly and, at least for our app, actually makes it slower when it doesn't crash (FB5418811 Feb 11, 2019). Both of them seem to still cause the the shaders to be compiled during the CADisplayLink frame refresh, so they hang the whole app UI anyway. I've removed all uses of prepare from our app, at least until the bugs are fixed. I agree with your assessment of RealityKit also: not a replacement for the functionality of SceneKit yet with a few too many missing features.

Graphics and Games Engineer : Thank you for your response. The Metal cache is helpful, but for some reason it is either too small or fails much of the time. During my investigations, for some scenes, the "compile time" is indeed a couple of milliseconds, so it must be hitting the cache. But I cannot figure out a pattern or how to get the cache to work all the time. Is there some way to adjust the size? I see what looks like the cache in Library/Caches/app-id/com.apple.metal/functions.list, functions.data, libraries.list, libraries.data, so I see it written when a scene is loaded and shaders are compiled. Is there doc on how it works? I'm also not sure what you mean by "...after each reboot." At least for our app, SceneKit scenes ARE the app UI, so there really isn't a way to show something else while the shaders compile. I'd be happy if there was some way to just get the shader compilation off the frame refresh (CADisplayLink) so it wouldn't hang the entire app UI. If you have some suggestions on how to achieve that, it'd be super appreciated.

Unfortunately I've verified with Instruments that the performance problem still has not been fixed in iOS 14.3 RC. The UI hangs are a really bad experience. In our app loading multiple models into a scene, we see hangs like this being logged in the Console app: com.apple.hangtracer Hang detected: 10.03s (always-on hang reporting) com.apple.hangtracer Hang detected: 1.55s (always-on hang reporting)

The shader compile time problem is still happening in the latest iOS 14.3 Beta. I've attached shader compile times using Instruments running our app on an iPad running 14.3 Beta. It's such a pity that with all of Apple's focus on 3D, AR and GPU performance, especially with the new M1 chip-based Macs, that they haven't resolved such a big performance problem yet. When users get frustrated with our app's UI appearing to hang for seconds at a time, they're unlikely to stick around to appreciate the beautiful billions of triangles-per-second rendering. I sure wish we could come up with a workaround for this. Start Duration Stage 00:00.067.901 350.18 ms Compile shader 00:00.483.174 382.15 ms Compile shader 00:00.893.477 383.61 ms Compile shader 00:01.342.543 368.81 ms Compile shader 00:01.713.172 355.37 ms Compile shader 00:02.076.597 400.08 ms Compile shader 00:02.521.364 389.56 ms Compile shader 00:02.911.883 352.88 ms Compile shader 00:03.266.651 347.64 ms Compile shader 00:04.025.355 494.98 ms Compile shader 00:04.527.612 392.55 ms Compile shader 00:04.953.428 408.40 ms Compile shader 00:05.362.909 370.68 ms Compile shader 00:05.736.013 368.20 ms Compile shader

The warning logging has been fixed in iOS 14.2, but the performance problems still happen consistently in iOS 14.2 and in the latest macOS 11.0.1 RC2. I decided to dig into the performance problems with Xcode a bit more and basically I found that SceneKit is using MTLDevice.newLibraryWithSource to synchronously compile a roughly 4,200 line (~144KB) Metal shader source string. This is happening in the render loop which is apparently invoked as a CADisplayLink handler, which is why the whole UI hangs for seconds at a time. To verify that this is the problem, I captured one of the SceneKit shader source strings and options with a breakpoint and used them in a simple test program to compile and time it 50 times. On an iPad Pro, each compilation takes about 200 msec. On an iPad 6th Gen, that takes about 340 msec per compilation. This matches what I’m seeing using Instruments in our real SceneKit-based app. It appears that the compilation is happening on the GPU and not the CPU. If no changes are made to the source string between compiles, it appears that MTLDevice keeps a (hash-based?) cache and so the subsequent compilations are more like 6 msec. For the test program, I appended a space character each iteration to the source string, so I was able to force it to recompile every iteration. SceneKit appears to make changes to the source and recompiles it when each set of new nodes with meshes or lights are added to the scene, which again explains what I see with Instruments. Just to see what the what a “minimal” Metal shader compile time is like, I tried it with a simple 24-line source string with only a vertex and fragment shader and it takes about 8 msec per compile. I’m not sure what Apple is going to do to avoid recompiling that four-thousand line source file during frame update, but the current design seems like it doesn’t work well. I've passed along all of this (in more detail) via Feedback to Apple.

I've tried this for quite a while also and it has never worked well. A USDZ file is exported, but it's usually useless because there are so many bugs (which I've reported). It would be great if someone at Apple actually worked on this, but so far it doesn't seem to get much love. Here's a quick example of how to at least try it:     func make3DModel(fileName: String) -> URL? {         let sceneURL = URL(fileURLWithPath: NSTemporaryDirectory() + fileName + ".usdz")         let options: [String: Any] = [SCNSceneExportDestinationURL: URL(fileURLWithPath: NSTemporaryDirectory(), isDirectory: true)]         if sceneView.scene?.write(to: sceneURL, options: options, delegate: self, progressHandler: {(progress, error, stop) in             if let error = error {                 NSLog("ShareScene \(String(describing: error))")             }         }) != true {             NSLog("ShareScene Unable to write scene to \(sceneURL)")             return nil         }         return sceneURL     }