Hi iOS devs,I'm developing Social networking app which includes APNS for Push notification and VoIP for Voice calls. After migrated to Xcode 11.3 and in iOS 13+ devices, sometimes the device token callback not called properly.func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
// APNS Token callback
}func pushRegistry(_ registry: PKPushRegistry, didUpdate pushCredentials: PKPushCredentials, for type: PKPushType) {
// VOIP Token callback
}I tried killing the app and restarting, won't help. After some different ways, i tried turning off & on network and opened my app and then above two callbacks working for me.Also, I searched about this issue and most of developers suggesting to Restart device or turn off & on data/wifi.I don't think this could be possible solution and it's not consistently occuring in a same device. It's occuring randomly in different iOS 13+ devices mostly on fresh installation.Please suggest your solutions.Thanks in Advance,Balaji.
Post
Replies
Boosts
Views
Activity
Hi iOS Devs,In my application, I'm using both APNS & VoIP for Chat and Voice call respectively. In my app, both token generated properly and updated to my App's server. When sending a APNS push from my server, push is successfully reached APNS server. But I'm facing the following issues :1. APNS/VoIP Notification doesn't reach the device properly when app is suspended/killed. When i tried to check server logs, the device token is available & valid and properly sent to APNS server. 2. Sometimes, APNS notification getting delivered while the VoIP notification doesn't received in the device and vice-versa. Is there any dependencies/relations among the both notification ?It occurs mostly on iOS 13+ devices and I've updated Push notification format as specified in WWDC'19.Kindly post your suggestions.
Hi Devs,I'm developing a Social networking app which includes audio call feature. I integrated with SocketIO + WebRTC for this audio call. I'm receiving audio call by two ways.Socket call when socket is connected & activeVoIP call by default irrespective of socket is connected or not.FYI, Why i had two ways of receiving call as mentioned above,Enabled VoIP by default, because sometimes socket call is unresponsive and never show call at that time.Enabled socket when app is in foreground, to ensure that call is received in case of MissingDeviceToken/BadDeviceToken errors occurred for VoIP push.Considering iOS 13 guidelines for VoIP usage, I followed below steps for integration.When app is killed or socket not connected, will get VoIP call and responding with provider.reportNewIncomingCall(). So here no issue for VoIP usage.When socket is connected, will get both socket call & VoIP call. But socket call will get instantly before getting VoIP call. So here's what i did:
Responded socket call with provider.reportNewIncomingCall().After a little delay will get VoIP push for the same call which is already invoked by socket. Here, I should respond this VoIP push with CallKit. But i have already invoked the call. So, I used below code to handle.
provider.reportCall(with: call.uuid, updated: update) with same uuid & update used for socket call initiation.Hope, this VoIP call also responded with CallKit and there's no issue in VoIP blocking/app termination.Question 1 : Is this a proper way of handling above issue ?===========================================================================================================As per my app requirement, there's should be one active call at a time from my app.Consider, I'm in active call and one more incoming call is received via VoIP. So here, I don't want to show the additional call. So I'm ignoring the VoIP push for the additional call. But it leads to this crash "Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push callback."Question 2 : How to handle above mentioned scenario ?===========================================================================================================Kindly post your suggestions.