I'd like to see a step by step process for this. It all seems mismatched with reality. Icon Composer wants to export 2X. Xcode doesn't accept 2X. Icon Composer has things like "tinted dark" and "tinted light" but Xcode only has spots for "tinted". They should just have Xcode read the .icon file. I nuked my old AppIcon asset, but creating a new one in Xcode doesn't match up with what Icon Composer is doing.

Experiencing this as we speak... I actually have received the Your submission was accepted email twice now, but the app still says In Review on the ASC website. About 4 hours have passed so far.

Just pinging this thread that as reported above and in FB11746132, it is still impossible to submit Catalyst apps to the App Store that include this entitlement. The failure in that case is during upload of the build to the App Store from Xcode. However, in the intervening years since this issue began, I can now run apps from Xcode with this entitlement. So the remaining issue appears to be solely on the App Store submission side.

Unfortunately this is not just an Xcode problem. There are effectively 2 issues here. Xcode does not allow launching/development with the UADN entitlement on Ventura as per above posts. Ventura requires this entitlement to get the device name. Note that #2 is my assumption because it works on macOS 12 and returns "iPad" on Ventura 13.0.1. Which is the same behavior iOS uses without the entitlement. But since it is impossible to build with said entitlement, I can't be certain. What I do know is that there seems to be no way to get the device name on Ventura today. Which is why I filed the bug. My assumption is that the entitlement is therefore required on Ventura, but impossible to use.

This works for iOS. But building the same app for Catalyst fails to launch: LaunchServices launcher has returned an error, until you remove the entitlement manually. Note that Catalyst does require the entitlement, but won't let you build with it even if it is granted and part of your app identifier. For now I have to manually delete the entitlement from the entitlements file every time we build for Catalyst, and meanwhile the Catalyst app is hobbled without this functionality. I did already file this 2 weeks ago as FB11746132.

My steps are not quite the same, but have the same outcome. We have the entitlement, it works and has been deployed on iOS. Unlike the multicast entitlement, this one randomly is getting applied on Catalyst as well. So we tried to include it there but then we run into essentially this where the Profile has the entitlement but uploading to App Store Connect fails. But in our case the issue is Catalyst specific. Feels like the App Store filters incorrectly are blocking the entitlement on Catalyst even though it is in fact required there.

This is absurd. How is it "Live Activities" if you can't update it when your app is in background and it is not visible when your app is foreground. This is totally broken. We spent a ton of time on this only to find the feature doesn't really work! Only a joke app that sets a timer with no relation to a real activity would be possible with such an API.

Had this problem all Summer. Still in GM. CloudKit has been non-functional on Simulator all Summer on Xcode 14 including the RC of Xcode 14. Today in particular, CloudKit production has also been mostly down, but that's on normal devices.

It is safe to say the HomeKit API seems just as out of date after WWDC21 as it has been for 3+ years now. It is still missing TVs, HomePods, AppleTVs, Airplay2 devices, etc. There was really nothing announced that was actually HomeKit framework related. Home Keys looks like the team that does Wallet. HomeKit Secure Video expansion was just a matter of where and how much video is stored. Nothing related to HomeKit. The way I read the tea leaves since Apple didn't add anything to HomeKit again this year is this (this is not a real quote just how I interpret the broader direction): We have spent all of our resources for some years working on CHIP/Matter. We presume that by putting parts of HomeKit into this open source effort, more types and more brands of devices will then become part of it that were previously hesitant to do so. Therefore, we have spent years redirecting our efforts towards that at the expense of essentially everything else. This seems like a road that will take 3+ years (plus the 3+ years already spent) to come to fruition. Meanwhile, the HomeKit API will still be missing everything that has been announced for the last several years. It's also counter-intuitive as most of the missing devices are Apple devices so they never needed third-party or open source anything to fix that. Regardless, I think that's what we're getting. At this point, anyone serious about the HomeKit area starting fresh is likely better off using an HAP implementation of their own and basically ignoring the HomeKit API.

I am also seeing this. I'm going to experiment with turning on recognitionRequest.requiresOnDeviceRecognition as it has nothing to do with those network services, so presumably removes these limits.

Think I'm closer to a solution here. I had to convert 8 different libraries we use from .a files into xcframeworks last Summer to support all the many archs. It is my theory that these unsigned xcframeworks are causing the problem, and available literature on xcframework is.... limited. So one issue is that the codesign tool and the various Xcode logs do not identify any issue there. Instead, they say "MyKit.framework" isn't signed rather than "libmystuff.xcframework" inside "MyKit.framework" isn't signed. Switching the xcframeworks to "Embed and Sign" elicits the hoped for error that identifies the specific xcframework that it wants to sign but for some inexplicable reason does not sign. ../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A: code object is not signed at all In subcomponent: ../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A/Frameworks/libmystuff.a However, I would have thought --deep would at least have glossed over that problem and I did try setting that to no avail earlier. As to how I get these frameworks signed in a static way (we don't rebuild these regularly, they are just part of our repository). I guess I need to go find a command line to sign them somehow before adding them to the project? Something doesn't seem right here. Seems like codesign needs a flag to say "yes, I know this object is not signed, so sign it".