“Popping Sound”

Thanks, i figure the issue is on the flutter side but just wanted to check here if there is any way its possible for the audio to stop working only when downloading through test flight / app store And yes that is correct to your first statement

My implementation was not including the show password button in the UI when VoiceOver was enabled. @kthchew that's a good point about letting the user manage their risk. Especially if they're wearing headphones. Should I were to include it again, and give the option to the user to speak the password; I probably wouldn't want the accessibility label to be Show Password Perhaps something such as Speak Password? Where the accessibility hint would then indicate that by double tapping the system will speak their password out. Does that sound reasonable or would something else be better for the accessibility label? What about password requirements? My thoughts are if you have a list of password requirements, that UI containing the accessible list of Password requirements should come before the actual password field when VoiceOver is enabled. This way the user knows what the requirements are before they start entering a password.

Hi @muhammadharoon. Thanks for the details. It sounds like you may have a reproducible case. I recommend packaging that up into a bug report so engineering can consider adding further investigation into their work schedule. Capturing this information in a forums post is interesting, but it is not the sort of thing our engineering teams use for scheduling work. Won't you please consider filing a feedback report about this question.

Core Problem: VoIP push notifications are not delivered to the application when it is in the background or terminated. After reviewing existing discussions on the forum, I concluded that the cause might be related to CallKit not having enough time to register. Yes, that's sort of correct. I think root of the problem is actually here: private let voipRegistry = PKPushRegistry(queue: .main) private var provider: CXProvider? ...and is tied to the dynamic of how static object initialization occurs. Basically, your PKPushRegistry object is going to be created IMMEDIATELY after your AppDelegate object is created and before basically any normal app methods are called, including didFinishLaunchingWithOptions. I'm not sure how the full process plays out from there, but I think the net result is that you're losing the initial push because of the time gap between PKPushRegistry's creation and when didFinishLaunchingWithOptions is called and the rest of your initialization completes. One thing to note here is that you ca

Thanks for the post. Sorry for the delay. Very interesting and great question. For alarm-like functionality, local notifications can be paired with custom sounds. The default alarm sounds available on iOS devices are proprietary. This restriction ensures that these sounds remain exclusive to and maintain their intended user experience. As of now, there is no public API that allows developers to access or directly play the built-in iOS alarm sounds in their apps using AlarmKit or any other framework within the iOS SDK. Developers looking to implement alarm functionality in their apps can provide their own audio files. This means you can bundle custom sound files with your app or allow users to select from their own music library I think as well. In summary, as far as I know now, you are currently limited to using custom audio files for alarm sounds in apps, as there is no supported way to access the default iOS alarm tones programmatically

@crexon where does this pop up show? everyone is experiencing that when u update the age ratings without needing to submit binary, and the banner/flag goes away i just confirmed with my apps. there is no such pop up.

Thanks for the post. Upon uploading your app to TestFlight and installing it from there, all audio on your app appears to be disabled? Are you utilizing Flutter? Have you reached out to the support channel for Flutter, the third-party resource you are using? I do not believe this issue is related to TestFlight, as other apps have audio. However, if you can reproduce the issue using Xcode by creating a focused sample and uploading it to TestFlight to verify the presence of audio, that would be helpful. A focused Xcode project that builds and demonstrates the issue. Ideally this will be a new Xcode project created specifically to demonstrate this issue, and which includes only the minimal code and API necessary to reproduce the issue. This focuses on the important code paths and may require you to perform additional debugging to extract the relevant code. Please do not include any 3rd-party code or frameworks unless they are absolutely required for this targeted sample project to run.

No, I am not activating or changing anything in AudioSession. I have pretty straightforward setup; recording an audio using AVAudioEngine and sending to the server (which is running locally for now). And when PTT notification arrives saving url to audio file in incomingPushResult, then downloading and playing that sound using AVAudioPlayer when didActivate is executed. It's working fine on foreground, but when app goes to background incomingPushResult is called as expected but didActivate is not for some reason. Am I missing anything in my setup?

I am having the same issue, channelManager(_:didActivate:) is not called in the background. audio is included in UIBackgroundModes. So, it seems the issue is in the PTT framework itself. No, not necessarily. What audio API are you using and, most importantly, do you EVER activate the AudioSession yourself? The PTT framework is built around the same infrastructure as CallKit, which also means that you MUST rely on it for session activation instead of activating the audio session yourself. CallKit's speakerbox sample is a good starting point for how this should work. I am testing on debug mode, but that shouldn't be a reason, right? No and, in fact, testing with the debugger tends to make this work better than it should[1], not worse. [1] Notably, the debugger disables normal app suspension, so your app ends up being awake in the background in ways that would not normally occur. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Apps cannot initiate any AV sessions while in the background, and definitely not when they are not running. Critical alerts are handled by the system, and the app has no control over the sounds once the notification is created. What you can do is, perform the TTS beforehand, create a sound file with the required speech, and use that sound file as the sound for the critical alert. While you can technically do this in a Notification Service Extension - to create the sound file locally - it might be a practical challenge due to the memory and time limits imposed on extensions. The solution I could suggest would be to have your push notification server to create the TTS sound file, pass on the URL for this sound file in the notification payload, and then have your Notification Service Extension to download this file and reconstruct the critical alert notification using the downloaded file. If you want to try to create the sound file locally,