Never use the comments. They hide your replies. The whole reason for the encryption is my app keeps personal info for the user and I wanted to give them secure protection. Nothing to do with National Security. You're exporting software from the USA with unknown encryption capabilities. The US government considers that a national security issue. Apple has a number of APIs for secure data storage. However, collection of personal information for a user may put your app under a higher level of scrutiny. Don't be surprised if you still have a very long wait ahead of you.

I provided all the requested information and replied at 1:41 AM on the same day, only 23 minutes later. Your response time has no bearing on wait times. What makes this even more frustrating is the difference in developer experience. Developer experience is irrelevant. People want to publish on Apple platforms because that's where the money is. I paid $25 for Google Play...With Apple, I’m paying $99 per year Both are trivially small amounts. Most professional fees are many times higher. Even Apple's fees were once much higher, before Google existed. Could someone from Apple please help me understand what is happening with my review While waiting for someone from Apple to respond, I recommend reading some of the many identical posts here in the forums. The deluge of AI slop has forced Apple to rely on AI itself. This has led to some developers, especially new ones, waiting weeks to months.

Nobody knows anything about your app, or how it's configured in App Store Connect. What you're describing is a setting that would require uploading additional documents to Apple. I've seen a couple of people recently say they did that and now they're waiting a very long time for approval. The only reason I can imagine for someone picking the "upload documents" option would be if their employer required it and they're able to sit back and wait a few months while still getting paid. If you aren't getting paid while waiting for that human review, I recommend you reconsider those encryption choices.

I could reproduce this, but only by following your procedure exactly. I first had to install the command line tools. That worked fine and the build worked fine. It was only after deleting the directory and then using xcode-select --install that it failed. I don't have an answer for you. File a feedback report. Personally, I avoid both the latest version and the previous version of Apple software whenever possible. My production machine is Sequoia and will remain so until Apple forces me to change.

The SDK is tied to the version of Xcode. It's not related to the host OS version except in terms of whether or not Xcode runs on that host OS version. I assume the Command Line tools are similar, but that's a funky environment. It would be better to post a reproducible example code that generates the error.

Apple’s guidance indicates that this type of review normally takes about 2 business days. All Apple Developer support e-mail blurbs say 2 business days. Means nothing. Do you have any advice? Never do anything that takes you out of an automated flow. There is no guarantee that any task requiring human intervention will be correctly resolved in any timeframe. Even simple, mundane issues take weeks. You're talking about something involving national security. I can't give you an answer regarding a request that's already in progress. I can definitively say that if your app requires encryption documentation then you need to change your app. Then it should be a (relatively) straightforward question of cancelling the old submission and doing a new one that only requires the reporting.

Don't use the comments. They hide your replies. But the certificate name isn't mine to choose: Apple takes it from the account holder's legal name, which I had to verify with my ID. So there's no way around my real name, umlaut included. That's unfortunate. If you remember where you saw the similar post, a link would be great. It's hard to be sure. I found this one after a quick search. There is a link in that one to a similar, earlier question. These questions were regarding Notarization on macOS. It's possible that old bug got promoted in Xcode 27. Was this working before Xcode 27? If this works in an older version of Xcode, then you can just use that instead. You'll be on the clock though. Apple will eventually require a newer Xcode for submissions. And Apple's pretty aggressive about that. Xcode 27 will likely be required by April. It sounds like this is only an issue for Xcode Cloud. Perhaps that explains why no one has experienced it yet. I don't know the details of how Xcode versions and Xcode Cloud are released. Perhaps this bug is entirely on the Cloud side. But even so, it's worth testing with and older Xcode. Maybe Apple has some older servers for compatibility. Hopefully it will be fixed eventually.

Is this a known issue with cloud-managed signing and non-ASCII certificate names? Yes. I'm pretty sure I've seen a very similar post here in the forums before. Is there a supported way to have Xcode Cloud sign without hitting it in the meantime? Supported? That's a real can-o-worms. And I use that phrase on purpose. Apple is a California company. And California is in the USA. And pretty much the rest of the tech industry is too. Americans don't do diacritics. Americans do English, and that's it. If you feel the need or desire to use something other than English, the responsibility is on you to properly manage it. All of your code and anything that interacts with the operating system should be strictly ASCII. A-Z, 0-9, and that's it. Spaces are a risk. Even changing case still introduces some risk. Apple is one of the most "foreigner-friendly" platforms. So they have a wide range of supported APIs for localization into foreign languages. These APIs all do the exact same thing. They take text written in some sequence of acceptable ASCII as described above, and display it with whatever diacritics or font-supported Unicode glyph you hopefully have installed. (And Apple installs a whole lot of 'em.) You are, of course, welcome to file feedback on this bug. Apple will get to work on it "real soon now". (Please don't take offence at my use of Americanisms or terms like "foreigner". I'm doing that on purpose. I spent my first, formative years in the USA, so I know how Americans think. It's certainly possible that localization engineers working on Apple developer tools may fix this bug in a few months. But then it's equally possible that some other engineer will break it again 3 weeks later because he hates dealing with those "garbage characters".)

Don't use comments to reply. They hide your replies. that doesn't apply to my case. This is my first-time submission, not a repeated rejection. There is not a separate expedited review queue just for your app. It's shared by all apps. So your first time submission is sitting under a mountain of dating, astrology, and gambling apps that have been repeatedly rejected.

It seems the entire "Expedited Review" queue is completely frozen right now. Yes, of course. I haven't seen a single "My app rejected for the 5th time" post that didn't resort to an expedited review. So that means the expedited review queue is full of problematic apps that take longer to review.

From all the similar 5.6 cases you've seen, have you seen any that were eventually resolved? The only similarity is the "Developer code of conduct" violation. I'm sure each individual situation is unique. But unfortunately, I don't recall any post regarding this guideline where there was a positive followup. I've seen many cases of individual apps being rejected on other grounds, where I thought the rejection was legitimate, but they ultimately followed up saying the app was approved. Because if Apple can reject a legitimate business No one is claiming your business isn't legitimate. Apple's a private company. They don't have to do business with anyone they don't want to, for whatever reason. Apple can, and will, reject apps without any stated violation of any guideline. provide no clear explanation of what triggered it, and then leave the appeal unanswered for weeks Unfortunately, that's typical. Again, Apple has no obligation to explain why they don't want to do business. I do this myself sometimes. When I see someone that's going to be a real problem, I just issue a quick refund and I'm done with it. I never explain why. That would be a real mess. Just cut my losses and move on. I don't fault Apple for having a similar policy. Abandon the business because Apple won't approve the app or explain what needs to be fixed? I'm afraid you'll have to do that review on your own. Please don't post any more details here in the forum. That usually reveals personal details that shouldn't be disclosed in public. The "Developer code of conduct" is usually a developer account termination action. Yet you're talking about it in terms of a simple app rejection. And you've also only waited a month. Typically these issues take longer than that. You might want to try a "Meet with Apple" session and get some clarification regarding whether this is a simple app rejection or if your entire developer account is at risk. Obviously, if you have more app rejections, then your developer account would be at risk. In the guidelines, there is a remediation process for a 5.6 violation. But I'm absolutely certain it will take longer than a month, even if successful. And to clarify, the app itself is dead. Give that up. You need to be fighting for your developer account instead.

The app was rejected under Guideline 5.6. For those that haven't memorized those paragraph numbers, that's "Developer Code of Conduct". If this were a company based in the United States, would the same situation be considered acceptable, almost one month without a substantive response to an App Review dispute or appeal? There are many similar reports here in the forum. I don't see any indication of any focus on any particular country. In fact, I've seen a number of developers go to extra effort to setup a shell company in the US. It doesn't seem to help. If the answer is yes, then I would genuinely like to understand what is happening with our case, because almost a month without a substantive response does not appear consistent with Apple's published App Review communication timelines. Those guidelines specifically said, and you quoted, 90%. That means someone's got to be the 10%. What you're describing is very consistent with other similar reports about "Developer code of conduct" rejections. I want Apple to tell us clearly what the problem is, what evidence led to the rejection, and what we need to do to resolve it. I have not seen a single instance where someone in your situation reported that Apple provided this information.

Has anyone experienced a similar delay recently Yes. The forums have been inundated with identical complaints the past few months. particularly after submitting an expedited review request? Yes. Everyone submits expedited review requests now. how long did it take before the status changed to “In Review”? Typically the time is measured in weeks, not hours.

You might also consider a "Meet with Apple" session. The only other issue is ensuring that the app has enough functionality without Other App already installed in order to pass app review. But now we're getting into "random guy on the internet says" territory. It's better to ask App Review directly. From what I've seen and experienced, Apple takes a really dim view of interaction with Apple apps outside of heavily-marketed extension points. But there is much greater leeway for apps that interact with other 3rd party apps. I see many apps that are fundamentally based on some other app. So I don't see what other functionality they could possibly have. So I just don't know.

If the other application is installed, it recognizes the file and presents its own installation/consent flow. It's like I'm beating my head against a wall here. One thing I can definitely tell you is that App Review tries to see the world through an end user's perspective. They aren't software developers. Sometimes that frustrates developers who expect them to be able to instinctively know how to do something technical. I've been a professional software developer for longer than most other developers have been alive. And I have no idea what you're talking about. So if you can't explain it to me, you're dead in the water at App Review time. Does the fact that the receiving application treats the opened file as one of its own extensions make this materially different from your PowerPoint example? I'm still focused on certain technical aspects of the file that you're embedding into your app. There are two scenarios here: The user already has Other App installed. The user does whatever in your app and tries to open this embedded file. Doing so activates the other app. The user does not have Other App installed. The user does whatever in your app and tries to open this embedded file. Doing so presents a system dialog explaining that the file can't be opened and offers to search the Mac App Store. As far as I know, App Review will have no problem with #1 or #2. They definitely aren't going to have Other App installed, so they aren't even going to test #1. But if there is any #3 flow that I haven't described, then that would probably be rejected. And from the way you've described it, there is going to be a #3. But perhaps I'm misunderstanding. But remember that I'm not App Review. I'm happy to go back and forth with you here in the forums and answer in a few hours. App Review is on the clock. This kind of back and forth would take several weeks and could possibly lead to dire consequences. So regardless of what you do, you're going to have to have a better elevator pitch to explain to someone who really doesn't care why they should bother.