Physical volume button pressed notification "AVSystemController_SystemVolumeDidChangeNotification" stopped working with the release of iOS 15. AVAudioSession::OutputVolume (https://developer.apple.com/documentation/avfaudio/avaudiosession/1616533-outputvolume?language=objc) seems like the preferred approach but the limitation is that it doesn't provide a callback when volume is at max (press up) or min (press down). is there any alternative to get the callback even when the volume is at max or min? There is a new notification available "SystemVolumeDidChange" that works similar to "AVSystemController_SystemVolumeDidChangeNotification". Please can you confirm if it a Private API or if it may be used to publish apps on App Store? Our use case requires the physical volume button press notification even if volume is already at max or min. is there any other alternative approach available?

Are you able to reproduce the issue? Yes What software version(s) and hardware have you reproduced the issue on? iOS 14, iOS 15 iPhone XR, iPhone 12 simulator (On All iOS devices) Description When trying to import a P12 certificate using the API SecPKCS12Import, it is failing with error errSecDecode = -26275 since 09/23 in production. We tried to figure out the change in our code base (client as well as server side) that might have triggered this failure but there is no change on either side. The same P12 certificate is successfully validated using the below mentioned openssl command on the terminal. openssl pkcs12 -in -passin pass: Please can you tell us how we may debug the API SecPKCS12Import and understand what might be incorrect in P12 certificate format due to which it has started failing. Note: The same code (with zero change) was working fine in production until 09/23. If required, we may share the p12 certificate and associate password with you to debug it further.

In the WWDC202 video https://developer.apple.com/videos/play/wwdc2020/10110/ at 7:17, it is shown that "NoAuth" is received if Local network permission has been declined. Can we rely on this error code if using NWBrowser API to confidently say that local network permission is not available or could there be other cases where this error may be encountered?

As per the new "Support local network privacy in your app" introduced in iOS 14, if an App use of custom multicast and broadcast protocols, then it requires the com.apple.developer.networking.multicast restricted entitlement. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_multicast Please let us know if a SDK/framework (instead of an App) can get the com.apple.developer.networking.multicast restricted entitlement using developer portal? So that if SDK/framework has the entitlement, the App integrating the SDK will not require entitlement separately.

Q1. Please clarify what all an App need to do to send custom multicast messages using socket level APIs instead of Bonjour APIs. Only Specify service types accessed in Info.plist under Bonjour services. Only Require the com.apple.developer.networking.multicast restricted entitlement. Both 1 and 2. Q2. is "Privacy - Local Network Usage description" always required or is it also optional. If not specified, will iOS present a default local n/w permission prompt to user?

What all an App need to do to create TCP connection on local network. Network permission description in Info.plist Require the com.apple.developer.networking.multicast restricted entitlement. Both 1 and 2.

Please can you share deep linking url to help users open the local network permission settings directly from inside the App.

If an App accesses XYZ.tcp services on local network, does it need to specify sub services like 123.XYZ.tcp or 234.XYZ.tcp, etc in the bonjour services list? Also please confirm the same for SDKs. If a SDK accesses different sub-services on local network depending upon the Host app that integrate it (similar to above scenario), does it need ti specify all sub services through Entitlements on Developer portal? or is it ok to specify just XYZ.tcp?

If an App changes the list bonjour services accessed on local network in upcoming releases, will the user be prompted again for local network permission if there is any change in the services accessed list?

A user might decline the local network permissions by mistake. Is there any flow/policy to prompt the user again to ask for local network permissions if denied earlier?

Please can you confirm the behaviour of an Apps on iOS 14 if user has not updated that app through App store. Let's say an App 'XYZ' accesses local network on iOS 13 and it was working as expected. Then user updates the iPhone to iOS 14 but does not update the App 'XYZ'. can that App still access the local network (to support backward compatibility)? If not, then is Apple looking into some strategy to notify such user to update all the Apps (that require local network permission) as well along with iOS 14?