When iOS is on lockscreen "slide to answer" doesn't open app.

[un-hongly]

Hi, I have an issue with the incoming call locked screen when "slide to answer" doesn't open the app instead it just stays on the call screen.

[hiennguyen92]

Only open app when type video call. Audio call only show callkit framework

[un-hongly]

Only open app when type video call. Audio call only show callkit framework

@hiennguyen92 Thanks you for the fast response :). Actually, It's a video call (type 1). For more information, I tested it on iOS 12.4.8 and I showed it with flutter code FlutterCallkitIncoming.showCallkitIncoming() not swift code.

[itsthetaste]

Setting type=1 and supportsVideo=true in my voip notification makes my app bypass this screen. I also have my audioSessionMode set to videoChat, but doubt that has an impact. My app is only supporting iOS 15+ though, so perhaps apple only introduced the ability to bypass in later versions than what you're testing.

[albrave]

Almost same issue here. it seems totally random. Sometimes it correctly open the app and sometimes no.

The only sure thing is that is happening only on iOS 16 and when I was able to debug during the issue I had this error on the debugger console:

NSOSStatusErrorDomain Session

The notification is set as video (I see the call as a video call) and the callkit logo is correctly implemented.

[albrave]

I don’t know if this could be useful

https://developer.apple.com/forums/thread/712817

[federico-amura-kenility]

any update on this? if my phone its locked, i can asnwer the call but then I get stuck on the lockscreen, the app is not getting opened

[colaTW]

Almost same issue here. it seems totally random. Sometimes it correctly open the app and sometimes no.

The only sure thing is that is happening only on iOS 16 and when I was able to debug during the issue I had this error on the debugger console:

NSOSStatusErrorDomain Session

The notification is set as video (I see the call as a video call) and the callkit logo is correctly implemented.

Have you resolved this issue? If so, please let me know. Thank you.

[albrave]

Hi, I used another callkit https://github.com/voximplant/flutter_callkit In general, as far as I know, there's no solution to detect when the user unlock the screen with faceID or fingerprint BUT that voximplant callkit gives you the possibility to force the app opening through 'fulfill()' native method of the apple callkit. The workaround I used is wait for 4 secs after the user accept the call and open the app through 'fulfill()' method

_provider.performAnswerCallAction = (answerCallAction) async {
      Timer(Duration(seconds: 4), () async {
            await answerCallAction.fulfill();
      });
};

[cosnomi]

I don’t know if this could be useful

https://developer.apple.com/forums/thread/712817

    public func provider(_ provider: CXProvider, perform action: CXAnswerCallAction) {
        guard let call = self.callManager?.callWithUUID(uuid: action.callUUID) else{
            action.fail()
            return
        }
        DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(1200)) {
            self.configurAudioSession()
        }
        self.answerCall = call
        checkUnlockedAndFulfill(action: action, counter: 0)
    }

    private func checkUnlockedAndFulfill(action: CXAnswerCallAction, counter: Int) {
        if UIApplication.shared.isProtectedDataAvailable {
            sendEvent(SwiftFlutterCallkitIncomingPlugin.ACTION_CALL_ACCEPT, self.data?.toJSON())
            DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(5000)) {
                action.fulfill()
            }
    } else if counter > 180 { // fail if waiting for more then 3 minutes
        action.fail()
    } else {
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            self.checkUnlockedAndFulfill(action: action, counter: counter + 1)
            }
        }
    }
    

Thanks to albrave, I found that waiting for isProtectedDataAvailable to be true and adding another sleep after that actually worked. However, the solution is unstable; reducing the sleep time from 5000 ms to 1200 ms caused an error. I believe it depends on the processing speed of user devices, which implies that this solution might not work for some devices.