Upgrade instructions for older versions

Instructions to upgrade iOS SDK version to 6.x

When upgrading from a version 5.x SDK to version 6.x, several changes have to be applied in your application.

Note: Starting from this version we removed the leading zeros from our versioning scheme. So the SDK uses the standard major.minor.patch versioning scheme.

Removed API's

  • ONGUserClient
  • enrollForMobileAuthentication: and storeDevicePushTokenInSession: ==> removed in favour for enrollForMobileAuth: and enrollForPushMobileAuthWithDeviceToken:completion. You can now enroll for mobile authentication without enrolling for push mobile authentication. Enrollment for push requires enrollment for mobile authentication to be done first.
  • ONGMobileAuthEnrollmentErrorMissingDevicePushToken ==> the error is no longer returned
  • ONGPublicCommons - file removed
  • ONGSDKInitializationException ==> removed in favour for NSInternalInconsistencyException
  • isEnrolledForMobileAuth ==> isUserEnrolledForMobileAuth:
  • isEnrolledForPushMobileAuth ==> isUserEnrolledForPushMobileAuth:

Removed deprecated API's

  • ONGUserClient
  • handleApplicationURL: ==> respondWithURL:challenge: method of id<ONGRegistrationRequestChallengeSender> object provided by the ONGRegistrationRequestChallenge Registration redirect URL can now be passed to the sdk using id<ONGRegistrationRequestChallengeSender>, which makes handleApplicationURL: obsolete.
  • ONGRegistrationDelegate
  • userClient:didReceiveRegistrationRequestWithUrl: ==> userClient:didReceiveRegistrationRequestChallenge: The URL is passed within the ONGRegistrationRequestChallenge object. It also provides a sender object used to respond with the redirect URL or to cancel the registration.
  • ONGClientBuilder
  • setUseEmbeddedWebView ==> No longer required. The Onegini SDK no longer distinguishes how the registration request URL is handled.
  • ONGPublicCommons
  • ONGCloseWebViewNotification ==> No longer required. Called only if setUseEmbeddedWebView was set to YES. The Onegini SDK no longer distinguishes how the registration request URL is handled. If the registration request URL was handled within a UIWebView, it could be closed as soon as you send a response to the ONGRegistrationRequestChallengeSender or when you receive the userClient:didReceivePinRegistrationChallenge: on your ONGRegistrationDelegate.

Renamed API's

  • ONGUserClient
  • handleMobileAuthenticationRequest:delegate ==> handlePushMobileAuthRequest:delegate:
  • canHandleMobileAuthenticationRequest ==> canHandlePushMobileAuthRequest
  • ONGMobileAuthenticationRequest ==> ONGMobileAuthRequest
  • ONGMobileAuthenticationRequestDelegate ==> ONGMobileAuthRequestDelegate
  • didFailToHandleMobileAuthenticationRequest ==> didFailToHandleMobileAuthRequest
  • didHandleMobileAuthenticationRequest ==> didHandleMobileAuthRequest
  • ONGMobileAuthenticationEnrollmentErrorDomain ==> ONGMobileAuthEnrollmentErrorDomain
  • ONGMobileAuthenticationEnrollmentErrorUserNotAuthenticated ==> ONGMobileAuthEnrollmentErrorUserNotAuthenticated
  • ONGMobileAuthenticationEnrollmentErrorDeviceAlreadyEnrolled ==> ONGMobileAuthEnrollmentErrorDeviceAlreadyEnrolled
  • ONGMobileAuthenticationEnrollmentErrorEnrollmentNotAvailable ==> ONGMobileAuthEnrollmentErrorEnrollmentNotAvailable
  • ONGMobileAuthenticationEnrollmentErrorUserAlreadyEnrolled ==> ONGMobileAuthEnrollmentErrorUserAlreadyEnrolled
  • ONGMobileAuthenticationEnrollmentErrorMissingDevicePushToken ==> ONGMobileAuthEnrollmentErrorMissingDevicePushToken
  • ONGMobileAuthenticationEnrollmentErrorNotEnrolled ==> ONGMobileAuthEnrollmentErrorNotEnrolled
  • ONGMobileAuthenticationRequestErrorDomain ==> ONGMobileAuthRequestErrorDomain
  • ONGMobileAuthenticationRequestErrorNotFound ==> ONGMobileAuthRequestErrorNotFound
  • ONGMobileAuthenticationRequestErrorUserDisenrolled ==> ONGMobileAuthRequestErrorUserDisenrolled

Renamed errors

  • ONGSDKInitialisationErrorDeviceRegistrationFailed ==> ONGGenericErrorDeviceRegistrationFailure
  • ONGRegistrationErrorDeviceRegistrationFailure ==> ONGGenericErrorDeviceRegistrationFailure

Removed error domains

  • ONGSDKInitializationErrorDomain The Initialization error domain is removed since it didn't contain any errors anymore after renaming & moving the ONGSDKInitialisationErrorDeviceRegistrationFailed error to the ONGGenericErrorDomain.

Instructions to upgrade iOS SDK version to 5.02

When upgrading from an older SDK version to version 5.02, several changes have to be applied in your application.

Although it is still possible to use the old API's we recommend to update to the new API's since the old ones will be removed in the next big update of the SDK.

Deprecated API's

ONGUserClient

  • handleApplicationURL: ==> respondWithURL:challenge: method of id<ONGRegistrationRequestChallengeSender> object provided by the ONGRegistrationRequestChallenge
    Registration redirect URL can now be passed to the sdk using id<ONGRegistrationRequestChallengeSender>, which makes handleApplicationURL: obsolete.

ONGRegistrationDelegate

  • userClient:didReceiveRegistrationRequestWithUrl: ==> userClient:didReceiveRegistrationRequestChallenge:
    The URL is passed within ONGRegistrationRequestChallenge object. It also provides sender object used to respond with redirect URL or to cancel registration.

ONGClientBuilder

  • setUseEmbeddedWebView ==> No longer required.
    Onegini SDK no longer distinguishes how registration request URL is handled.

ONGPublicCommons

  • ONGCloseWebViewNotification ==> No longer required. Called only if setUseEmbeddedWebView was set to YES.
    Onegini SDK no longer distinguishes how registration request URL is handled. If registration request URL was handled by within UIWebView, it could be closed as soon as you send response to ONGRegistrationRequestChallengeSender or when you receive userClient:didReceivePinRegistrationChallenge: on your ONGRegistrationDelegate.

Instructions to upgrade iOS SDK version to 4.10

When upgrading from an older SDK version to version 4.10, several changes have to be applied in your application:

Although it is still possible to use the old API's we recommend to update to the new API's since the old ones will be removed in the next big update of the SDK.

Also the multiple profiles feature is not available when your app still uses the old API's.

Deprecated API's

OGOneginiClient

  • authorize ==> registerUser:delegate: and authenticateUser:delegate:.
    The authorize method had a dual responsibility: registering users and authenticating users. It has been split up into two methods: registerUser:delegate: and authenticateUser:delegate:. Use the first method in case you want to let a new user register his account in the application. After registration you must use authenticateUser:delegate: to authenticate the user. Only registerUser:delegate: will interact with a browser.

  • reauthorize: ==> reauthenticateUser:delegate:

  • authorizeClient: ==> authenticateClient:delegate:

  • confirmCurrentPin: ==> confirmPin: in the OGPinConfirmation protocol.
    Delegating control from the SDK to the app regarding the PIN has been changed to make it more clear that it is part of the authentication process. Therefore the SDK will call the askForCurrentPinForUser:pinConfirmation: method on the OGAuthenticationDelegate implementation. In response to the askForCurrentPinForUser:pinConfirmation: method which contains a delegate on which confirmPin must be called. The OGAuthenticationDelegate is the delegate that needs to be passed when calling authenticateUser:delegate:. Please look at the user authentication topic guide for more information regarding this topic.

  • confirmNewPin: ==> confirmPin: in the OGPinConfirmation protocol.
    Delegating control from the SDK to the app regarding the PIN has been changed to make it more clear that it is part of the registration process. Therefore the SDK will call the askForNewPin:user:pinConfirmation: method on the OGAuthenticationDelegate implementation. In response to the changePinRequest: method which contains a delegate on which confirmPin must be called. The OGAuthenticationDelegate is the delegate that needs to be passed when calling registerUser:delegate:. Please look at the user authentication topic guide for more information regarding this topic.

  • confirmCurrentPinForChangeRequest: ==> confirmPin: in the OGPinConfirmation protocol
    Delegating control from the SDK to the app regarding the PIN change functionality has been changed to make it more clear that it is part of the change PIN process. Therefore the SDK will call the askCurrentPinForChangeRequestForUser:pinConfirmation: method on the OGChangePinDelegate implementation. In response to the askCurrentPinForChangeRequestForUser:pinConfirmation: which contains a delegate on which confirmPin must be called. The OGChangePinDelegate is the delegate that needs to be passed when calling changePinRequest:.

  • confirmNewPinForChangeRequest: ==> confirmPin: in the OGPinConfirmation protocol
    Delegating control from the SDK to the app regarding the PIN change functionality has been changed to make it more clear that it is part of the change PIN process. Therefore the SDK will call the askNewPinForChangeRequest:pinConfirmation: method of the OGChangePinDelegate implementation. In response to the askNewPinForChangeRequest:pinConfirmation: which contains a delegate on which confirmPin must be called. The OGChangePinDelegate is the delegate that needs to be passed when calling changePinRequest:.

  • confirmCurrentPinForFingerprintAuthorization: ==> confirmPin: in the OGPinConfirmation protocol
    Delegating control from the SDK to the app regarding the fingerprint enrollment functionality has been changed to make it more clear that it is part of the fingerprint enrollment process. Therefore the SDK will call the askCurrentPinForFingerprintEnrollmentForUser:pinConfirmation: method on the OGFingerprintDelegate implementation. In response to the askCurrentPinForFingerprintEnrollmentForUser:pinConfirmation: which contains a delegate on which confirmPin must be called. The OGFingerprintDelegate is the delegate that needs to be passed when calling enrollForFingerprintAuthenticationWithDelegate:.

  • handleAuthorizationCallback: ==> handleAuthenticationCallback:

  • Fetching resources
    New methods have been introduced to fetch resources. The scopes attribute is no longer required in any of the fetchResource methods. Please follow the topic guide about fetching resources to update your implementation to the latest methods

  • logoutWithDelegate: ==> logoutUserWithDelegate:

  • enrollForMobileAuthentication:delegate: ==> enrollUserForMobileAuthenticationWithDelegate:
    For more information regarding the enrollUserForMobileAuthenticationWithDelegate: method implementation see the mobile authentication topic guide.

  • enrollForFingerprintAuthentication:delegate: ==> enrollForFingerprintAuthenticationWithDelegate:
    For more information regarding the enrollForFingerprintAuthenticationWithDelegate: method implementation see the biometric authentication topic guide.

  • unenrollForFingerprintAuthenticationWithDelegate: ==> disableFingerprintAuthentication

  • disconnectWithDelegate: ==> deregisterUser:delegate:
    For more information regarding the deregisterUser:delegate: method implementation see the user authentication topic guide.

  • **isClientRegistered ==> userProfiles In order to check whether a user is registered use the userProfiles method to get the profiles that are registered on this device.

OGEnrollmentHandlerDelegate

  • enrollmentInvalidClientCredentials ==> enrollmentErrorDeviceDeregistered

OGFingerprintDelegate

  • askCurrentPinForFingerprintAuthentication ==> askCurrentPinForFingerprintEnrollmentForUser:pinConfirmation:

  • fingerprintAuthenticationEnrollmentErrorTooManyPinFailures ==> fingerprintAuthenticationEnrollmentErrorUserDeregistered

OGResourceHandlerDelegate

  • resourceSuccess: ==> resourceResponse:body:requestId:
    We no longer distinguish between resource success or failure but always call the resourceResponse:body:requestId: method.

  • **resourceError ==> resourceResponse:body:requestId:
    We no longer distinguish between resource success or failure but always call the resourceResponse method.