SOLVED but this needs to be addressed by engineers - both the actual issue and the incorrect auto-generated App Review response that led us on a wild chase. I reproduced the install failure on a physical iOS device through TestFlight, and the real blocking error is not UIRequiredDeviceCapabilities. The device installation log shows MIInstallerErrorDomain Code 152 with AppexBundleContainsClassOrStoryboard, because the [APPNAME]DeviceActivityReport.appex for com.apple.deviceactivityui.report-extension contains NSExtensionMainStoryboard or NSExtensionPrincipalClass, which iOS says is not allowed for that extension point. This seems to be a known issue reproducible on iOS 18 and 26. This creates a validation conflict: removing NSExtensionPrincipalClass makes App Store Connect reject the upload with “Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found,” but including it causes the install to fail on device. In other words, there is no plist configuration that satisfies both validators for this extension type. So the rejection appears to be misclassified. The app is actually blocked by an extension plist validation issue in the Device Activity report extension, not by UIRequiredDeviceCapabilities. I found my solution here: https://origin-devforums.apple.com/forums/thread/809227 The key fix was using an ExtensionKit extension embedded in the Extensions folder with an explicit dstPath = "$(EXTENSIONS_FOLDER_PATH)", rather than the default PlugIns setup. Once I switched to that configuration and removed NSExtension* from the extension plist, the app both passed App Store Connect validation and installed successfully on device. Resubmitting to App Review and hopefully they accept this go around.🤞🏽

I'm facing the exact same rejection and tried a few of those solution attempts you listed. No luck - It's very frustrating. Waiting to get a call from the App Review Board in a few days.

Experiencing the same issue, any update?

Experiencing the same issue - any update?

Adding some more context to this as I'm determining how best to set up my CloudKit zones: Option A (Current) - 1 zone per Root parent collection Option B - 1 zone per collection With Option A, I’d need to handle cross-zone migration whenever a SavedItem moves between Collections, or when a Collection’s parent changes (since that effectively moves an entire sub-tree of data into a new/different zone). With Option B, where each Collection has its own zone, I’d only need to worry about migrating SavedItems and Extracts when they move between Collections - parent/child changes between Collections themselves would just update references. Trade-off becomes: Option A → Simpler sharing (since sharing a single Collection would automatically include all its subcollections), but I’d need zone-migration logic for all object types — Collections, SavedItems, and Extracts. Option B → I’d still need zone-migration logic for SavedItems and Extracts, but not for Collections. However, sharing a Collection that has subcollections would require creating multiple CKShares.