“Popping Sound”

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

This is a well-known problem. It actually doesn't (directly) involve your app at all. The operating system will do this with any document when you've configured the document to be opened with an app that doesn't explicitly declare support for it. Since you have declared support for this file type, the most likely explanation is that you haven't declared that support correctly. Document types are specifically for the NSDocument architecture. I don't know anything about your app so I don't know if that usage is appropriate or not. But it sounds like you just need to add some imported type identifiers for those types.

[quote='854085022, DTS Engineer, /thread/797007?answerId=854085022#854085022'] Keep in mind that appex-based VPN isn’t well aligned with macOS’s execution model. macOS supports multiple users simultaneously, which is a concern because VPN configurations affect the networking stack as a whole. [/quote] So how does that explain network app extensions in App Store apps? What is there to stop a user logged in on the same system (possibly a standard user) from accessing a VPN tunnel started by another higher privileged user via a Mac App Store app with a network app extension and gaining unauthorized access to resources via that tunnel? I would think most people assume App Store apps to be running in a far more restricted environment than apps distributed outside the App Store, but in the case of app extensions the opposite appears to be the case. By forcing Developer ID apps to use system extensions it forces admin privileges in order to install the extension and the explicit granting of Privacy and Security perm

Sorry I mised your earlier response. 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. This suggests that while UDP packets reach the device, delivery to the process is suspended in background, which explains why the DTLS handshake cannot progress. Indeed. This is pretty fundamental to how iOS works. If your app moves to the background, iOS suspends it. It then can’t do anything until it gets resumed. It’ll be resumed when your app moves to the foreground. It can also be resumed in the background under specific criteria. However, traffic on a UDP socket is not one of those criteria. I talk more about this in iOS Background Execution Limits. Traditionally, VoIP apps use two different techniques for these two scenarios: For ring indication, they use one of the technologies that Kevin described above (VoIP push or Local push connectivity). For the actual conversation, they prevent the app from suspending by virtue of their active audio

The Xcode team is here! Thanks for reporting this, I'm seeing the lost prompt as well when starting a new conversation. The crash sounds quite unfortunate and is not something I've seen. A bug report would be great, especially if you have reproducible steps or a screen recording. Even the crash report would be very informative. Thank you for reporting!

Hello, I would like to get more information. What error do you see when you try and log into https://account.apple.com or https://business.apple.com When it states the account is locked, steps to be taken are listed in the same pop-up.  Travis Trotto - DTS Engineer

I am testing my iOS app on iOS 18. I performed 50 tests, and in 43–44 of them, the app successfully detects beacons, relaunches in the background, and continues BLE communication. Testing how? What are the details of the process you're actually using to test this? That is, are you: Artificial Testing” -> Laying the phone on a desk next to the beacon and toggling the beacon (or shielding the phone) on/off to simulate entry and exit. VS. Real World Testing” -> Carrying the phone around in your pocket and seeing what happens. Beyond that, what are the broader parameters of the test itself? How far is the device from the beacon? How long is the device exposed to the beacon? What's the broader use case you're trying to implement? Most importantly, what, if anything, do you know about EXACTLY what was happening when the failure occurred? I want to understand why beacon triggers are inconsistent in iOS. What are the common reasons behind iOS not relaunching the app for beacon events, and what factors affect re

[quote='815753021, AkshayKalucha, /thread/815753, /profile/AkshayKalucha'] We are currently observing NEVPNConfigurationChangeNotification [/quote] That is the canonical way to do this. [quote='815753021, AkshayKalucha, /thread/815753, /profile/AkshayKalucha'] it appears to have inconsistent behavior when … VPN configurations are installed programmatically via MDM systems [/quote] What do you mean by “inconsistent”? Your steps to reproduce indicate that this fails every time, which seems pretty consistent to me (-: Are you saying that this is inconsistent with the documented behaviour? Or are you seeing the problem intermittently? Either way, this sounds like a bug to me and I encourage you to file it as such. Make sure to include a sysdiagnose log taken shortly after reproducing the problem and, for bonus points, enable additional logging per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. Please post your bug number, just for the record. On the workaround

If there is any known reason for this behavior or any recommended workaround, we would greatly appreciate your guidance. Additionally, if this is a known issue that was addressed in iOS 26.3, we would appreciate any information you can provide regarding that as well. I haven't found the specific bug, but yes, this sounds like a bug was introduced in 26.2 and then fixed in 26.3. There are complicated entanglements between the call management system and the media center, so I can see a few different ways something like this could happen. Did you file your own bug on this and, if so, what was the bug number? Does your app activate its own audio session? That's the only way I can see your app actively triggering something like this. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

SO, let me start with the immediate answer here: Is there any supported way to ensure notification sounds consistently route through connected Bluetooth/external speakers? Basically, no. Your app has no direct control over how notification audio is routed. Our app sends push notifications with a custom sound file using the sound parameter in the APNs payload. What's the nature of the audio you're trying to send? In particular, if this is communication of some kind, then you might want to consider using the PushToTalk framework, which would give you much more control over exactly how audio is played. Is this routing behavior expected for push notification sounds? The word expected is a tricky one here, as it's clearly not the system goal to have the notification route audio in a weird way. I've provided a bit more background on why this happens below, but here is how I'd describe the state of things: The expected behavior is that, ignoring

I had the same issue. I managed to workaround this by enabling background audio in the app's capability settings. See also: https://developer.apple.com/forums/thread/799104