“testflight the requested app is not avaliable”

I’m not the right person to address that. I don’t have any in-depth experience with HID stuff. Sorry, that would be me and I apologize for having missed your post until now. (thanks to Quinn for giving me a heads up!) Questions reordered for clarity: At what stage is it enforced: activation, personality matching, provider attach, or before Start()? First off, as general background, I have a forum post here that has an overview of the IOKit->DEXT loading flow. In any case, entitlement validation is implemented as a secondary stage of the IOKit passive match process, with each family handling the details of entitlement validation. For reference, this is how the PCI Family does these checks. Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface? I haven't actually looked at the HID families implementation in detail so it's possible there are other requirements, but, yes, at a minimum the built-in entitlement is re

Hello richardbe, Thanks very much for your detailed investigation into the crash. Can you please copy your findings into a bug report on Feedback Assistant? Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Afterwards, please post the FB number to this thread. Bug Reporting: How and Why? has tips on creating your bug report. Also, it would be very helpful to our engineers if you can attach the JSON-formatted .ips crash report to the bug report by following the instructions in Posting a Crash Report and Acquiring crash reports and diagnostic logs. Thank you for reporting, Richard Yeh  Developer Technical Support

Thank you for your post. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us.

If your app has been rejected and you need help resolving the issue, consider taking advantage of one of the following support options available from App Review: Reply to the message from App Review in App Store Connect and request clarification. Request a call with an Apple representative to discuss the outcome of the review. Submit an appeal to the App Review Board if you believe your app follows the App Review Guidelines. Visit the Contact Us page on Apple Developer and select the App Review tile to learn more.

Thank you for your post. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us.

Thank you for your post. There are several factors that may contribute to an app not following App Review Guideline 4.1. Visit Preventing Copycat and Impersonation Rejections to learn best practices that will help you submit original apps that follow this guideline.

I am having a similar issue. Its been more than 14 hours and still In Progress. First time i am trying notarization and already feel exhausted. No clear logs or status updates. It would be nice if we know its in queue or waiting manual review etc.

This is still happening in the debug console, app not crashing. Wonder if this is something I can ignore? A fix is documented elsewhere? Not fixed? The Apple sample app SwiftDataFlashCardSample prints the same log messages than my app I just started to implement. On macOS Tahoe 26.4 (25E246), Xcode Version 26.4 (17E192).

The issue isn't just with CKSyncEngine. I have a custom CloudKit-based syncing setup, which uses CKRecordZoneSubscription to listen and respond to changes in a zone, and the remote notifications aren't working with that either. I filed FB22380044 ... hopefully this can be patched up with a quick update, as it would break so many apps

Thanks for bringing this to the forums. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] Any improvements or new tools available since the 2022 DTS post? [/quote] I’m glad you asked (-: Recently the App Store Connect folks updated their documentation to describe a technique for transferring app groups between teams. See App Store Connect Help > Transfer an app > Overview of app transfer > Apps using App Groups [1]. Given that, it’s now possible to use an existing technique — using an app group ID as a keychain access group — to preserve keychain access across an app transfer. I’ve just updated App ID Prefix Change and Keychain Access to describe this approach. Now, this is all very ‘bleeding edge’, and thus it’s possible that you might run into snags. However, it’s certainly an option worth exploring. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] We just finishe

I reported this in Feedback Assistant, no reply so far.