“file uri scheme”

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

Everything you've described sounds like you're on the right track. Great, thanks! Interesting. Are you primarily editing the contents of the zip file (so you end up modifying the data inside, but don't really change it's overall size or structure)? Cloning is a huge help if you can clone the contents and then modify but if your modifications end up changing the fundamental contents, then I wouldn't expect the difference to be nearly as large. At large scale, this eventually devolves to bytes moved. Yes, I believe editing a large zip file using LibZip can indeed still be slow on APFS. However, the nice thing is that if a user edits a text file in a (zip) project in our app, only the first save to those edits would have the potential to be slow. After that, until they switched to editing another text file in the project, saving subsequent edits even into a huge zip file would be fast on APFS. (A project created in our app can contain text but also research files

Things that give me hope: The response from Apple  above says the word 'both', which is different from other responses on other threads, so it's a human being answering, not a bot Received new developer agreement email from Apple  - something something China something something, so they're alive and well, they must know that we're having this issue The daily barrage of developers raising concerns on this forum about the delays The delay also seems to signify that it's humans reviewing apps, which I much prefer over any 100% automated review system I know a lot of us are waiting, me included, for the fruits of our labor and creativity to be unleashed into the world, and to hopefully earn some money from it. Hold on tight guys, I'm sure it will happen. I know some of us are actually losing money because of this delay. But since we have no other leverage, stay patient. I tell myself a month is nothing in the large scheme of things, right? Right?

Thank you for your replies. Unfortunately, this didn't help either. I developed an app with SwiftDate in a GroupContainer. The data model is stable, and all relationships are optional. The next step should be to switch to an iCloudContainer. Both computers are on the same network and have internet access and access to the developer account. I disabled and re-enabled automatic signing. No change. A comparison of the project.pbxproj files showed two new lines in the non-functional project: 913a913 CODE_SIGN_IDENTITY = Apple Development; 948a949 PROVISIONING_PROFILE_SPECIFIER = ; I manually deleted these two lines and restarted Xcode. There was no change in behavior; the same error occurred. I also manually downloaded the profile from the developer website and tried to sign it manually. But this deployment profile has the same error again: Entitlements: 8 included, 1 Missing What surprises me is that the working version on the MacBook lists 12 entitlements. The entitlements are identical on both systems

So I am running APFS. But ... Instead of the default case-insensitive, I set up the file system as APFS case-sensitive. Hmm ...

Thanks, That makes sense. I've gone ahead and filed the report; the feedback ID is FB22221658. I'll attach the sysdiagnose to the ticket as soon as it's ready.

[quote='879742022, rsfinn_halcyon, /thread/818568?answerId=879742022#879742022, /profile/rsfinn_halcyon'] I would enter the service name for the single listener under both keys in the Info.plist file. [/quote] That’s not going to help, and it could hurt: It’s not going to help because you can achieve the same effect by putting that name into either of the spots in your Info.plist. It could hurt because… well… it’ll be exercising code paths that are very likely to be untested. [quote='879742022, rsfinn_halcyon, /thread/818568?answerId=879742022#879742022, /profile/rsfinn_halcyon'] I'm seeing that refer to Mach service names and the like. [/quote] XPC is implemented on top of Mach messaging. In some contexts an XPC named endpoint name is synonymous with a Mach service name. For example, when you use XPC in a normal launchd daemon, you put your XPC endpoint name into the MachServices property. However, there are places, like XPC services, where using Mach messaging directly, rather than XPC, is not viab

Weird. On the machine with this problem, are you running your tests on a non-Apple file system? So, something like FAT32, rather than APFS or HFS Plus? That’s sometimes the cause of weird problems like this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

lingyun1998 wrote: I have submitted it for review repeatedly for more than 30 times. Submitting the same request over and over again isn’t going to help. In my previous post I suggested you read Q&A with the Mac notary service team, which says: If your app [requires additional analysis], rest assured that we’ve received your file and will complete the analysis, though it may take longer than usual. and: In addition, if you’ve made changes to your app while a prior upload has been delayed, it’s fine to upload a new build. So, it’s fine to submit a new build if you’ve made meaningful changes to your product, but submitting the same build multiple times is pointless. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for your reply. I have already filed a report through Feedback Assistant. Case-ID: 18609190 (Apple DTS incident) Feedback ID: 22081725 The issue was submitted on Feb 28, 2026, but so far there has been no update in Feedback Assistant. The problem is still reproducible in Xcode 26.3 with Release (-O) builds when targeting iOS 16/17/18. Could you please help check whether this Feedback has been routed to the appropriate Swift/Xcode engineering team, and whether there is any information about which future Xcode version might include a fix? Thank you very much for your help.