“file uri scheme”

No, at least from the Apple perspective. As I mentioned above, the sticking point is reproducing the problem. If you have a way to reproduce the problem reliably, I encourage you to file a bug with that info. And also post your bug number here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='820543021, mhenke, /thread/820543, /profile/mhenke'] I filed an issue in the Feedback Assistant [/quote] What was that bug number? Oh, and do you hit this when you choose Validate App in the Xcode organiser? Or only after you’ve uploaded to App Store Connect? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='820585021, faisalIkwal, /thread/820585, /profile/faisalIkwal'] We don't apply rules in these methods [/quote] So what do you do in those methods? In many cases a transparent proxy can get away without implementing those methods at all. If you do implement them: Make sure they return promptly. In the case of the sleep(…) method: Implement the async version and have it return promptly. Implement the completion handler version and have it call the completion handler promptly. [quote='820585021, faisalIkwal, /thread/820585, /profile/faisalIkwal'] com.apple.developer.endpoint-security.client is not present in .entitlement file. [/quote] Network Extension and Endpoint Security are separate subsystems. It’s fine to implement an NE sysex without any ES bits in it. In fact, it’s more than fine, it’s very common. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, Thank you for the suggestions. I have tested the communication using the EADemo sample app as suggested, but unfortunately, I had no luck. The app is unable to establish a stable session with the accessory, which mirrors the issues we are seeing with our own application. To move this forward, I have filed an official bug report via Feedback Assistant and attached a full sysdiagnose captured during a failed communication attempt: Feedback ID: FB22116486 Current Project Status: Certification: The accessory is currently in an early development state, so we have not opted for MFi certification yet. We are using development identifiers/chips for testing the iAP2 protocol. Prior Success: We have not yet been able to successfully maintain a functional data session between the ExternalAccessory framework and this specific hardware revision. Technical Observations from Firmware Logs: Based on our local logs, the hardware side appears to be performing correctly: Link Synchronization: The iAP2 link complete

Hi Kevin, I have tested it on macOS 26.4. Bug no longer reproduces with my test samples. Thank you for the fix! Regarding fclonefileat API my expectations are actually met in macOS 26.4 now - I do expect that Kernel is capable of rejecting invalid calls of clonefile API and does fail the operation. It is tricky to predict the future as there might be new regular file type that might not be clonable/will become clonable so I always delegate the file clonability decision to Kernel. My userland code is to handle the errors gracefully, although fallback in case of rsrc needs to be reconsidered... It is on my side though, I do not see any further enhancements needed in Kernel currently. For backwards compatibility, I will include explicit careful checks for resource forks and paths with ..namedfork/ as you have suggested. I appreciate your help!

I have the same issue and filed a bug report already: FB22324179 Since updating to iOS 26.4, iCloud remote notifications (CloudKit push notifications) are no longer delivered. The same setup worked reliably on iOS 26.3 without any changes to the app or server configuration, so this a new regression from Apple. didReceiveRemoteNotification: in AppDelegate gets not called anymore.

I've been working with CoreML extensively across macOS 26.x betas and can confirm this regression. After investigating with MPS shader profiling, it appears to be a stride alignment issue in the MLMultiArray backing store when the compute unit dispatches to GPU/ANE. Workarounds I've found: Force CPU-only as temporary fix: let config = MLModelConfiguration() config.computeUnits = .cpuOnly If you need GPU performance, pin to CPU+GPU (excludes ANE): config.computeUnits = .cpuAndGPU In my testing, the corruption is most severe on the ANE path. CPU+GPU gives ~70% of the full .all performance without the scrambled outputs. I'd encourage everyone affected to file duplicate Feedbacks referencing the stride/alignment hypothesis to help Apple prioritize.

I've been working with the new Swift Vision API's RecognizeTextRequest on iOS 18 and hit this exact deadlock. After profiling with Instruments, I found that the Vision framework internally uses a limited thread pool for its neural engine requests — on most devices this caps at 2 concurrent ANE inference sessions. The workaround I'm using is a semaphore-based concurrency limiter that queues requests: actor OCRPipeline { private let maxConcurrent = 2 private var running = 0 private var pending: [CheckedContinuation] = [] func recognizeText(in image: CGImage) async throws -> [String] { await acquireSlot() defer { Task { await releaseSlot() } } let request = RecognizeTextRequest() let handler = ImageRequestHandler(image) let observations = try await handler.perform(request) return observations.compactMap { $0.topCandidates(1).first?.string } } } This keeps throughput high while never exceeding the 2-concurrent-request limit. In my testing across iPhone 15 Pro and iPad Air M2, this processes ~40 images per seco

Thanks Albert, we'll file the bug report. One more ask: we have a live event tonight with printed QR codes and we're seeing very inconsistent behavior across fresh devices. Some devices load the App Clip perfectly via the Safari Smart App Banner fallback, while others show App Clip not available. Same URL, same network, all fresh devices that have never had our app installed. Is there anything else we can try on our end to improve reliability tonight? Any headers, cache settings, or meta tag adjustments that might help the Safari fallback path work more consistently? Or is the inconsistency entirely on the ASC publishing side? We're running out of ideas and have fans arriving soon. I'm attaching the QR code and the result when it fails. Thanks!

@fanarchy Thank you for the post. It appears that the file is syncing to the servers without any issues. This is excellent news, and I appreciate you providing additional information regarding the problem. Your discovery of removing the “/next-game” from the AASA file, which causes it to fall back to Safari, is brilliant. This effectively isolates the issue, but still we have the issue in the App Store App Clip publishing. Safari Smart App Banners do not rely on the App Store Connect Advanced Experience database. When Safari loads your page, it reads the tag and cross-references your AASA file locally. Because your AASA and meta tags are perfect, this works flawlessly. In any case I see the issue is in the configuration on the App Store and you should file a bug for them to take a look at the process with your App Clip. The issue here is the status of the App Clip should eventually become published. Once you open the bug report, please post the FB number here for my referen

Hitting the same issue. Filed FB22336025

I filed feedback FB22335783, Regression: reduced editor tab density in Xcode 26.