Popping Sound

@StevenPeterson Thanks for chiming in and thanks for the video itself, much appreciated. No, the view bodies are only run if the body uses the environment value for the key(s) used in that view and the value changes. That makes a lot more sense to me and aligns with the simple demo app I made to test out my original question. Consider: struct ContentView: View { @Environment(.name) var name @Environment(.age) var age var body: some View { Text(name) } } If .name is updated anywhere, then ContentView.body will be run but if .age is updated anywhere, then body is not run because .age is not referenced in the body. What worried me was that if somewhere else a view wrote to .address, then ContentView would be re-evaluated even though it doesn't refer to .address in any way. That's how I (incorrectly) interpreted the slide above. But in SwiftUI, an update doesn't always cause the view body to run again, but there is still a cost associated with these updates. That's the real clarifying statement, for me. There's

Hi! I'll try to provide some clarification: Does writing any value to the environment really cause all views in the entire SwiftUI view hierarchy that read any environment key to have their body re-evaluated? No, the view bodies are only run if the body uses the environment value for the key(s) used in that view and the value changes. But in SwiftUI, an update doesn't always cause the view body to run again, but there is still a cost associated with these updates. In Instruments, these updates are labeled as skipped. The demo in the video shows that the cumulative cost of all the skipped updates (seen in the Consequences detail view) is significant, even without their associated view bodies running (the view that demonstrates this in the video is called CardBackView). Do environment writes only affect child views, or do they propagate through the entire SwiftUI hierarchy? Great question! This only applies to child views of the .environment modifier that you're writing with. So if View B uses an .environment m

There are various reports of this issue scattered about. Any time I start to hear the crackle I run the following command from a terminal window: sudo pkill coreaudiod That fixes the issue for a while. If you run that while playing music or other audio, the sound will stop for a couple of seconds as the process restarts and then the audio will come back without the crackle.

First, let me explain my understanding of this API. I believe its purpose is to allow an app to trigger tasks that can be represented with progress indicators and require a certain amount of time to complete. I put things much more simply than that and say that the goal is simply to provide an API that gives apps an extended period of time to complete user-critical work after they enter the background. The progress requirement exists as a practical UI compromise so that the user can see something and the system has some assurance that the app is still functioning. I'd also push back on the trigger tasks part of this. Nothing requires your app to actually bind its activity to the continuing task and, in fact, I think there are many situations where your app should simply start the work immediately, with the continuing task acting as a backup in case your app is sent to the foreground. See this forum thread for an extended discussion of this. After I called register and submit, the BGContinuedProcessingTask cou

My app uses CallKit and PushKit for real-time voice and video calls. I want to configure VoIP push notifications so incoming calls can wake the app, even when it’s in the background or terminated. Right now, I only see the normal Push Notifications option in my App ID settings and no VoIP Services section. I'm not entirely sure of what you're looking at here, so I'm going to give you a general rundown of how VoIP apps are configured and hope that covers your questions: The app itself doesn't actually have any special configuration on the developer portal. In Xcode, you do need to add both the voip and audio background categories, but both of those are actually modifying the UIBackgroundModes Info.plist key, so that doesn't actually impact the portal. Most VoIP apps also implement standard push, both to support text messaging and for things like notifying the user of missed calls. However, receiving VoIP pushes does NOT actually require authorization from the user. The modern approach to sending VoIP

[quote='806537021, jay2013, /thread/806537, /profile/jay2013'] This has to be a bug. [/quote] Well, that depends on your point of view (-: When dealing with managed capabilities like this, the system allows for various restrictions, and it seems that whoever set this up decided to apply this restriction (or made a mistake). I’m not involved in that process, so I can’t offer any insight into that. [quote='806537021, jay2013, /thread/806537, /profile/jay2013'] How do I get Apple to fix this? [/quote] My general advice for entitlement problems like this is to start a support request via Apple > Developer > Contact Us > Development and Technical > Entitlements. It sounds like you’ve already done that. You should’ve got back a case number. Please post that here. Also, can you post the first and last letters of your Team ID. For example, the Team ID of my individual test team is SKMME9E2Y8, and the redacted version is S________8. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Suppo

Thanks for filing the feedback report (FB20915258) for us. Given that complications render correctly on the watch, it does sound like an issue on the Watch app in iOS. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Could you please advise on which framework or API Apple recommends for a third-party application to intercept and process the audio stream—specifically, to apply a GAIN factor to PCM samples—during an active CallKit call? AVAudioEngine is the API we generally recommend for lower level audio processing. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

For #1 I think our recommendation would be to never rely on the main menu bar existing but I can certainly see challenges in building a UI that way at times! For #2 that sounds buggy to me but I don't know for sure. If nothing else it would probably make good feedback, since I would hope that we would behave consistently in this respect regardless of modes. I'll ping some folks and see if there is any additional insight they can provide here.

Thank you for the clear explanation. We must emphasize that, as a Mission critical Push-to-Talk (PTT) application, the perceived volume and clarity of the audio are fundamental user requirements. We currently achieve the necessary amplification and clarity using a custom PCM gain factor. Therefore, the ability for our application to apply a specific gain factor to PCM samples for amplification is essential. Could you please advise on which framework or API Apple recommends for a third-party application to intercept and process the audio stream—specifically, to apply a GAIN factor to PCM samples—during an active CallKit call?