Popping Sound

The tricky part here is that, once you start messing around with code running as root, there are multiple TCC databases to contend with, namely the one for your user account and the one for the system as a whole. That complicates matters. Thanks for the insight. I didn't know that! Out of curiosity: would a sudo tccutil reset All com.mycompany.myapp reset the permissions for the app for the root user? So, anyway, lemme clarify your actual setup. It sounds like you’re: Using an IOHIDManager to discover HID devices. That vends you various IOHIDDevice objects. You choose one and call IOHIDDeviceOpen on it. Is that right? I'm doing it a bit differently: Using IOServiceAddMatchingNotification() to look for IOKit services of IOHIDDevice class. Match the properties of the IOKit services/devices I receive in the callback with the properties in the callback. And if it fulfills my criteria, proceed to the next step. Use IORegistryEntryGetRegistryEntryID() to get the registry entry ID for the IOKit service of t

Ideally, we would like calls to be delivered even when the app is completely closed or after the device is restarted. As I understand it, this may require obtaining VoIP permissions; otherwise, calls may only work when the app is open or running in the background. That understanding is incorrect. Voip apps do NOT require special authorization in order to function. All any voip app require to functions is including the two UIBackgroundModes: voip-> This allows an app to receive voip pushes through PushKit and use CallKit to report and manage the call interface. audio-> This allows the app to use the audio system in the background. In Xcode, both of these are configured through the Background Modes capability section. That section labels them: Voice over IP -> voip Audio, AirPlay, and Picture in Picture -> audio CallKit has a sample app Speakerbox which fully demonstrates all of this. It works as a standalone calling app by looping audio (to fake call inp

@Engineer Thanks for reply. Some more crash info. On simulator (did not test on device at this stage). Here is crash report: Error occurs in #4 notifyMe IBAction @IBAction func notifyMe(_ sender: UIButton) { let center = UNUserNotificationCenter.current() center.delegate = self center.getNotificationSettings(completionHandler: { (settings) in if settings.authorizationStatus == .notDetermined { center.requestAuthorization(options: [.alert, .sound, .badge]) { (granted, error) in DispatchQueue.main.async { if !granted { // Alert user } } } } else if settings.authorizationStatus == .denied { DispatchQueue.main.async { // Alert user } } else if settings.authorizationStatus == .authorized { DispatchQueue.main.async { self.alarmButton.isHidden = self.duree <= 120 } } }) var alertStyle = UIAlertController.Style.alert let alertController = UIAlertController( title: NSLocalizedString(M'avertir, comment: ), message: NSLocalizedString(Attention, comment: ), preferredStyle: alertStyle) var title = NSLocalizedS

We’d like to confirm if there have been any recent changes in AVAudioSession, CallKit, or related media handling that could affect audio input behavior during long-running calls. The system is always changing, but I'm not aware of any specific change or issue which matches what you're describing. There is the issue (and workaround) described here, however, that wouldn't happen mid-call. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

This may be an interaction with Swift's new approachable concurrency feature, which wasn't in play during the development of the sample app. If approachable concurrency is enabled, then the application may not be processing and displaying results in parallel as expected. Instead, it may be doing both on the main actor, and therefore waiting for the entire audio file to finish processing before displaying any results. If so, you can resolve the issue by either turning off approachable concurrency, or by marking certain methods as @concurrent.

[quote='852554022, felixs, /thread/795686?answerId=852554022#852554022, /profile/felixs'] I wasn't able to use VMs for testing here as I couldn't find a way to make a HID device connected to the host owned by the guest. [/quote] Ah, yeah, that’s a pain. Virtualization framework doesn’t support USB device access, so any VM app based on that is similarly limited. [quote='852554022, felixs, /thread/795686?answerId=852554022#852554022, /profile/felixs'] I also tried resetting TCC for my app [/quote] The tricky part here is that, once you start messing around with code running as root, there are multiple TCC databases to contend with, namely the one for your user account and the one for the system as a whole. That complicates matters. So, anyway, lemme clarify your actual setup. It sounds like you’re: Using an IOHIDManager to discover HID devices. That vends you various IOHIDDevice objects. You choose one and call IOHIDDeviceOpen on it. Is that right? Are you passing in kIOHIDOptionsTypeSeizeDevice? Share

I'm a bit unclear on your exact question, so let me try to outline a few things for you in hopes that you'll identify your path forward from this information. I need to upload and push to my mobile, but I can't b/c of the old software. I've moved the files to my wife's newer MacBook, but the app doesn't work. It sounds like your iPhone is running a version of iOS that is newer than iOS 16.2. I'm picking iOS 16.2 there because that was the most recent version of iOS at the time Xcode 14.2 was released, and an older Xcode won't know how to talk to an iOS version that is newer than that. You should be able to take your Xcode project — which includes the Xcode project file, and all for resource code and assets — and open it in a newer versions of Xcode without an issue. I presume the Xcode version on your wife's Mac here is more recent than Xcode 14.2; however, depending on the iOS version of your iPhone, you may need to update that Xcode version even further. We have a table on this support page that ex

Regarding try to setActive(YES) for workaround, this only happens 5 seconds after our app detects Audio Session is not activated call started. That doesn't change my answer. Directly activating the audio session will never be reliable and can disrupt CallKit's own ability to manage your audio session. It happens to not be the cause of the problem you're currently looking at, but it can and will cause problems that look EXACTLY the same. Putting this another way, the problem with using setActive ISN'T that it doesn't work, it's that it can SORT of work in a way that can mask and create other issues, both now and in the future. We agree the major key issue is the SessionID 0x0. I have created a feedback for this issue, and submitted sysdiagnose/console logs in it. However, the issue happened on Apr 4, the sysdiagnose was generated on Apr 7. So we are not sure if it could contain the key data on Apr 4. I'll try and take a look later today; however, I've seen enough already to raise the

[quote='852648022, Etresoft, /thread/795994?answerId=852648022#852648022, /profile/Etresoft'] You were relaying what the end user told you [/quote] I stated the opposite: This is what happens for me. I only wrote that the user brought the issue to my attention. Never use the App Store. That sounds like a very generic statement and I don't see a reason why not. Would you like to elaborate?

Hello @Jir_253, Thanks for your questions. I’d recommend that you start by watching Set the scene with SwiftUI in visionOS from this year’s WWDC. Your “CWindow” sounds similar to the Tools window covered in this talk: WindowGroup(Tools, id: tools) { ToolsView() } .restorationBehavior(.disabled) .defaultLaunchBehavior(.suppressed) Similar to iOS where you cannot quit the application yourself, you cannot dismiss the last window of your application. When a user goes to close the main window when the secondary window is open, you cannot close this secondary window if it’s the only window group that is open in your application. Consider adding an affordance to the secondary window to reopen the main window in this case. There's no supported way for you to create parent/child window relationships with the APIs currently available. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number

I’m experiencing the same issue. When you set the alpha parameter to a semi-transparent value (like 0.5), the title becomes slightly visible. This suggests that the background layer is rendered above the title when prefersLargeTitles is enabled. Sounds like a bug in iOS 26 or Xcode. FB19434429