“file uri scheme”

It is caused by code coverage being injected by test plan that is autogenerated in scheme. Disabling code coverage for driver target and deleting test scheme will fix the problem. However, you might want to have testing with your project. But it looks like any test plan inside same project will inject profile-instr-generate. Not sure how to have testing for main app, and no code coverage flag injected for driver. Seems like bug in Xcode.

Hi @Ziqiao Chen and everyone, Thank you @simonfromhelix for reviving this thread. @Ziqiao Chen — I tested the frontmost app state approach as you suggested. Sharing the full results here in case they're useful. == Test Setup == Disabled HKWorkoutSession entirely (no workout session started) Used only HKAnchoredObjectQuery for heart rate sampling Set Return to Clock → PowerNap (per-app Custom) → After 1 Hour Ran the app, then lowered my wrist to simulate a real nap scenario == Results == With Xcode debugger attached: HR sampling worked great (~5 second intervals), continuous and stable This initially gave me hope! Without Xcode debugger (real-world scenario): The app was terminated by the system within ~10 minutes, even with Return to Clock set to 1 hour for this specific app After lowering my wrist, the screen turned off and the app was suspended/killed shortly after Zero heart rate samples were collected The Xcode debugger appears to elevate the app's priority, masking the real behavior Digital Crown: Pressi

Thanks a lot for confirming that this is currently investigated! Can you say when this will be addressed? I have reported this horrible regression in iOS 26 beta 1 in June 2025. It’s kinda sad that this didn’t seem to have any priority for Apple to get addressed before the public version was released. In 3 months this bug report will be one year old. [quote='874099022, DTS Engineer, /thread/809410?answerId=874099022#874099022'] This is a known issue that is currently being investigated. If you have already filed a bug report for this issue, thank you. [/quote]

Hello. I can help you update the stream link and publish a new version as long as you have the original Xcode project files.

Hello, thanks you for your response, and noted. Yes, I did explain. My frustration is that the App is designed specifically for iPhone devices, and I thought I had selected the correct settings in Xcode, by removing all options other than iPhone. However, the reviewer tested the app on iPad, in compatibility mode, and as such, there was a display issue. I have now made the relevant telemetry adjustment to the info.plist file, in the hope that it can't be confused and used on an iPad in compatibility mode. My frustration has been that the expectations from what I have read suggest 24-48 hour review time, and my app is so simple, (1 page, 4 actions), no connectivity or database etc required. Thank you for your response though, it's all a bit new to me. Fingers crossed!

I advise that you find a way to move on with your life. Don't let them play their game. Or you will get sick mentally and enter a long period of depression. No matter how harsh your words are, they are not going to listen, and they will ignore you. I left the entire Apple ecosystem after almost going crazy 16 years ago. Back then, an average wait time was 17 to 19 days. And I had about two dozen software updates and new software submissions waiting. It was frustrating when I had a software title, whose name contained the word 'Rip' and they rejected it by saying 'Illegal file sharing.'

Dear CRI_Omachi, While I am not aware of any changes made to IOBufferDuration in iOS 26, this seems like an issue that merits further investigation. Can you please open a bug report via Feedback Assistant? With it, please attach any documentation of this issue, such as logs, footage, or a focused sample project demonstrating this phenomenon. 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? Let me know if you'd like to know more, Richard Yeh  Developer Technical Support

So, let me start here: Should I avoid 'cloning' directories in general with the copyfile function? No, quite the opposite. If you read the copyfile man page closely, you'll find that it's very careful to NEVER say that it clones directories. It either refers to cloning individual files or recursive cloning. Recursive cloning means using COPYFILE_CLONE on directories and is actually the standard behavior across all of our copy APIs (and the Finder). More specifically, COPYFILE_CLONE means that copy file calls clonefile for every possible individual file object and creates new objects for directories or anywhere it can't use clonefile. Note that this process is more sophisticated than it might seem, as it doesn't just use cloning within the same file system, but actually preserves clones across volumes (which is much trickier). copyfile() can also do standard copy all data copies on APFS but, to be honest, I've never come up with any good reason why you would do so, as it's b

How does Numbers.app detect that a document has been moved to Recently Deleted? Can third-party apps implement the same behavior? In my reply on the other thread, I said this: I haven't looked at it in detail, but I suspect it's using a combination of security-scoped bookmark (for basic file tracking on the device) and the iCloud Document API. In particular, the key NSMetadataQueryUpdateRemovedItemsKey should be included in the NSMetadataQueryDidUpdateNotification you receive for deleted files. Have you tested this? As I'm fairly sure that's what Numbers is doing. One follow-up comment on this point from your other thread: Result: The file disappears from Files App Recently Deleted. In contrast, using [NSFileManager replaceItemAtURL:withItemAtURL:] keeps the file visible in Recently Deleted. Is this difference designed behavior? In the context of iCloud, delete/move and replaceItemAtURL are fundamentally different operations. In the first case, you deleted an exist