Update: we have now tested the setComputeDevice workaround, and it cannot work for VNDetectBarcodesRequest. Some further findings below, plus a correction to my original post. The non-ANE path has no weights — reproducible on a healthy device Restricting the request away from the Neural Engine is accepted, but every perform() then throws: Error Domain=com.apple.Vision Code=9 "Could not create/add network to inference plan - Espresso exception: "I/O error": Missing weights path mrcdetector.espresso.weights_nonane (DESIGN)" and this appears on stderr for every analyzed frame: [Espresso::handle_ex_plan] exception=Espresso exception: "I/O error": Missing weights path mrcdetector.espresso.weights_nonane status=-2 Reproduction (iPhone 16e, iOS 26.5, ~4 lines of code, works every time): let devices = try request.supportedComputeStageDevices[.main] ?? [] // 3 devices are reported; pick the .gpu one request.setComputeDevice(gpuDevice, for: .main) try handler.perform([request]) The important part: this device is completely healthy. Its barcode scanning works normally on the ANE. So this is not the broken state from my original post — the non-ANE weights for mrcdetector appear not to be shipped at all. That makes the failure in my original post unrecoverable: there is no non-ANE path to fall back to. Also logged by the system immediately before the switch, in case it means something: numANECores: Unknown aneSubType VisionKit fails too, and it fails silently On a device in the broken state, DataScannerViewController starts without any error and then recognizes nothing at all — no barcode, indefinitely. It reports neither frames nor errors, so there is no way to detect this from the delegate. We had to add a watchdog that fires when nothing has been recognized for 10 seconds, purely to make the state observable. So on an affected device all three paths are dead: AVCaptureMetadataOutput (silently), Vision on the ANE, and VisionKit. Vision off the ANE was never an option per point 1. The state is intermittent per device, and rare I described it as persistent, which was based on what we could see at the time. With more data that is only half right: it persists until reboot, but devices do come back. One device logged ~37,000 consecutive failures on one day and ran without a single failure days later. Frequency, now that we log this properly: one occurrence across 42 devices and 260 scanner sessions over five days. It is rare, which is also why we cannot give you an on-demand reproduction for it — unlike point 1. Apple Intelligence is not the trigger by itself SystemLanguageModel.default.availability reports .available on the healthy device we reproduced point 1 on, so simply having Apple Intelligence enabled does not cause the failure. We cannot rule out that ANE load or memory pressure plays a role. Correction to my original post I wrote that other device models in our fleet running the same build and iOS version are unaffected. I cannot support that. Our logs only carried UIDevice.model ("iPhone") at the time, so no model information was available. We have since added the exact model identifier, and every device we can identify is an iPhone 16e (iPhone17,5) — including the ones that work. We have no data on other models either way. Revised questions Are the non-ANE weights for mrcdetector expected to be absent? If so, should setComputeDevice be considered unsupported for VNDetectBarcodesRequest, and is there any other supported way to run it off the Neural Engine? Given that, is there any in-app recovery from the ANE load failure at all, or is rebooting the device genuinely the only remedy? For the intermittent failure, what should a Feedback Assistant report contain to be actionable? We can catch a device in the state, but not on demand — is a sysdiagnose taken before rebooting the right thing?

Thank you very much. This solves my problem.