Hi @jphreynaud, just to be clear are you saying that per each complication type, you are seeing more than 10 of your complications? Mine stop at 10. The rest are not there. let complicationServer = CLKComplicationServer.sharedInstance() complicationServer.reloadComplicationDescriptors() Been doing that every time my complications require changing.

I have an update, it turns out that there is a new Apple intermediate certificate: Apple Public Server RSA CA 12 - G1 that needs to also be added to the trust store. This is directly authorized by the AAACertificateServices Root CA. You can get it from: www dot apple dot com / certificateauthority / public . Click on the "valid" link under the Apple Public Server RSA CA 12 - G1 header. This certificate is in PEM format.

Hi @awaisfayyaz17.apple, you're quite welcome. I was able to get detailed help from Apple as to what to do regarding the new vs. old root CAs. I'm sharing and hoping that you may find it useful. If you are using a third party service to send push notifications, it is their responsibility to update their CAs. Therefore contact them to ensure a seamless transition. The rest of this post is for developers who maintain a backend server which directly communicates via HTTP/2 to Apple's APNS servers. The GeoTrust Global CA is currently being used by api.push.apple.com:443. This is indirect via the intermediary certificate Apple IST CA 2 - G1 which is authorized via the GeoTrust Global CA. The site certificate is then authorized via the intermediate Apple certificate. My mistake was not looking all the way up the certificate path to the root, and if I caused any confusion in my earlier posts, I apologize. Regardless of where your server's trust store is located you must make sure that A) it's the one used by server app and B) it contains both the GeoTrust Global CA and the derived intermediary Apple IST CA 2 - G1 certificate. In my case we are using curl and passing a file which contains the root certificate and its intermediary Apple IST CA 2 - G1. In my case, we were using curl with a default where if it could not authenticate the certificate chain of api.push.apple.com it would continue anyway. This was being treated as a warning and not an error, making us potentially susceptible to MITM attacks, as well as other issues in the future. This is easily testable since Apple is currently using that certificate chain until March 29th. Note that api.push.apple.com, api.development.apple.com and api.sandbox.push.apple.com are all using the same certificate chain. As for the new AAACertificateServices Root CA, if you're using a Mac OS X machine to send APNS payloads to Apple, you most likely already have it in your keychain. Still, you should verify it. if it's a Linux or Windows box, you should verify that it's in the trust store being used by your server app to send the APN payload. Keep in mind that although your server has a default trust store, your app may not be using it and may be using a file or some other certificate repository. You need to verify which certificate trust store is being used by your server. When you go to the Sectigo web site (the url is in the Apple announcement as well as in the email send to you by Apple) to obtain the AAACertificateServices, you'll notice that there are 3 certificates: AAACertificateServices 5/12/2020 UserTrustRAAAACA 5/12/2020 COMODORSAAAACA 5/12/2020 The first is the root CA certificate, the last 2 are CA certificates authorized via #1. I assume that they are intermediary certificate, so I grabbed those as well. I placed all 3 in the same trust store as the GeoTrust Global root CA and its intermediary Apple certificate. Now here is the issue. I cannot test the new root CA until Apple makes the switch to it. Furthermore, if the new site certificate for api.push.apple.com is derived from any of the 3 certificates, then everything will work fine after March 29th. However if Apple creates a new Apple intermediary certificate derived from any of those 3 and then has the site certificate authorized by this new Apple intermediary certificate, Apple must share this certificate or the certificate chain will not be validated correctly by your software. I am really hoping that Apple is authorizing the site certificate with the AAACertificateServices root CA, and then everything will work. (It'll also work if Apple does it using the last 2 certificates as well.) Thanks

Hi @awaisfayyaz17.apple, we have a similar situation. We looked for the GeoTrust Root CA in out server's trust store and it's not there, and it's also not being picked up by curl. Our server is a Windows 10 box (don't ask, we have very low volume push notifications and it was not my decision) so it was easy to find the trust store and list all of the root CA's. No GeoTrust Root Ca in it. For Ubuntu 18.xx the trust store is accessible in /etc/ssl/certs/ or /etc/ssl/certs/ca-certificates.crt for the CA certs. What will you do if the GeoTrust Root CA is not in there? For us we specify --cacerts file for the curl command, but it contains the Apple Root CA, which I believe is not derived from the GeoTrust root CA.

Somewhat similar situation as @Nikitkirik here. Although we don't use npm, we use curl to send APN payloads to Apple servers, and it is absolutely not clear why this is necessary. We are not using the GeoTrust root CA for anything, and can't locate it on our servers. Our push notifications have been working for about 2 years and we are using HTTP/2. Can someone from Apple tell me what the GeoTrust Root CA is being used for right now w.r.t APNS? Our SSL cert and key are signed with the Apple Root CA, and so are the Apple push servers (that certificate expires in April 2021 btw). This thread is not very helpful. I had to file a TSI and hopefully someone from Apple will get back to me.

@KJZZZ, I would imagine that it is Firebase's responsibility to update their back end appropriately. Your server connects only to FireBase, so it's out of your domain. Have you considered getting in touch with FireBase directly?

Hello! We use curl on a Windows box to send low volume APN payloads to Apple's server. We DON'T have the GeoTrust Global CA or the new AAACertificateServices in that Windows box's trust store. Can we just add the AAACertificateServices to the curl option --cacerts CACertsFile? I'm not clear why the AAACertificateServices is necessary. The api.push.apple.com SSL certificate is authorized by the Apple Root CA, not GeoTrust Global CA or AAACertificateServices Root CA. So why is it necessary to add it? The curl command line we're using consists of the following options: curl -x http://somePROXY -U X:X -v -d "{\"aps\":{\"alert\":\"Success!\",\"sound\":\"default\"}}" -k --cert path to cert PEM  --key path to cert key --pass "XXXX" --cacert path to Apple Root CA -H "apns-topic: APNS topic" --http2 https://api.push.apple.com/XX/device/YYYYYYYYYYY With the -v curl option we get the following output: HTTP/1.1 200 Connected Proxy replied OK to CONNECT request ALPN, offering h2 ALPN, offering http/1.1 Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH successfully set certificate verify locations:   CAfile: path to CA.pem file CApath: none SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 ALPN, server accepted to use h2 Server certificate:  subject: CN=api.push.apple.com; OU=management:idms.group.533599; O=Apple Inc.; ST=California; C=US start date: Mar 14 17:50:10 2019 GMT  expire date: Apr 12 17:50:10 2021 GMT  issuer: CN=Apple IST CA 2 - G1; OU=Certification Authority; O=Apple Inc.; C=US  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. Using HTTP2, server supports multi-use Connection state changed (HTTP/2 confirmed) Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 Using Stream ID: 1 (easy handle 0x1eeb1e8) POST /x/device/YYYYYYYYYYYYYYYYYYYY HTTP/1.1 Host: api.push.apple.com User-Agent: Our user Agent Accept: */* apns-id: AN APNS ID apns-topic: OUR APNS Topic Content-Length: 208 Content-Type: application/x-www-form-urlencoded Connection state changed (MAX_CONCURRENT_STREAMS updated)! We are completely uploaded and fine HTTP/2 200 apns-id: some APNS ID Thanks

There is no way at the present time for a third party app to detect gestures if your app is in the background and it is suspended.

Any framework engineer want to chime in on this?

From my testing, I've noticed that you can wear 2 watches at once, but only one of them can communicate back to the Watch. If your app doesn't need to talk back to the iPhone or can defer it, you should be good. It is simply a current limitation.

Hi @DorNabet, Have you checked to see if you have any storage space left on the Watch? It is possible to fill up storage and prevent a WatchOS update from installing. It's happened to me before several times.

I’m also having this issue. Submitted 2 builds a few hours ago and don’t see them at all. Typically I see them under activity in processing state within 30 seconds after submission. No emails from Apple. update: I just resubmitted my last 2 builds and I now see them under activity. Thanks @mdb837!

Hi @jungsufromgwanak-gu, If I understand you correctly, you are doing the following: 1 - Getting the URL address of your audio asset in the background. This URL address is the content you wish to get via a background URLSession 2 - Using that URL address to then load the audio content into the player in the background as well 3 - Play the audio content. You are having trouble with 1, 2 or 3? If you're having trouble with 1 that brings up a lot of questions, because you said the URL address is only available for 10 minutes. You cannot schedule a background refresh for less than 15 minutes, so I don't understand how it was working in the first place. Also, even if you could make the scheduling every 10 minutes, how would you synchronize the start of the 10 minutes on the watch with the 10 minutes on the server? As polyphonic pointed out WatchOS could schedule the next background refresh at 10 minutes + n, where n could be several minutes. Typically I schedule background refresh for the smallest time interval (15 minutes) and then at that point I create a background URL session which then downloads my content. So the best that I can do is get my content approximately every 15 minutes. There's no way to make that time interval 10 minutes. Are you certain that in WatchO 6.x.x the address was being obtained via background URLSession every 10 minutes?

Hi @jungsufromgwanak-gu, in your Watch Extension's info.plist for "Required Background Modes", do you have these items: 1 - "App plays audio or streams audio/video using AirPlay" 2 - "App downloads content from the network" 3 - "App processes data in the background"? Also are you debugging in the simulator or on a real device?

Since it is possible to programmatically unwind from a detail screen in WatchOS using either pop() or popToRootController(), it'll be easy to achieve the desired effect. Thanks