I am running IOS18.1 Beta 4 but had the problem with previous versions of IOS. I have been getting the errors in _dispatch_assert_queue_fail. No I am NOT modifying the UIVIEW or any buttons during this. The program had been running for several seconds. The error can be pretty much reproduced at will by running for a few seconds I have the back trace from the point of the error if needed. this has been going on since the IOS17 Beta testing.

[quote='789248022, DTS Engineer, /thread/756237?answerId=789248022#789248022'] Try doing less work in a pass or optimize it to help ensure there is a drawable available. A speedier SoC can also process your workload faster. [/quote]

one further question, is there an inventory of active ARSessions in nn ordered list that can be examined?

Actually I tracked it to the initial processing of the Room Capture view class and there are NEW methods that get the errors and they are related to the NSCoder/NSDecoder methhods invoked . I can consitently reproduce the errors using the Out of the Box Room Plan demo from WWDC. I submitted a bug report via the. feedback mechanism from IOS18 Beta 4 after noticing a pattern of behavior stepping the base demo kit through the initiation processing 30+ times where I saw two patterns

Where is the log that I would look at to evaluate the possiblllity of a device or OS issue?

not so harmless at all my metal app won't run properly

BTW for my version of RoomPlan the error is NOT harmless because Metal cannot load its Texture and Vertex files. Without those files Metal has nothing to work with.

For me, the error was first observed when running late IOS17 levels. If you look at the URL, the path is missing the host component from the URL resulting in a string for the url of "file:///System/Library/CoreServices..." which is an invalid URL construct due to a missing host component after the "file://". That is why you are seeing the error. The path you are seeing in the URL is on the Mac system driving the App on the iPhone and that path does not exist on the iPhone device. I have been trying to track down component that it originaties in. Ir you take a demo application and step through the AppDelegate.swift from the entry point, you get the error on the execution of the second line of the AppDelegate class initialization on the line that starts "var window". It consistently stops with the execution of that line. "@main class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { return true" it is any comfort I was seeing the error when running a GIS application on Microsoft systems too because of a scripting error in setting up the configurations on a multi host distribute application.

Another question is why does the URL not have a host id to allow it to follow the path. Presumably the host field is the identity of the build host should be available in a number of places for the loaded executable

I have observed something similar on my iPad

I started to download it and it failed.. I did a restart of my Mac mini and then restarted Xcode which worked.

The only question left is what parameter in the project that needs to be changed to correct the behaviour of Metal and other code in the app

I found the answer to my own question. It turns out that the URL for data files was Malformed by the library routines. There. is no target Host available in the URL so it prepends a string of "///" to the directory path to the particular file being referenced on the foreign host. I seem to have missed setting up the info.plist configuration item that defines the HOST to be targeted for fetching the related file from the build machine or libraries. With all the Useless information that is dumped in the logs, I am surprised that there was NOT a diagnostic or warning about the Malformed URL missing the Host name from which to fetch the data

Is there a corresponding directory tree on the iPadOS.platform? I. have not been able to locate it through the file management UIs that are available

The question is why did the system version bundle not get found if I could find it by a manual search? On which machine does that message originate? I presumed it is background from the Mac I am using for Xcode debugging.