“Popping Sound”

UIBackgroundModes includes push-to-talk Did you also include audio? You actually need both. Strictly speaking, push-to-talk allows you to receive PTT pushes while audio allows your audio session to activate in the background. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

OK, thank you. So I do have an Enterprise account; on the device I installed the app by hand, I do have the trust setting, and it’s trusted. The app will launch and exit and just sit in the background. To give you a scale, we deploy the application via MDM to our fleet, which is less than 10,000. We have been seeing devices more regularly where the app launches and exits right after seeing the splash screen. I think the next step here is to reproduce the problem, collect a sysdiagnose (make sure you don't reboot the device until you've collected the log), then take a look at the console log to see what happened. I don't know what you'll find, but the device WILL log anytime in choose/can't run an app. This also seems to occur on newly enrolled devices. FYI, the devices are all supervised. One last data point. If I sign the app as AdHoc using another non-enterprise developer account, the app installs (did not use MDM) and launches and runs fine. Sure. All of this sounds like a problem with the enterpr

3: Use a Bluetooth device to call up the microphone for audio recording and write the audio data to the file. What is the “Bluetooth device here? Is it: (1) A standard, classic Bluetooth, consumer headset (A2DP/HFP)? To support these, all you need to do is enable accessory events using setAccessoryButtonEventsEnabled(...), at which point the PTT framework will start delivering events through the standard delegate methods. The main issue to be aware of here is that the entire process that makes this work is inherently a bit weird and can look somewhat buggy. For example, many A2DP head units automatically send play on connect, which the PTT framework will convert to a start transmission. The problem here is that the system doesn't really have any way to know exactly what kind of device it's dealing with (for example, differentiating between an headset and a head unit), which means any attempt to really fix one edge case ends up breaking other devices. Two points to all of this: Your app is go

Okay, I made it working exactly as I wanted, so I'd like to inform all people participating here, but also others who might see this while searching for similar content. The first stumbling block was making sure the application can actually send Apple Events in the first place. And in that regard I admit I should've listened better to @Etresoft and I apologize to him for not listening more carefully and dismissing his remark about hoops so that the app can actually send Apple Events too easily. It turned out that, even though the application is NOT sandboxed, com.apple.security.automation.apple-events entitlement is mandatory in the entitlements file. I couldn't assume it would be necessary even for a NON-sandboxed app, but it is. From my experience with executing AppleScript from another, sandboxed, application I remember that defining com.apple.security.automation.apple-events in the entitlements file and NSAppleEventsUsageDescription in the Info.plist file always go together and that's the case here too. S

1: Turn on the PushToTalk status 2: The application switches to the background 3: Use a Bluetooth device to call up the microphone for audio recording and write the audio data to the file Can you help me write the relevant code? ( I spent more than a month on this function, but it hasn't been solved) Thank you.

What I don't understand from the reviewer's response is what receipts validation are they talking about? When a user makes a purchase, it creates a receipt in the app bundle. Your app should check the validity of that receipt. If it is valid, then you make the premium features available. If you don't validate the receipt, then hackers will re-distribute your app with a fake receipt so that anyone can use it for free. They might even charge a fee, making money off your app instead of you. Don't assume you're too small to be targeted. I assure you that you're not. I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation) That's something totally different. Most apps are subscription based or have some service provided over the internet. For these use cases, Apple provides a quick-and-easy way to validate receipts. In your case, since you're entirely on-device, you'll need to validate the receipt on-device. That's tricky beca

So, let me start here: But there are problems with clicking on recorded audio on Bluetooth devices (all noise or no sound during playback). The thing to keep in mind here is that Bluetooth has two entirely separate audio mechanisms, which have very different levels of audio quality and behavior: A2DP -> Playback only, higher quality, modeled as music player. HFP -> Play and record, lower quality audio, modeled as a phone. Switching between those modes isn't immediate, so manipulating the audio session configuration can change how audio sounds and/or cause odd glitches. These issues will also be worse in the background, where your app no longer has direct/less control over the audio session state. In terms of your code, there are a few different issues: (1) AVAudioPlayer should not be used for exactly the same reasons you should not use AVAudioRecorder. All your playback and recording should be going through AVAudioEngine. (

This is a known issue in the wording of the error message in Xcode 26.0 and 26.0.1 that makes it sound like Xcode does not have your ChatGPT Plus account logged in. If you want us to double check that the number of actual requests is within your limit, please file a feedback request with a sysdiagnose and say I was asked on the forums to file this to double check my limits

PTTManager This is my PTT code 1: Click on the intercom button and Bluetooth device button on the PushToTalk interface. The recording all starts in this method (channelManager: PTChannelManager, didActivate AudioSession: AVAudioSession) 2: There is no problem with recording audio by clicking the intercom button on the PushToTalk interface. But there are problems with clicking on recorded audio on Bluetooth devices (all noise or no sound during playback) 3: The method called after the application switches to the background (setupChannelManager (channelUUID: UUID)) 4: The method called by clicking the Bluetooth button (requestBeginTransmitting()) 5: The above scenarios are all when the application switches to the background (the application has set the background to keep alive and Background Modes) 6: All functions are normal without any issues when the application switches to the frontend.

FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.) I've looked over the sysdiagnose from that log and I'm left a bit confused. You said that you've applied the workaround I'd suggested, but when I look at the log you sent I don’t see the workaround I'd suggested. I can see where you're reporting calls: 2025-10-23 16:00:39.916170+1100 : (CallKit) [com.apple.calls.callkit:Default] Provider was asked to report a new incoming call with UUID: update: … 2025-10-23 16:01:34.063889+1100 : (CallKit) [com.apple.calls.callkit:Default] Provider was asked to report a new incoming call with UUID: update: … 2025-10-23 16:02:01.765404+1100 : (CallKit) [com.apple.calls.callkit:Default] Provider was asked to report a new incoming call with UUID: update: However, if the workaround was active I'd expect to see a log message like this before each of those call reports: 2025-10-23 16:00:39.916170+1100 : (CallKit) [com.apple.calls.callkit:Default] Provider was notified that