“We are unable to process your request”

The issue was the feedback stayed very generic (“overtly sexual”) without pointing to specific elements They only tell you how you violate review guidelines. They won't tell you how you should make changes so that you will pass the review process. It's been like that for the past 15 years or longer. We only pay $99 annually. So it shouldn't be a surprise. If you need to find out how you should make changes, I'm afraid you need to hire a consultant.

Dear DTS Engineer, Thank you for your reply. Yes, I have already submitted a new request form for the DeviceActivityMonitorExtension today. Please note that the correct Bundle ID is com.hayashikento.FocusPact.FocusPActMonitor . Since my parent app (com.hayashikento.FocusPact) has already been approved for the Family Controls entitlement, I would appreciate it if you could link this new extension ID to my existing approval so I can proceed with Distribution/TestFlight testing. Thank you for your assistance. Best regards, Kent Hayashi

Hey @drewolbrich, After looking into FBFB21873482, both myself and another engineer were not able to reproduce this. Can you try this again on visionOS 26.4? Additionally, if you are able to reproduce this, can you updated your Feedback Request with the sample code you are using, a video of the user flow that causes the issue, and a sysdiagnose captured after the error occurs? Instructions on capturing a visionOS Sysdiagnose can be found on the Profiles and Logs webpage. Thanks! Michael

@fanarchy Thank you for the post. It appears that the file is syncing to the servers without any issues. This is excellent news, and I appreciate you providing additional information regarding the problem. Your discovery of removing the “/next-game” from the AASA file, which causes it to fall back to Safari, is brilliant. This effectively isolates the issue, but still we have the issue in the App Store App Clip publishing. Safari Smart App Banners do not rely on the App Store Connect Advanced Experience database. When Safari loads your page, it reads the tag and cross-references your AASA file locally. Because your AASA and meta tags are perfect, this works flawlessly. In any case I see the issue is in the configuration on the App Store and you should file a bug for them to take a look at the process with your App Clip. The issue here is the status of the App Clip should eventually become published. Once you open the bug report, please post the FB number here for my reference. If you have any questio

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.