“xcode simulator is not listed in visual studio.”

OK, I saw the difference. But we still can not know the user action type from this method. func provider(_ provider: CXProvider, perform action: CXEndCallAction) There is no option like actionType to know it is triggered by the CallKit screen / Hardware / unknown. Then we can know the details. Why do you want to know this? What are you trying to do? We don't provide this kind of detail because applications shouldn't be changing their behavior based on the how the user ended the call. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thank you for the detailed guidance. After performing a full reset on all devices as you suggested, the OTA process completed successfully through the TestNet backend. Good! There isn't a good way to know for sure, but I suspect the HomePod was hanging on to an expired profile which then confused the rest of the system. I appreciate your help in resolving this! You're very welcome. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Let me start by saying two slightly contradictory things: It's very likely that there is an APFS bug here, so if you haven't already, please file a bug on this and post the bug number back here. It's ALSO very likely that your ES client (possibly both ES clients) are required to actually experience this bug, and you should address it as well. Next, I think I want to be clear that some of what I'm saying is a bit of an educated guess. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. That doesn't invalidate what I'm describing above, but I do think it's important to have some awareness of the limitation of the data at hand and that, most importantly, new data could totally change our understanding of the overall state of things. Getting into the details: But here, I don't see such things. When EndpointSecurityEventManager is on the spindump, it's only because they

All apps should build with the latest SDK, so you have access to the latest APIs, regardless of the distribution mechanism used. Regarding the UIDesignRequiresCompatibility questions, it's useful to see how this was described in the WWDC25 Platforms State of the Union: As you evaluate your app's UI and the time you need to adopt the new design, we're providing an option to continue to use your app's current design with Xcode 26. We intend this option to be removed in the next major release. Hopefully you're on your way with the adoption of the new design already, or have upcoming plans to tackle it. You'll have to look at your own specific situations and determine how long you can continue using it for specific hot fix situations against the above statements and the timing of your own planned adoption of the new design. What are the potential issues if a team continues development on Xcode 16 while others have migrated to Xcode 26? For example, could there be compatibility, build, o

Thank you for your post. The App Store team does not monitor the forums, and I believe you set your app as “Made for Kids” for the first time when you deployed the app. Since your app is already live, the “Made for Kids” flag and the “Kids” category are often locked to prevent developers from changing an app’s target audience without parental consent. This will be a significant privacy issue as you can see. To resolve a locked metadata field like that, you need to contact App Store Connect Support, not App Review. Visit the Apple Developer Contact Us page. The representative can file an internal ticket directly to the App Store Connect engineering team to manually unstick the metadata field on your account if appropriate. Now, depending on your app and the people affected by that change, the engineering team will decide whether to make that change. I’m not in that team now I know their process. Once App Store Connect Support unlocks the field and you successfully uncheck “Made for K

Hi, @Dominik_2 I'm a little late here but I'm having the same issue. Did you ever figure this out? I can't even get a 2019 Mac Pro to properly activate LOM and a 2023 Mac mini which gives me the same Address Already In Use error. Here's all my testing and info. Apple are you there??? Infrastructure: • Mac mini 2023 (M2, 10Gb Ethernet, MacMini.local, macOS 15.x Sequoia 15.7.4) — MicroMDM v1.13.1 • Mac Pro 2019 (MacPro7,1, Intel T2, MacPro.local, macOS 15.x Sequoia 15.7.5, T2 firmware 23P3120) • Both supervised via Automated Device Enrollment (DEP) through Apple Business Manager • Both enrolled: IsSupervised = 1, APNs working on both • Both are Controllers and Clients LOM Current State: Mac mini (Apple Silicon M2): • LOM profile installed ✓ • lom0 interface active ✓ • Port 55555 listening on * ✓ • LOMDeviceServerColsolidated path (Apple Silicon) ✓ • com.apple.AppleLOM.XPC active=1 ✓ • com.apple.AppleLOM.Watchdog active=1 ✓ • Mac Pro CAN reach mini's lom0 port 55555 — TCP connection established ✓ • BUT connectio

Xcode should never crash, so filing bug reports through Feedback Assistant are encouraged.