Popping Sound

We've also double-checked and confirmed that there is no early activation of the audio session before CallKit is expected to activate it. How did you make that determination? The problem here is that AVAudioSession does not provide great visibility into it's activation state, which makes knowing what happened trickier than it might seem. More to the point, here are two key points in your original email that I want to expand on: ...result in one-way audio. The way I understood this is that the receiver of the call can hear audio (Playback) but cannot be heard (Record) by the initiator of the call. In other words, your app DOES have an active audio session, the problem is that it either: Is failing to properly start it's own recording process (meaning, it could be capturing audio data but simply isn't). It activated as a Playback session (not PlayAndRecord), so it cannot record. However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider,

Hello, it sounds like the script uses a third party testing framework. I would recommend following up with the developers of this framework since it may be an issue with the framework itself. You could also try using the standard XCTest framework to see if you can access this view using the identifier.

As of today, it now works by adding the Audio Unit extension to a Swift project. There’s a new hurdle to clear every day.

And then, he came back from the future with the solution: enabled hardened runtime set to FALSE in the build settings. Funnily this setting was set to TRUE by default on a new Audio Unit Extension project using the official Xcode template. Life throws you curveballs.

Hi @DTS Engineer Thank you for your response and insights. We understand your point about AVAudioSession possibly being activated too early by third-party libraries like WebRTC. However, we would like to clarify that our app does not call AVAudioSession.setActive(true) before CallKit triggers didActivate, and we've ensured that WebRTC is initialized only after this delegate method is called. We've also double-checked and confirmed that there is no early activation of the audio session before CallKit is expected to activate it. Despite this, on iOS 18.4.1, we’re seeing a statistically significant increase in the failure rate of didActivate, as shown in our metrics. Given that our app version remains unchanged, and the issue correlates strongly with the iOS 18.4.1 system update, could you help us further investigate whether there might be behavior changes in AVAudioSession or CallKit that could explain this? Any guidance or diagnostic suggestions would be greatly appreciated?

Is it possible to schedule an alarm or run an app logic when the app is in terminated to play the audio instead with overriding DnD and have control over volume? Could read that iOS might terminate or not allow such things running the background when app is in the terminated state.

[quote='784566021, kocaatli, /thread/784566, /profile/kocaatli'] especially if there’s official guidance or references from the Swift core team. [/quote] The Swift Core Team doesn’t hang out here on DevForums. Rather, pop on over to Swift Forums. [quote='784566021, kocaatli, /thread/784566, /profile/kocaatli'] Or is there a better alternative for expressing intent and preventing instantiation? [/quote] Not that I’ve seen. You can prevent external instantiation of a struct by adding a private initialiser: struct MyStruct { private init() { } static func helper() { } } However, that has some drawbacks: It’s extra code. It doesn’t prevent internal instantiation. Honestly, I think the caseless enum is the best option here, and it doesn’t surprise me that the community seems to have standardised on it. Having said that, I get the feeling that I overuse this technique personally. It’s tempting to use it when a better option would be to namespace via a module. To take your first example, if StringUtils were

I am afraid you might be confusing two different features. The entitlement you have been granted would be for Critical Alert Notifications and you probably used Request a Critical Alert Notifications Entitlement form to get it granted. But the feature you are talking about sounds like Critical Messaging as described at Sending SMS messages from an app which uses a self assigned entitlement. So, first you need to make sure you are using the correct entitlement. And you need to make sure you are using the correct entitlement in both Debug and Release builds for your app. As you say things work fine when built from Xcode but not in TestFlight indicates that there are issues in your Release builds - either in configuration or your actual code. You can read Testing a release build to understand the pitfalls you might encounter between two kinds of builds that you may not be seeing in the Debug versions. It is also important to make sure that you are not mixing and matching logic for these two different fe

So, repeatedly calling SCScreenshotManager increments counter accessed your screen and system audio ?