“We are unable to process your request”

Thanks for your reply. I only know how the API works based on the documentation, I’m not in IT and I do not know the limitations on your server side. Because the upload is handed off to a system daemon to be performed out-of-process, the API is currently designed around a fire-and-forget model for a single HTTP request per resource. It assumes the destination endpoint can ingest the entire payload in one go. But for your description this is not correct? I would suggest to open a conversation with the IT department for that server and if not changes can be done, I would recommend to another approach. If backend changes are entirely off the table, sticking with your custom NSURLSession implementation is the right call. Albert Pascual
  Worldwide Developer Relations.

Is there any update on this? I've had an achromatopsia vision augmentation solution waiting since day 1 release and I'm still waiting. Would very much like to deploy it someday. Also, if there is a place to request this feature, I'd very much like to know where that would be.

Unfortunately as the issue is still being investigated, we do not have the answers you seek. We suspect the issue may have started with iOS 26. The root cause is not determined yet, but we believe there is a specific trigger for this issue to surface - that is, it does not effect all apps that get deleted and re-installed every time, all the time. All that will be part of the investigating and fixing process.

(I say “in theory” because LibZip seems to be doing something smarter somehow; even if you overwrite the text file at the same position—at the first entry—saves are still a lot faster than they would be writing the entire 500MB out again.) So, one factor here is just write caching. The more specifically, the write() syscall is returning as soon as data reaches the UBC (Universal Buffer Cache), which is the shared read/write cache for the entire system. This ensures that subsequent reads() return the just written data, even if the read originates from different file descriptors or processes. However, when the data will actually reach the disk is basically undefined, which is why fsync and F_FULLFSYNC exist. What makes copies slow isn't the writes; it's the reads, since the data still has to be pulled off the disk so it can be sent back to write. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

If your test app and main app share the same Bundle ID, granting permission in the test app automatically grants it in the main app. Furthermore, once an app is authorized, the system will never show the prompt again, which is why your main app is always reporting as authorized. Before you can request access, your main app must have the privacy string in its Info.plist. If you call the authorization code without this, your app will crash. I would check on your workflow. Since your app is currently stuck in the .authorized state, calling requestAuthorization will just instantly return .authorized without showing the UI. To test the prompt, you need to revoke the permission. When you install that app into a new device do you have that issue? Albert Pascual
  Worldwide Developer Relations.

Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions time expires. No, but the primary causes are user cancellation and failure to report progress. Theoretically, resource pressure could cause it; however, in practice, I think the system typically ends up killing your app instead[1]. Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? There isn't any specific time limit. I've never worked out what the absolute maximum (defined by the progress reporting requirement) is, but that limit would be high enough that it's not really a constraint. Q3. A way to distinguish the reason is needed. User stop and system expiration require completely different handling. Currently, this is impossible. Yes, this is definitely an issue with the API. Please file an enhancement request asking for this, then post the bug number back here. [1] The issue here is similar to (one of…) the reason why memo

Very strangely on the test app I was requested to allow the usage of the music repository and now even the main app allows to use the music repository. I wonder how may I request the same thing on the main app, especially given I'am always reported as authorized.

Hello @Bikrrr I see your report just landed in our system. This is interesting, thank you for reporting. 🧐 Updates will be provided in Feedback Assistant, we are unable to discuss if a fix has been found on the Forums. Have you found a workaround for this you'd be willing to share here that I can show to the engineering team investigating this issue?  Travis

And this is the full error display: Error acquiring assertion: [u 31CF99CC-85C8-4FDF-9567-8ED0FF31C74F:m (null)] [com.apple.Music.MediaPicker(3.1)] could not acquire startup assertion Plugin , instance = [(null)], state = 3, useCount = 0> must have pid! Extension request will fail Failed to acquire assertion for plugin: , instance = [(null)], state = 3, useCount = 0> pid: 0 Unable to acquire process assertion in beginUsing: with plugin identifier: com.apple.Music.MediaPicker, killing plugin begin extension request Request PK UUID: CB10114C-0A82-4781-9B26-17A754A333B8 with item count 0 complete with error: Error Domain=PlugInKit Code=4 could not acquire startup assertion UserInfo={NSLocalizedDescription=could not acquire startup assertion} PlugInKit error in beginUsing: with plugin identifier: com.apple.Music.MediaPicker, killing plugin *** Assertion failure in -[MPMediaPickerController_Appex requestRemoteViewController], MPMediaPickerController.m:523 *** Te