Popping Sound

I did further investigation and that's step by step I did: Created manifest file: { assetPackID: assettest, downloadPolicy: { onDemand: {} }, fileSelectors: [ { file: audio/test_audio.mp3 } ], platforms: [ iOS ] } Created package assettest and upload it to AppStore Connect via Transporter (verified, delivered, ready for internal testing) xcrun ba-package Manifest.json -o assettest.aar Created new target ManagedAssetPack (Apple-Hosted). BackgroundDownloadHandler file is: import BackgroundAssets import ExtensionFoundation import StoreKit @main struct DownloaderExtension: StoreDownloaderExtension { func shouldDownload(_ assetPack: AssetPack) -> Bool { // Use this method to filter out asset packs that the system would otherwise download automatically. You can also remove this method entirely if you just want to rely on the default download behavior. return true } } Created appgroup and successfully associated main app target and background assets target (I have 3 flavors in main app, Signing&Capab

@DTS Engineer Sure, will do. We have re-implemented the workaround solution and plan to roll it out to production in two weeks. Before proceeding, could you please help double-check if the workaround is implemented as expected in our lab app? Thank you for your assistance. Sysdiagnose log file sysdiagnose_2025.10.28_18-28-20_0800_iPhone-OS_iPhone_23A355.tar.gz has been uploaded in the ticket. FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.)

Thanks for the extra. Another question: [quote='805044021, chevalierpg, /thread/805044, /profile/chevalierpg'] there is no issue when using WiFi [/quote] I’d like to clarify what you mean by “no issue” here. In general, I’d expect Wi-Fi to be slower than Ethernet, but it doesn’t seem like it’d be slow enough to mask this issue. So imagine these scenarios: Server | Network API | Speed ------ | ----------- | ----- Dispatch | Ethernet | A Dispatch | Wi-Fi | B Network | Ethernet | C Network | Wi-Fi | D In both servers I’d expect to see a slight performance loss from Ethernet to Wi-Fi, but it sounds like you’re seeing a much greater performance loss in the Network framework case. That is, the C:D ratio is wildly different than the A:B ratio. Is that right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I found the problem. 1: Because the recording operation needs to press the Bluetooth button and hold it all the time to start recording. Let go and stop recording. 2: When you press and hold the Bluetooth device button. The mobile phone will always receive the data sent by the Bluetooth device. The recorded audio at this time is noise (the app is always running in the background). 3: But it is normal that there is no noise when the app is running in the foreground and repeats the recording operation. 4: Press and lift the Bluetooth device button to start recording. Wait for the recording. Press and lift again. Stop recording. At this time, the recording is normal and there is no noise. 5: So how to do it without changing the audio session mode when long pressing (long press will always receive the data sent by Bluetooth) 6: How to maintain the audio mode at the beginning

[quote='805245021, sonnylife, /thread/805245, /profile/sonnylife'] our core monitoring logic is in a Python daemon. [/quote] I’d like to clarify what you mean by this. On macOS we generally use the term daemon to mean a launchd daemon, that is, something that launchd runs in the global context, usually as the result of a property list file in /Library/LaunchDaemons [1]. However, it sounds like you’re use in in the more general sense of a program that runs in the background. So, how is this program actually launched? You mentioned it’s a child process, so presumably you’re using fork / exec* or posix_spawn or something layered on top of that. In which case, how is the parent process launched? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Or installed as a daemon via SMAppService.

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