“We are unable to process your request”

Thanks for the response, for context it was around 15 submissions over a few months and 30ish messages. I get your example, but I think my situation’s a bit different. The updates weren’t just micro changes trying to slip something through, there was a mix of both small tweaks and broader changes. The issue was the feedback stayed very generic (“overtly sexual”) without pointing to specific elements, so each update was essentially a best guess at what might be triggering it. Especially early on, when only metadata was flagged, I assumed the issue was relatively minor. By the end, I actually went in the opposite direction of evasion & submitted a build with everything unlocked and included screenshots showing all content upfront, so review had full visibility, as requested during a phone call. It’s possible I missed a couple of screenshots in earlier messages, but nothing was intentional. That’s why the 3.2(f) decision caught me off guard, there was no intent to hide or mislead, just trying to int

I’ve also spent some time investigating this. While monitor mode works, setting the channel using CoreWLAN’s [CWInterface setWLANChannel:error:] API does not behave as expected. As a result, capturing isn’t reliable for third-party apps on Macs with the Apple N1 Wi-Fi chip or the MacBook Neo. I've identified and submitted two issues: FB22295165: [CWInterface setWLANChannel:error:] does not work on a disassociated interface, even though the documentation indicates it should, and it behaves correctly on older Macs. FB22295685: Once in monitor mode, [CWInterface setWLANChannel:error:] reports a successful channel change and the interface reflects the requested channel, but capturing continues on a different channel (usually the channel the interface was operating on previously to being placed in monitor mode). There also appears to be a race condition between entering monitor mode and macOS attempting to rejoin a network shortly after calling [CWInterface disassociate]. While I can’t confirm this defini

Currently experiencing the exact same issue (ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING), with no response from Apple Developer Support. All agreements are signed, no account changes, etc. Currently unable to test any apps and have been for the last few weeks.

Sorry, it was a TSI, not a bug report. I replied to the DTS email yesterday with the full spin dump. Ahh, I see it now. So, the first thing I actually did was search for /usr/lib/libEndpointSecurity.dylib (the library link path), which is a convenient way to find all ES clients. What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. That's a critical factor here because it means that there are now two independent entities with veto power over each other's activities, particularly activity that's coming from helper components (not just the direct ES client). That leads to here: There are only 2 other threads in the logs that appear relevant, both from our helper process and both down in APFS. One of them is also stuck inside decmpfs_read_compressed: That's the deadlock. More specifically, looking at your thread's stack when you enter decmpfs_read_compressed, the first thing it does is call decmpfs_lock_compressed_data: (1) *940 decmpfs_read_compressed + 30

Could you please authorize the following new Bundle ID for the same Family Controls (Distribution) entitlement?New Extension ID: com.hayashikento.FocusPact.FocusPActMonitorParent App ID: com.hayashikento.FocusPact Did you submit a new request for the com.hayashikento.FocusPact.FocusPActMonitor bundle ID?

Thanks for the post, interesting that's something in the process. TN3168: Making your App Clip available in the App Store | Apple Developer Documentation https://developer.apple.com/forums/thread/804858 There is something I always like to check when deploying AASA files. When the full app is installed, iOS handles the URL invocation locally via your apple-app-site-association (AASA) file and entitlements, bypassing the need to query Apple's App Clip CDN. The fact that this works proves your code, AASA file, and associated domains are configured correctly. The failure for fresh devices is happening because Apple's CDN has not yet been updated with your App Clip's metadata? Can you provide me a link to your AASA file in your server so we can see why is not syncing into the Apple servers? Is your server preventing or blocking IP address or user agents from requesting the AASA file? Sometimes, the job queue in App Store Connect simply drops the task. You can often force it to re-queue by making

a long review process with many resubmissions The word 'many' doesn't convey the exact number to others. Can repeated resubmissions / iterative changes alone be interpreted as “evasion” under 3.2(f)? It depends on what you have done, and nobody but people from Apple, Inc. knows it. You have been told that you have some questionable, overly sexual content. Suppose that that you have covered a sexually-revealing person with a see-through material. You've been warned 5 times. And each time you increase its opacity from 10% to 11%, 12%, 13%... If you do it many times without entirely getting rid of this person, I would definitely flag it for evasion.

@gavers Be assured we are paying attention. Unfortunately we're unable to share any updates on specific reports on the forums. However on your individual FB numbers you will receive a notification when a fix is available on a release for you to verify. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

Chiming in to say three things: The Oauth token expiration happens to me as well. I can't find an exact pattern, but it seems to happen when I leave Xcode idle for a while. I'll go have lunch, come back, and suddenly I have to sign out and sign back in to Claude Agent. The AI seems to lose itself a lot. It'll begin responding to a prompt, I'll see output in the chat, but then it'll hang at Thinking... for a couple minutes. Suddenly, it'll pick up again and it always starts with: I should resume... or I'll resume..., as if the original session got interrupted. My internet connection is rock-solid; that is NOT the issue. This happens very frequently and it's pretty annoying because it adds minutes of overhead to what should be very quick, easy requests. Unlike Xcode 26.3, version 26.4 now puts much of the AI's thinking into chat bubbles that cut off the text and are not expandable. This is very dumb. I WANT to see what the AI is thinking. Xcode 26.4's UI is actively harmful and in the way. The only bub

It is a mixture of a number of things. After calling contentHandler, the notification starts getting processed, and as far as you are concerned the NSE is done. If there is no memory pressure, and the extension is known to run frequently, the system may not terminate the process, but reuse it by leaving it in memory, and just give it execution time the next time it needs to run. So, the process could stay alive after contentHandler, but it is not guaranteed. It could be terminated right after, or it could be left in memory for one notification, but could end up being terminated after another one. The URLSession task continues to run, because the NSE process is not the one running it, but the system handles the network requests. The request may complete after calling contentHandler, but by the time it does there may be no process to return the results to. So, it is not entirely safe to rely on this assumption, but you could fire-and-forget, as long

Well I figured it out - for anyone still encountering this issue: My company has one domain to service multiple locations/storefronts. Each location has it's own separate Payment Processing account, requiring a unique Apple Pay Payment Processing Certificate/MerchantID. The docs and responses here made me think subdomains would be required, which is a headache in itself - especially since the Apple Pay Session must be started from that subdomain (not the parent domain). SOLUTION: If you register multiple MerchantIds within a single Apple Developer Identifier - all Domain Association Files tied to a certain domain are the same. So if you verify for one MerchantID, then add that same domain to another - it will count it as already verified. No need for subdomains. No need for swapping out Domain Association files. Really wish that Apple had made that clear.