“file uri scheme”

If you use Apple Development signing for your day-to-day development, you can set up a reasonable debugging workflow. I explain how I do this in Debugging a Network Extension Provider. This still requires you to deactivate and then reactivate your sysex every time you change your code. That’s necessary because activating a sysex copies it from your app to a protected location on the file system, so without reactivation you end up running your old code. Debugging a Network Extension Provider discusses two key techniques for reducing the hassle associated with this process, namely: Unit tests Well-considered logging Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882538022, AlexPan19920718, /thread/820969?answerId=882538022#882538022, /profile/AlexPan19920718'] FB: FB22384135 [/quote] Thanks for filing that. I took a look at Xcode 26.5b1 and it still seems to have the problem )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not aware of any known issue that matches these symptoms. As you’ve noted, iOS is expected to preserve app group containers across OS and app installs. This certainly works for most apps and most users, but that doesn’t preclude there being a bug that causes this problem for some users of some apps. To investigate this we need to see a sysdiagnose log taken immediately after the user notices the problem. That’s gonna be tricky to acquire given that this problem isn’t obviously reproducible. I have a bunch of background on this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Key to that process is the ability to quickly and reliably identify that the problem has occurred. If I were in your shoes I’d add specific code for that, code that’s not tied to UserDefaults or Core Data. Both of those are big, complex subsystems, which makes it hard to know whether you’re hitting a problem with that subsystem or something more fundamental. Rather, I recommend that you store this state in files

You haven’t asked a question here, so it’s not clear what your goal is with this forums thread. My best guess is that you’re aiming to report a bug in Rosetta. If that’s the case I recommend that you file that in Feedback Assistant. See Bug Reporting: How and Why? for lots of detailed advice on that topic. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I've hit a very similar issue with CoreML model loading hanging on the MLE5ProgramLibrary.lazyInitQueue after OS updates. A few things that helped me work around it: 1. Pre-compile to .mlmodelc instead of loading .mlpackage at runtime The AOT recompilation path (which is what's hanging) gets triggered when the on-device compiled cache is invalidated by the OS update. If you ship a pre-compiled .mlmodelc built with the matching Xcode/SDK version, it often skips recompilation entirely: // Compile once at build time or first launch let compiledURL = try MLModel.compileModel(at: mlpackageURL) // Then load from compiled let model = try MLModel(contentsOf: compiledURL, configuration: config) 2. Load on a background thread with a timeout Since the hang is on a serial dispatch queue and the C++ exception bypasses Swift error handling, wrapping the load in a Task with a timeout at least lets you fail gracefully instead of getting watchdog-killed: let loadTask = Task { try MLModel(contentsOf: modelURL, configuration: c

The background like: We have a VoIP app with more call features. Sometimes, we received some feedbacks about call ened. After checking the log file, it shows there are user actions (eg, from func provider(_ provider: CXProvider, perform action: CXEndCallAction)), But the user said no user actions. So we doubt if there is a system-level event or error that will end this call. Then the details of the end call reason would be very helpful for debugging.

Hi Ziqiao, Thank you for confirming the issue. I've filed a Feedback Report as suggested: FB22384792 I'm also experiencing this on Apple Watch Ultra 2 with the latest watchOS. My configuration matches the documentation exactly (WKBackgroundModes with underwater-depth, WKSupportsAutomaticDepthLaunch = true, shallow depth entitlement). I've referenced the original thread (https://developer.apple.com/forums/thread/773542) and feedback report FB16448625 in my submission. Would appreciate any updates from the watchOS team. This is blocking a key feature for our freediving app launch. Thanks, Alexis

I saw the same issue on my Apple Watch Ultra 2 + watchOS 11.3 (22S555), as mentioned here. I haven't yet tried with watchOS 26, but if you follow the documentation to add underwater-depth background mode in your Info.plist, and the issue is still there, I’d suggest that you file a feedback report – If you do so, please share your report ID here. Thanks. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks so much for the reports. Any of you have filed a bug? Have you try with the new Xcode 26.5 beta? Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Thanks Albert Pascual
  Worldwide Developer Relations.