Post not yet marked as solved
I had a problem with VoIP and Standard notifications with iOS 14.X only devices.
My scenario is as follows:
I have two iOS devices:
User A, User B
Interrupt the internet connection at user B
User A call User B via my VoIP application
Wait 15 seconds and activate the internet for B
Issue:
VoIP notification of the call is not received for User B
Side effect:
Randomly after this scenario, User B may no longer receive VoIP and standard (for text) notifications until I reboot the device.
This side effect is more common when I switch to LTE 7/10
When I switch to WIFI, I was able to reproduce it 1/20
PS: If user B is using iOS 12 or iOS 13 it works fine.
Post not yet marked as solved
I had a problem with VoIP and Standard notifications with iOS 14.X only devices.
My scenario is as follows:
I have two iOS devices:
User A, User B
Interrupt the internet connection at user B
User A call User B via my VoIP application
Wait 15 seconds and activate the internet for B
Issue:
VoIP notification of the call is not received for User B
Side effect:
Randomly after this scenario, User B may no longer receive VoIP and standard (for text) notifications until I reboot the device.
PS: If user B is using iOS 12 or iOS 13 it works fine.
Post not yet marked as solved
Hello,
I have a question that could help better understand a change in iOS 14.5 Beta, it could be a problem with this Beta. For my test:
I am using an iPhone 11 Pro device.
Device connected via WIFI
iOS 14.2:
handling this SCNetworkReachabilityGetFlags return kSCNetworkReachabilityFlagsReachable.
When I upgraded to iOS 14.5, the result is different which became kSCNetworkReachabilityFlagsReachable | kSCNetworkReachabilityFlagsTransientConnection
Could someone explain this change to me and is it a bug with iOS 14.5?
Post not yet marked as solved
Hi,
I have a big problem to find an effective solution to detect the country where the device is located.
First of all I wanted to use the MCC, MNC from CoreTelephony (CTCarrier) and then it turned out that I cannot rely on this information since the framerwork only provides the information from the Sim Card. So there will be a problem in the case of roaming.
The second solution is to use the CoreLocation framework which is not efficient since there are applications like iMyFone AnyTo which can break my whole algorithm.
Can you help me resolve this situation?
Note that I wanted to publish my application so using private APIs is not an option
Post not yet marked as solved
Hi, During my documentation on the DeviceCheck framework, Apple mentions that it is necessary to check if the service (API) is well supported by the device. There is no description on the devices that does not support this service. I understood that the simulators do not support this service as well as the device which uses an iOS less than iOS 11. But do you have an idea on the other devices which do not support it?
This will help me a lot with the client / server implementation and the use of the framework.
Thanks in advance
Post not yet marked as solved
My application uses the CallKit framework to notify users of VoIP calls, I have a key feature for our customers which allows the user to automatically accept received calls. this function works perfectly up to the version of iOS 13.3. from iOS version 13.3.1 the application automatically accepts the call but the callkit view always displays the buttons to accept or end the call and does not update following the automatic action, this problem does not appear when the application is open on the other hand it is reproduced when the application is in the background.
STEPS TO REPRODUCE
Precondition: User A has the application installed
User B has the application installed and the Auto answer option activated.
User B puts the application in Background or application close.
User A call User B via the application using VOIP.
The CallKit screen is displayed for user B.
The application automatically accepts the call received from user A.
Issue: The Callkit screen continues to display the buttons accept and refuse when actually the call is already accepted.
Can you verify this problem because it seems to me that this is not a modification by design since the problem occurred starting from iOS 13.3.1.
Post not yet marked as solved
Hello,As indicated on the Apple documentation, we must call the requestAlwaysAuthorization methodbefore you can receive location information. You may call requestAlwaysAuthorization when the current authorization state is either:Not Determined (kCLAuthorizationStatusNotDetermined), orWhen in Use (kCLAuthorizationStatusAuthorizedWhenInUse).calling this method will start the process of requesting "always" * authorization from the user. Any authorization change as a result of * the prompt will be reflected via the usual delegate callback: * -locationManager:didChangeAuthorizationStatus.An application which currently has "when-in-use" authorization and has * never before requested "always" authorization may use this method to * request "always" authorization one time only. Otherwise, if * +authorizationStatus != kCLAuthorizationStatusNotDetermined, (ie * generally after the first call) this method will do nothing. * * If your app is not currently in use, this method will do nothing.So, in general : Your app can no longer ask for Always authorization after the user responds to the location permission prompt. Calling this method again will have no effect.The problem with iOS 13.1, calling this method and user chose already Allow Once, continue reflecting via the usual delegate callback : locationManager:didChangeAuthorizationStatusProblem not reproduced with Beta 13.0.Problem persist only when user select new permission option: Allow onceDid you have this problem like me?I would like Apple to review this problem.
Post not yet marked as solved
With the changes enforced and outlined in https://developer.apple.com/videos/play/wwdc2019/707/, We are now forced to report an incoming CallKit call immediately after receiving the VoIP notification. We are using PushKit in voip context, but not neccessarly with CallKit. How does Apple expect us to deal with these situations:CallKit with China: As you know, apps cannot use CallKit for users in Mainland China since 2018. How should a VoIP app handle receiving a PushKit VoIP push for a user in Mainland China?VoIP Calls not compatible with CallKit interface: Our application support VoIP/Video Call which is compatible with CallKit and PTT (Walkie-Talkie) Call which is not compatible with Call system interface as we are not able to customise the Call Interface with specific design (PTT button, timer...). Notification Service extension is not the good option as we need to handle 2 different Notification based on Call Type: PushKit Notification for VoIP/Video Call and Standard Notification for PTT !!Last point: There are various articles in the news discussing the tightening of VNS requirements in iOS 13. They all mention April 2020 as the deadline to comply with the news rules. Could you confirm that April 2020 is the correct deadline?
moalla.