Digipass S3 is now DigipassONE. This section is currently being updated to reflect our new name.

Upgrading from 8.0.1 to 9.0.0

  • Updated on Jul 9, 2026
  • Published on Nov 25, 2025
  • 3 minute(s) read
Prev Next

This section contains a list of changes to help upgrade your app from the 8.0.1 version of the iOS App SDK to the 9.0.0 version.

The following changes are introduced in 9.0.0. The client SDKs are backwards compatible and you can continue to use the 8.0.1 APIs. However, there are new features and updated behavior detailed below that could affect your application and it is best to review them to determine if any changes are needed:

  • To use Tutorial App version 8.0.1 with the SDK version 9.0.0, set the version number in TutorialAppPlus/TutorialAppPlus/config.json file to "9.0.0".

  • A new function was added to the IAuthenticationLiveData protocol. If your application adopts that protocol then it must implement the following new function:
    showSign(inPage extras: [String : String]!)

  • The setMethods() function in the IAuthenticationLiveData protocol was changed to receive any error information. If your application adopts that protocol then modify the prototype to match the following:
    setMethods(_ methodsList: NSMutableArray!, opType type: OpType, fidoStatus: FidoStatusEnum, message: String!)

  • The setMethods() function in the IFidoRegistrationLiveData protocol was changed to receive any error information. If your application adopts that protocol then modify the prototype to match the following:
    setMethods(_ fidoMethods: [FidoMethod]!, fidoStatus: FidoStatusEnum, message: String!)

  • The setMethods() function in the IManageRegistrationsLiveData protocol was changed to receive any error information. If your application adopts that protocol then modify the prototype to match the following:
    setMethods(_ registrations: NSMutableDictionary?, fidoStatus: FidoStatusEnum, message: String?)

  • The setMethods() function in the ISuggestRegistrationLiveData protocol was changed to receive any error information. If your application adopts that protocol then modify the prototype to match the following:
    setMethods(_ methodsList: NSMutableArray!, fidoStatus: FidoStatusEnum, message: String!)

  • The setMethods() function in the IRegistrationLiveData protocol was changed to receive any error information. If your application adopts that protocol then modify the prototype to match the following:
    setMethods(_ regs: [MethodRegDisplay]!, fidoStatus: FidoStatusEnum, message: String!)

  • To avoid possible name conflicts, a number of Nok Nok protocols were renamed in the 9.0.0 version. The new names of the protocols have the NNL prefix, and the old names of the protocols are deprecated. For example, AdaptiveUI is deprecated and the new name for the same protocol is NNLAdaptiveUI. Therefore, when Xcode warns you that a protocol has been deprecated, you should add the NNL prefix to the name of that protocol.

  • The deleteRegistration() function no longer supports a nil value for the regID parameter.

    • Beginning with v9.0.0, if nil is passed as a parameter, the function will throw the following error: "The registration Id is invalid."

  • The behavior of AutoStart.AUTO_ANY has changed. If your application uses this mode for authentication then adjust your code to match the following behavior:

    • The promise returned by enable(AutoStart.AUTO_ANY) is rejected only if there is no possibility to complete authentication. If this promise is rejected, your application should not present the AdaptiveAuthenticationView and should not call enable(AutoStart.AUTO_NONE) as it will result in an empty view.

    • The promise returned by enable(AutoStart.AUTO_ANY) is resolved even if authentication does not succeed and the session is still not available. If this is the case then more authentication methods can be used. Your application should present the NNLAdaptiveAuthenticationView and should call enable(AutoStart.AUTO_NONE) to get a list of all possible methods:

.then({ [weak self] result in
        let authData = result as! AdaptiveResult
        if (authData.status  == .INCOMPLETE) {
          //There is a choice for authentication,
          //get new promise here and show NNLAdaptiveAuthenticationView
        } else {
          //authentication is done
          //we can use the authData.sessionData here
          return NSNull()
        }
  })

  • The NNLAdaptiveAuthenticationView::enable()  function is deprecated. Instead, call NNLAuthenticationController::enable() directly:

authViewController?.getController().enable()

  • A new function getIcon() is added to the NNLMethodUIFactory protocol. If your application adopts the NNLMethodUIFactory protocol then it must implement getIcon():

override func getIcon(_ type: String, forName name: String?) -> String?

  • NNLFidoRegistrationController, NNLRegistrationController, and NNLManageRegistrationController no longer call onRefresh() after an operation is complete. If you only display the view from one of these controllers at a time, call onRefresh() on the respective controller when an operation is complete.

    If you display the view from more than one controller at the same time, you need to ensure that a change in one view is reflected in all views. Instead of calling onRefresh() after each operation, adopt the NNLIOperationResultListener protocol to keep the views updated. Here are example implementations of the two functions in the NNLIOperationResultListener protocol:

func onComplete(_ type: ListenerOperationType, result: NNLOperationData!, extras: [String : String]!) {
        //inform controller about operation completion
        mController?.onOpComplete(type, error: nil, liveData: self);
}
func onFailure(_ type: ListenerOperationType, error: Error!, extras: [String : String]!) {
        //inform controller about operation completion
        mController?.onOpComplete(type, error: error, liveData: self);
}