“We are unable to process your request”

We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Can you file a bug on this and upload the full spindump there? That's the easiest way to transfer large data files and I may eventually want a sysdiagnose. Having said that... Our agent uses Endpoint Security Framework to monitor events, and provide anti-tamper functionality for installed components and processes. While several EndpointSecurity calls appear in the spindump stack traces, we don't have any evidence that any calls from revisiond were blocked. ...this is almost CERTAINLY caused by your ES client. What we'd really like to to understand what that lock is (appears to be decompressing an object on an APFS volume), what revisiond and APFS are doing with it, and what might cause it to deadlock. Y

The place to request this feature is with the Feedback Assistant app. They do listen, even though they're not great at responding.

I`m facing the same issue right now. Did you solve? I signed the terms on https://developer.apple.com/contact/request/alternative-eu-terms-addendum/ but still now working

Thank you Quinn! Here's the direct download link to the installer package: https://github.com/Nakanokappei/window-resize/releases/download/v2.0/Window.Resize.pkg This is a Developer ID Installer–signed and notarized .pkg built with productbuild --sign. The .zip distribution of the same app passes Gatekeeper without issue. For reference, here's what I see: # Signature is valid pkgutil --check-signature Window Resize.pkg # → signed by Developer ID Installer certificate # Notarization succeeded xcrun stapler validate Window Resize.pkg # → The validate action worked! # But spctl rejects it spctl -a --type install Window Resize.pkg # → rejected # syspolicyd log shows # meetsDeveloperIDLegacyAllowedPolicy = 0 The productbuild --sign does emit Warning: unable to build chain to self-signed root but security verify-cert confirms the cert chain is valid. Happy to file a bug with the .pkg attached if that's easier for you.

[quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] I need to support both use case (exec and dylib). [/quote] OK. [quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] [Library validation] does not apply in my scenario since the library is provided by a third party [/quote] I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case? The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here? Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library valida

We're experiencing a similar issue with our app (Apple ID: 6754461151) and wanted to share our situation in case others are facing the same. Our app has been stuck in Waiting for Review twice in a row now: Version 1.0.2: Submitted February 7, 2026. After 24 days with zero movement, we were forced to withdraw it. Version 1.0.3: Submitted March 3, 2026. Now at 17 days with no progress. In total, we've been waiting 41 days across two submissions with no feedback, no rejection, no communication from Apple. Steps we've already taken: Submitted an Expedited Review Request 7 days ago - no response Contacted App Review Status support Verified our App Review Information is complete, including demo credentials and invite code Confirmed all agreements and banking details are up to date

[quote='819454021, oleksandr91, /thread/819454, /profile/oleksandr91'] Is this a known macOS bug? [/quote] I’m pretty sure I’ve seen this before. IIRC the problem was reported by a third-party developer and I found it super hard to reproduce, and thus I’m not sure if a bug got filed. Sorry to be vague about the details; I searched my records but was unable to track down the conversation. Anyway, it sounds like you can easily reproduce this. Given that, I think it make sense for you to file your own bug about it. 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

It looks like you’re trying to report a bug. If so, the way to do that is via Feedback Assistant. See my Bug Reporting: How and Why? for a lot more info about that process. Please post your bug number, just for the record. FWIW, I’m seeing the same issue with Swift Playground 4.7 on my Mac, so this is not iPad specific. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='819553021, robonaren, /thread/819553, /profile/robonaren'] my understanding is that root daemons typically don’t run sandboxed [/quote] Correct. While it is possible to enable the App Sandbox on a daemon, folks don’t normally do that. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The plugin only connects to the legitimate daemon [/quote] The canonical way to do that is by setting the privileged flag. I have a link to an explanation of that in XPC Resources. You could also validate the peer’s signature. Again, I have a link to info about that in XPC Resources IMPORTANT This works in this direction because you control the daemon’s main executable. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The daemon only accepts connections from trusted clients [/quote] There isn’t a good way to achieve this goal, presuming that this set of trusted clients includes an authorisation plug-in. The issue is that authorisation plug-ins are in-memory plug-ins, so you don’t control

Are you really supplying an empty Apple Account string? Or did you just redact that for the sake of this post? Regardless, I have a couple of generic bits of advice here: To get started, use the store-credentials subcommand. It runs you through the authentication process interactively, which can help head off the most obvious errors. Make sure you’re using an app-specific password, rather than the password for your Apple Account. An app-specific password should have the format aaaa-aaaa-aaaa-aaaa, where each a is a lowercase letter. If you get stuck, switch to authenticating with an API key. IME it’s often easier to get that working. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com