“We are unable to process your request”

Hi @siddakumar, More information is needed to investigate this issue. Please carefully review the resources in the post below: Gathering Required Information for Troubleshooting Apple Pay on the Web Merchant Issues https://developer.apple.com/forums/thread/762994 If, after reviewing the TNs, you are unable to resolve your payment failures, please follow the steps in the post above to create a report via Feedback Assistant. Once submitted, please reply here with your Feedback ID so I may investigate your device logs, and escalate to the Apple Pay Server engineers directly, if needed. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Man, there is so much history here... I tried setting the creation date to: 1946-02-14 08:34:56 +0000 right after creating the folder. But it doesn't have the desired effect. Maybe I didn't convert the date correctly? SO, I had a bit of loose time today, so I threw together this test code: // // main.m // create_time_check // // Created by Kevin Elliott on 3/16/26. // #import int main(int argc, const char * argv[]) { @autoreleasepool { NSURL* url = [NSURL fileURLWithPath: @/Volumes/HomeBase/MassiveTestBed/MassiveTestDirOut/TestDir]; NSDate* date = NULL; NSError* err = NULL; if([url getResourceValue: &date forKey: NSURLCreationDateKey error: &err]) { NSLog(@%@, date.debugDescription); } // Jan 24, 1984, the day the mac was announced... const CFAbsoluteTime kAbsoluteTimeMagicBusyCreationDate = -534528000.0; NSDate* magicDate = (NSDate*) CFBridgingRelease(CFDateCreate(kCFAllocatorDefault, kAbsoluteTimeMagicBusyCreationDate)); NSLog(@File is Busy: %d, [magicDate isEqualToDate: date]); NSURL* targetURL =

Is your project available somewhere where we could look at it with the right link? If it's not in a public place, but you're willing to share it with us privately, please open a code-level support request and we can send you instructions on how to share a copy with us to take a look. — Ed Ford,  DTS Engineer

Same here. Over 5 weeks now. @Tomato , I can't see why calling would fuel delays. That'd be extremely unethical. The reason we are calling is because we don't have any other means of getting answers. We are completely left in the dark in a process that's core to our businesses

Hi @DTS Engineer , I am also facing this weird issue I am consistently encountering a build warning in Xcode 26 that prevents proper symbolication of crash logs. The warning states: warning: (arm64) /Users/mickey/Library/Developer/Xcode/DerivedData/CalendarSync-bjuvwxojzofqzzcmzzpdozbujrge/Build/Products/Debug-iphoneos/CalendarSync.app/CalendarSync empty dSYM file detected, dSYM was created with an executable with no debug info. Steps to Reproduce: Open the project in Xcode 26. Build the project for a physical iOS device (arm64) or Archive the project. The warning appears during the Generate dSYM phase of the build process. Troubleshooting Steps Already Taken (Issue Persists): Set 'Enable Debug Dylib Support' to No. Verified 'Debug Information Format' is set to 'DWARF with dSYM File'. Verified 'Generate Debug Symbols' is set to Yes. Set 'Strip Debug Symbols During Copy' and 'Strip Linked Product' to No. Performed 'Clean Build Folder' and manually deleted the DerivedData folder. The issue persists reg

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.