Hi,Since version 2.20.31, released a few days ago, WhatsApp is being built with the iOS 13 SDK, and as such it should have to comply to the new VoIP push notification rules, where an incoming call must be reported to CallKit otherwise the app will be terminated.However we can easily observe from console logs that they are sending VoIP push notifications to awake the app when sending messages from the web client, and that those push notifications not only do not show any native CallKit UI but also keep the app awake long enough to sync with the web client:default 17:09:44.127516+0000 apsd : Received message for enabled topic 'net.whatsapp.WhatsApp.voip' onInterface: NonCellular with payload '{ c = 1; id = 3EB0128F27BBDC904743; t = 1583860183; }' with priority 10 for device token: NO default 17:09:44.146511+0000 SpringBoard Received trusted open application request for "net.whatsapp.WhatsApp" from :343>. default 17:09:44.515731+0000 callservicesd Call source registered with configurationThe logs also mention some type of call source reported but I could not find any related API.From my experience with VoIP pushes, if we don't report the incoming call the app is instantly killed:error 18:56:19.949023+0000 callservicesd Killing VoIP app com.xxxxxx.xxxxxx because it failed to post an incoming call in time.So, how are they doing this? Is there a specific API to report the incoming call as being handled in-app and not requiring the native call UI to be shown? Or are they using some kind of private entitlement that whitelists the app so it doesn't get killed?I'm asking because my app, while fully supporting regular content pushes, we had to drop a web client -like functionality because we could no longer send VoIP pushes to wake the app and reconnect the web socket, and we very much would like to know how we can reactivate it.Thanks in advance for any help.

We have an App Clip for our app that we promote on a webpage via a smart banner. When we open the link on Safari on iOS 14 and scroll the webpage up, the banner is hidden, as expected. However this action makes it become "locked", if we scroll back down the banner does not scroll back into view, we can see it hidden behind the slightly translucent address bar. If we rotate the device to landscape and then back to portrait, the banner "unlocks" and we can scroll it back to view. This appears to be an issue with Safari, does anyone else have this issue or suggestions on a workaround?

Hi everyone. When iOS 14 beta 5 was released we started getting a crash on our app, the classic "Cannot remove an observer <XYZBinding 0x600000d6b750> for the key path "state" from <XYZEntryChat 0x7f960a77a900> because it is not registered as an observer.". However, nothing had changed in our code base to justify that, indeed the code that was crashing hadn't been changed in several months. The crash persists even in the official iOS 14 release. We investigated and, by chance, found that the observationInfo object in XYZEntryChat, that should hold the information about the registered observers, is being deallocated after being created, without any intervention from our part. Also by chance, we found that overriding either the - (void)setObservationInfo:(void *)observationInfo method or the observationInfo getter in the XYZEntryChat class the issue no longer occurs. In many other classes that use the same base code to handle bindings the issue does not occur. We have no further leads on why this is happening, it may be an iOS 14 bug or some behaviour change on iOS 14 that uncovered a wrong usage flow in our app. We also investigated if it was related to Objective-C / Swift interoperability, but other classes that also use / are used by Swift don't have the issue. Has anyone ever came across this behaviour or has any idea of what the root cause may be? Thanks in advance.