“show when run”

Same here. There was no response from the created appeal and it does not show in the app review

I'm using SSH into the host itself to try to use virtualization tools to run macOS VMs. OK. So lemme see if I understand this correctly: You have a host Mac. And a VM product that you can run as a command-line tool. You’ve configured that product to run a Mac guest. You SSH into that Mac to run your command-line tool. You’re testing two configurations. In the first, the host is configured to autologin to the GUI. In that case you’re able to consistently start the VM. In the second case… Actually, I’m not sure about this. Is the second case, do you: Manually log in to the host GUI, and then SSH in and run your test? Or not log in to the GUI at all, and then SSH in and run your test? ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='884502022, iceboy, /thread/822626?answerId=884502022#884502022, /profile/iceboy'] If I do not set kSecAttrAccount right now, is it possible that I cannot read the keychain items correctly? [/quote] It’s hard to answer this because you’ve phrased it as a negative question. So, lemme rephrase it: If I’m using the data protection keychain (the default on iOS, something you have to opt in to on macOS), And I create a generic password keychain item without specifying kSecAttrAccount, Will I be able to access that item’s contents using SecItemCopyMatching? The answer to that is “Yes.” At the end of this post I’ve included some code that I used to test this. (Sorry it’s in Swift. I built this by cobbling together various existing bits of code that were all written in Swift, and I don’t have time today to convert them to Objective-C.) Having said that, my advice is that, when you creating a generic password item you always populate both kSecAttrService and kSecAttrAccount. If you don’t have a sensible value t

@App Review My app (id 1611398578) is also stuck In Review for a week now after being approved. In App Store Connect -> App Review all the submissions show as Approved. I also got the email and notification that the submissions were approved a week ago (iOS and macOS). I contacted Apple Support and have two open case IDs (102865508515 and 102865870578). I was told the issue has been expedited but there are still no updates or replies from Apple at all and I am stuck and helpless. Any help would be greatly appreciated!

Hello, I’ve resolved the issue—I had overlooked a crucial step. In the Build Phases section, I hadn’t added “Embed Foundation Extensions” to the Run Script. Once I did that, the problem was solved.

SO, let me start by sorting out a few specific details: delegate is called via applicationWillTerminate which will then again almost immediately end in the app receiving a SIGKILL. applicationWillTerminate is not part of the normal delegate lifecycle. It's a relatively late “add-on that was recycled[1] to give apps SOME opportunity to save work if/when the user for quit them, so it's ONLY called if the app happens to be a wake at the point it's terminated by the user. Most critically, you cannot do ANY work after receiving it. That's because: Your app will call exit() immediately after returning from it. If you block “too long, then the system will kill you anyway. In practice, that means it needs to be handled as a separate edge case as you don't really have a lot of time or flexibility to do significant work. This is not your app being closed in the normal sense, it's actually your app being force-quit by the user. With that out of the way, the important case is actually applicationDidEnterBackground, so le

Thank you for providing such a detailed account of the iCloud Drive file upload deadlock issue on macOS 26.4.1. It sounds like you've done extensive troubleshooting and analysis to identify the root cause. Here's a summary of what you've discovered and some additional thoughts or suggestions that might help refine your approach or assist others experiencing similar issues: Summary of Findings: Root Cause: A stale HTTP/3 (QUIC) session in nsurlsessiond's BackgroundConnectionPool leads to a deadlock during file uploads. Behavior: Deadlock occurs specifically with HTTP/3, while HTTP/1.1 works without issues post-restart. Affects larger files (>100 KB); smaller files may occasionally succeed. Restarting both cloudd and nsurlsessiond resolves the issue temporarily by clearing the poisoned session. Reproduction: Consistent behavior observed across multiple tests with varied file sizes. Diagnosis: Log analysis can help identify occurrences using specific grep patterns. Recovery: A targeted kill command for user-l

Your screenshot seems to show that the keyboard window was disabled, which may happen when your app has multiple windows (UIWindow) with a higher window level (windowLevel). You can do a quick check if that is your case. Other than that, as my colleague mentioned, it will be very helpful if you can provide a minimal project that demonstrates the issue. Best, —— Ziqiao Chen  Worldwide Developer Relations.