“We are unable to process your request”

Earlier I wrote: [quote='880097022, DTS Engineer, /thread/818192?answerId=880097022#880097022'] the … question is really about whether your app extension can call StoreKit [/quote] I’ve confirmed that we don’t support StoreKit in app extensions [1]. At this point I don’t see a good solution. You can certainly file an enhancement request explaining your use case and requesting that we support it, but that won’t help in the short term. Note If you do file an ER, 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 [1] Apparently there’s an exception for iMessage extensions, but that doesn’t help you.

There is no approval process for creating an NE packet tunnel provider [1]. Any paid developer can do that [2]. Why do you think that such an approval is necessary? If you’re using Xcode, you should be able to add the Network Extension capability to your app and appex, check the Packet Tunnel box, and let its automatic code signing handle the rest. But you’re the second person to ask a question like this recently [3], suggesting that something is misleading folks. I’d like to find that and fix it. ps Some NE providers have deployment restrictions. See TN3134 Network Extension provider deployment for the details. Also, don’t try to use a packet tunnel provider for something other than VPN. See TN3120 Expected use cases for Network Extension packet tunnel providers. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Other than approval to join the Apple Developer Program itself. [2] That wasn’t always the case. See Network Extension

It seems that you’ve already seen my standard spiel about this. I’ve included it below, for the sake of others that stumble across this thread but also so I can quote it. [quote='819061021, AppDevObb, /thread/819061, /profile/AppDevObb'] What is causing my requests to always require in-depth analysis … ? [/quote] I’m not sure I’d put it that way. Rather, it’s that the system is taking its time to “learn how to recognise” you submissions. [quote='819061021, AppDevObb, /thread/819061, /profile/AppDevObb'] is there anything I can do to prevent it? [/quote] We have some advice on that topic in the “Q&A with the notary service team” that I reference in my standard spiel. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise th

Some more hints and tips in this space: The easiest way to determine the actual calling conventions for a given function is to create a small project in Xcode that calls the function and then looking at the resulting assembly. The Product > Perform Action > Assemble command is super helpful in that case. But you can also run the program and choose Debug > Debug Workflow > Always Show Disassembly [1]. Apple documents its calling conventions in Xcode > Application binary interfaces. This is basically Arm’s Procedure Call Standard with a few tweaks. And one of this tweaks affects varags. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] It says something about me that I have a hot key for that (-:

Thanks for the reply. I’m currently working on threat modeling for my PSSO extension and trying to understand the different attack scenarios. For example, what if an attacker creates a separate SSO extension to generate a valid attestation, and then somehow replaces or injects a malformed payload from their own device into the registration request of another device, potentially updating the keys? In such cases, what protections does the attestation mechanism provide? Also, is it sufficient to send the attestation payload directly in the request body, or should I add an extra layer of security—such as wrapping the payload in a JWT and signing it using Secure Enclave–backed keys generated during registration—to ensure the payload hasn’t been tampered with? At the same time, I want to avoid overengineering the solution. I’m trying to determine whether these additional measures are necessary or just redundant.

Sorry for the typo earlier. To clarify: after connecting via Wi‑Fi Aware, we need to establish multiple additional NWConnection instances and send URLSession requests over the Wi‑Fi Aware network. However, we’re encountering a system Nexus assignment error when attempting to create NWConnections using the nan0 interface. Could you please demonstrate how to properly establish these extra NWConnections and send URLSession data through them?

@DTS Engineer When I enable and disable it, I do receive the startFilter and stopFilter messages, but I no longer receive the handleNewFlow message. As soon as I receive the stopFilter message, the network returns to normal. By the way, let loNetworkRules4 = NENetworkRule( remoteNetwork: NWHostEndpoint(hostname: 127.0.0.1, port: 0), remotePrefix: 0, localNetwork: NWHostEndpoint(hostname: 127.0.0.1, port: 0), localPrefix: 0, protocol: .any, direction: .any ) A rule like this has also caused complete network outages on many versions of the system. Speaking of which, I urgently need to find a solution. So, I have two requests: When this issue occurs, how can I collect system logs to help us pinpoint the specific problem (it could be a system issue or an issue with our extension)? Is there a way to quickly reset the network? You mentioned earlier that there is a process similar to launchd responsible for the entire lifecycle of the system extension. Can I kill this process to achieve a

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