“file uri scheme”

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.

[quote='818622021, mobiusmoonglade, /thread/818622, /profile/mobiusmoonglade'] Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? [/quote] No. Our direction in this space is the ManagedApp framework. It’s super cool. For a short intro, watch WWDC 2025 Session 203 Get to know the ManagedApp Framework. However, it won’t work for you because it’s not available on the Mac. Also note that its focus is on apps and app extensions, so it’s not clear how it would work for a launchd daemon. If you’d like to see ManagedApp support your use case, I recommend that you file an enhancement request describing your requirements. And if you do that, please post your bug number, just for the record. Beyond that, the only option that I’m aware for provisioning a daemon is via the super obscure mechanism [1]. However, that’s really meant for configuration settings rather than credentials. You could obviously jam a credential into it, but that has significant drawbac

Right. That’s the Swift compiler crashing, which is something it should never do. I recommend that you file a bug about it. And as this is specific to Apple technologies, you’ll have to use Feedback Assistant rather than the Swift open source bug process. 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