“We are unable to process your request”

[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

@App Review The issue is NOT resolved for all developers. I have two apps stuck in Waiting for Review with zero communication: OKIRIZO (Apple ID: 6757417197) - First submitted Jan 10, 2026. Current submission Feb 25. Over 2 months waiting. TidaKitchen (Apple ID: 6759185372) - Submitted ~Mar 11. Still waiting. I have filed THREE support cases with no response: Case 102824913561 (Feb 19) - no reply Follow-up (Mar 4) - no reply Case 102846444484 (Mar 17) - no reply Expedited review request also submitted with no response. Three support cases over one month, all ignored. This is unacceptable for paying Apple Developer Program members. Please investigate immediately.

I am experiencing the same issue with two of my apps. OKIRIZO (Apple ID: 6757417197) - First submitted January 10, 2026. Current submission from February 25, now waiting 23+ days. I have contacted Apple Developer Support on February 19 (case 102824913561), followed up on March 4, and again on March 17 (case 102846444484). No response to any of these inquiries. I have also submitted an expedited review request with no response. TidaKitchen (Apple ID: 6759185372) - Submitted approximately March 11, also stuck in Waiting for Review. Both are v1.0 initial submissions. No messages, no rejections, no feedback in App Store Connect. Three support cases filed over the past month with zero replies. This is severely impacting our business operations in Okinawa, Japan. Could the App Review team please investigate?

You are only required to create an account once you reach $30k in revenue. You can always voluntarily register, which you would need to do in this case. The problem here is that Apple is the retailer and Apple handles all of the tax collection and remission to CRA. Apple wants to have its CRA account tied to your CRA account because of the commissions that Apple charges you. If you have further questions, I recommend contacting CRA directly. They're usually very helpful. Unfortunately, this kind of business arrangement is actually very unusual as businesses go. But Apple is large enough so that CRA will understand the business from your perspective and should be able to provide assistance. Unfortunately, the entire process of connecting your CRA account with Apple can take a long time. And since Apple is a US company, there are also IRS forms you'll have to fill out. All of these forms can take some time to fill out - think months, not days.

Thanks for pointing me to the code-level support channel. I’ve submitted a request there including my Team ID and full context of the issue. While this isn’t a traditional code bug, I described it as an entitlement inconsistency across app extensions to help with investigation. I'm honestly pleading this is resolved as soon as possible cause this is really affecting us badly. Appreciate the guidance.

A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers If you haven't already, please file a bug asking for the dev-only entitlements to be enabled on free developer accounts, and post the bug number back here. I can't promise it will happen, but it's an interesting idea that I don't think we've really considered. Published approval criteria and timelines so projects can plan accordingly Unfortunately, publishing truly formal criteria is much more difficult than it sounds since, in practice, it's very difficult to come up with a criteria set that EXACTLY covers every reasonable use case while also excluding every possible unreasonable use case... and that assumes we could even come up with every use case. However, on this point: Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. We understand that the nature of real-w