I tried below at 2:00 PM on 21/01/2025(JST). Apple Push Notification service server certificate update I followed above, a new server certificate: "SHA-2 Root : USERTrust RSA Certification Authority certificate" was added to my push server, but a certificate error occurred and push notifications could not be sent. So I refered this article,Instead of connecting via DNS name resolution at api.development.push.apple.com, I fixed api.development.push.apple.com to "17.188.143.34" in /etc/hosts, I could push notifications with the new server certificate. (I got this IP(17.188.143.34) from this airtcle) From this, I suspect that Apple had not yet updated the APNs certificate (CA) for the Sandbox environment as of 2:00 PM on January 21, 2025 (JST). Was the update published as scheduled?

You are probably aware of the upcoming root certificate change for any servers you might have that you use to send push notifications by connection to APNs. If you are not, here is the announcement. We have been getting some questions about this, and understand not everyone is familiar with their server setup. First, we would like to clarify that this is only a change to your server's certificate trust store. You do not need to update anything else, like your APNs push certificates, the build certificates and provisioning profiles for your team/app, and so on. All you need to do is to install the mentioned new root certificate to your push server's trust store. If you are using a 3rd party push provider, it is them who will need to handle their servers. But you may want to double check with them nevertheless. If you are managing your own push servers that connect to APNs directly, then it is your responsibility to download and install the root certificate mentioned in the above link on your server(s). Unfortunately we cannot provide specific instructions on how to install this root certificate on every kind of server out there. Each server operating system/push server software will have different ways these root certificates are installed, which is out of scope of our support abilities. If you are not sure how to do this, I would recommend you seek help for this from your server-side developers or server admins. Or, if you don't have access to such resources, you can ask the support channels for your system the question: How do I install a root certificate? We have setup a test server at 17.188.143.34:443 that you can use to try and send pushes to test whether your new root certificate is correctly installed. An alternative way to test this would be, from a terminal prompt: openssl s_client -connect 17.188.143.34:443 -servername api.sandbox.push.apple.com -verifyCAfile USERTrustRSACertificationAuthority.crt -showcerts Change the parameter to the -verifyCAfile argument to point to your trust store, and it should allow you to validate Sample return results would be: Connecting to 17.188.143.34 CONNECTED(00000003) depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority verify return:1 depth=1 CN=Apple Public Server RSA CA 11 - G1, O=Apple Inc., ST=California, C=US verify return:1 depth=0 C=US, ST=California, O=Apple Inc., CN=api.sandbox.push.apple.com verify return:1 Argun Tekant /  DTS Engineer / Core Technologies

I see the log in my server and they told that PTT notification sent successful but bellow function not call from my app. Could you give me any suggest? func incomingPushResult(channelManager: PTChannelManager, channelUUID: UUID, pushPayload: [String: Any]) -> PTPushResult

Is there a way to prevent or disable either of the following system PTT screens? When on the lock screen, you can tap the PTT indicator at the top of the screen to show a full-screen PTT view that includes both a "Leave" and "Talk" button When on the home screen, you can tap the PTT indicator at the top of the screen to show the PTT "Pill" that includes a "Talk" button I'd like to prevent showing both of these views. We don't use them in our app (we use PTT to play back messages, but use hands-free voice commands to send messages back). Is it possible to disable/never show those system PTT views? Screenshots of them attached.

Hello, I've been working to implement PTT in the way recommended by the documentation. The main issue is that the bluetooth methods are opaque, so I cannot solve for what I need. The result will be that I will have to resort to hacky approaches that the PTT framework seems to be intended to solve (playing silent clips, playing custom notification sounds, having long running background audio sessions). I am testing with Anker soundcore mini as well as airpod pro. Here's the issue: there are 2 very different behaviours depending on whether I'm using a call/fullDuplex session and a halfDuplex session. halfDuplex Anchor mini Current behaviour long press activates siri pressing again after siri is active, starts transmission long press activates siri again pressing again after siri is active, stops transmission pause/play routes to the ongoing media session and plays music Expected behaviour play/pause should map to transmit/stopTransmit IF I have to use long press, it should at least not trigger siri AirPod pro Current behaviour long press changes noise cancellation pause/play routes to the ongoing media session and plays music Expected behaviour play/pause should map to transmit/stopTransmit fullDuplex/call Anchor mini: Current behaviour long press activates siri pressing again after siri is active, starts transmission long press activates siri again pressing again after siri is active, stops transmission pause/play routes to the ongoing media session and plays music Expected behaviour play/pause should map to transmit/stopTransmit IF I have to use long press, it should at least not trigger siri AirPod pro Current behaviour long press changes noise cancellation pause/play maps to mute/unmute (even if media is playing) Expected behaviour This makes sense for call behaviour, I wish it worked this well for PTT The intention here is to be able to fully interact with a channel hands-free. The current API seems to make that impossible. Is that by design? Reading all the docs seems to suggest its intended for transmit/stopTransmit to be doable just with the play/pause buttons, but even apple hardware seems to not support that.

Recently, we have started seeing this countdown in the dynamic island and it enables kind of listening mode and app completely loses the talk button. This is seen very recently and I cant make what it really is. I would like to know what this UI is and how I can bring back talk button.