“Popping Sound”

iOS 15 is the minimum supported device for debugging. It sounds like you found at least one of the places where this is documented, the Xcode Support page, in addition to the Xcode 26 Release Notes. For anything older than iOS 15 where you found that you can still connect the debugger to your app with Xcode 26, please consider that a happy convenience for yourself at this time, but you also should not rely on it, and instead look at moving yourself up to the documented minimum supported configurations. — Ed Ford,  DTS Engineer

I can’t really help you with MDM stuff. If you need help in that space, you can try over in Business & Education > Device Management but you might have more luck over in the Apple Support Community, run by Apple Support, and specifically in the Business and Education topic areas. However, I can help you with this: [quote='877476022, Leo_Nagano, /thread/815340?answerId=877476022#877476022, /profile/Leo_Nagano'] on that MDM‑managed macOS 14.4 (Apple Silicon) device the app still cannot be launched. [/quote] That sounds less like an MDM issue and more like a Gatekeeper issue. [quote='877476022, Leo_Nagano, /thread/815340?answerId=877476022#877476022, /profile/Leo_Nagano'] codesign -dvv confirms the app is signed with our Developer ID Application certificate and has … [/quote] I see no mention of the App ID (com.apple.application-identifier) and Team ID (com.apple.developer.team-identifier) entitlements. Any app that uses restricted entitlement should be signed with those entitlements because they

It sounds like you're encountering a known issue related to how iOS handles captive portals, particularly when websites are only accessible via IPv4. Apple has been aware of certain behaviors where iOS might prioritize IPv6 over IPv4, leading to incomplete captive portal experiences if the necessary IPv4 infrastructure isn't present. Here are a few points and potential workarounds you might consider: Understanding the Behavior: iOS is designed to prefer IPv6 when both are available because it's generally faster and more efficient. However, this can cause issues on networks that only support IPv4 for certain services, like captive portal pages. iOS and iPadOS Versions: Apple has made various improvements to captive portal handling across different iOS versions. While I don't have specific details on version 36.2, issues related to IPv6 preference have been addressed in updates prior to and possibly after this version. Ensuring your devices are running the latest compatible version of iOS/iPadOS is alw

This error code indicates that audio/video codecs used in your LL-HLS streams are not compatible with the the Apple platform that is tested with. Make sure that you validate the variant codec strings that are specified in HLS MVP.

Its redirecting to my own thread Oh gosh, sorry. I juggle a lot of threads and sometimes I lose track of the context )-: the pop-up does not specify if the playground will be run on an iPad simulator or an iOS simulator Indeed. I’ve always just assumed it would be an iPad simulator because that’s equivalent to what you get when you run an app with the Swift Playground app on iPad. However, you’re correct that the submission form doesn’t say that explicitly. My general advice here is that you strive to make your app work well on both iOS and iPadOS. That is, after all, what we expect of ‘real’ apps. If you can’t do that then my only immediate suggestion is to use the Comments box to note this. However, I’m also going to do a little digging to see if I can clarify our policy here. 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

It sounds like you’re trying to create an App Store Connect API key. When you do that, you get one shot at downloading the key itself, but the Issuer ID and Key ID are visible on App Store Connect indefinitely. An Issuer ID is a UUID, for example, c055ca8c-e5a8-4836-b61d-aa5794eeb3f4. A Key ID is a 10-character identifier, for example, T9GPZ92M7K. For more info on how to create these keys, see Creating API Keys for App Store Connect API. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Has anyone found another approach I'm missing? I'm not aware of any API that would (directly) get you the information you're looking for. The information itself is only directly needed within the Thread network itself, so there hasn't really been any reason to expose it (assuming the device has it at all). I'm not sure how likely this is to change, but if you haven't already, I would encourage you to file a bug on this and then post the bug number back here. Having said that, there might be an alternative approach, because this: HMAccessory already exposes matterNodeID as a cross-protocol identifier. ...was NOT added to simply be a cross-protocol identifier. The real reason it was added was to allow developers to send Matter commands through our ecosystem pairing, using the flow I described in this forum post. I haven't tried this particular cluster: Matter cluster 0x0035 (Thread Network Diagnostics) appears to have exactly what I need: RLOC16, NeighborTable with isChild boolean, RouteTable. ...but, in theory

I have a BLE device which my app connects to and can detect button presses. On a button press, I want my app to start recording using the AudioRecordingIntent. But my app doesn't work and throws a background error. Is there any reliable way I can get the app to start recording audio in the background? No, at least not within the general audio API. There's a privacy block in place that prevents recording sessions from activating in the background. Our voice communication APIs (CallKit, LiveCommunicationKit, and the PushToTalk framework) do allow this, but that's done as part of the system’s larger call management architecture and is not something that's possible outside of those APIs. If you’re working on some kind of communication app, then you can certainly use one of those framework, but they can’t be used for any other purpose. I also wanted to check if my app can trigger audio recording from the background if my Bluetooth device supports and is active on HFP mode. No, this doesn

We are experiencing the same issue. No new functionality for the chat was added. Should we just update the policy or add additional permission asking pop up?

[quote='876864022, SwiftieDog, /thread/797007?answerId=876864022#876864022, /profile/SwiftieDog'] I know this may sound like a why question [/quote] Two points: If you think that Mac users need more warnings than they already get — keeping in mind the one presented when the app saves a VPN configuration — you are welcome to file a bug about that. If you think that Apple should document this policy officially, you can file an enhancement request against the documentation. A good place for this sort of stuff is the Apple Platform Security guide. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com