Mobile SDKs revamped

The SDK mandates a minimum version of iOS 13.

loginWithPassword now takes either an email or a phoneNumber instead of a username as before.

We have introduced a new method called Provider.application(_:didFinishLaunchingWithOptions:) to call at startup to initialize the social providers.

We now require a new key called FacebookClientToken to configure Facebook Login.

The viewController parameter in Provider.login(scope:origin:viewController:) is now mandatory.

The viewController parameter in Provider.login(scope:origin:viewController:) must also conform to the protocol ASWebAuthenticationPresentationContextProviding when using WebViewProvider.

Some error messages may have changed.

Login using a webview: AppDelegate.reachfive().webviewLogin

WebViewProvider now uses ASWebAuthenticationSession instead of SFSafariViewController for improved security. The associated webview UI is different.

No need to ask again now to confirm app access for Facebook Login when a user still has a valid Access Token.

loginWithPassword calls /identity/v1/password/login now instead of /oauth/token.

Updated dependency Alamofire from 5.6.1 to 5.6.2.

Updated dependency BrightFutures from 8.1.0 to 8.2.0.

Updated dependency CryptoSwift from 1.3.8 to 1.5.1.

Updated dependency FBSDKCoreKit from 9.0.0 to 14.1.0.

Updated dependency FBSDKLoginKit from 9.0.0 to 14.1.0.

Updated dependency GoogleSignIn from 5.0.2 to 6.2.2.

Removed dependencies EllipticCurveKeyPair, KeychainAccess, PromiseKit, FacebookCore, FacebookLogin.

Client implementation has been broken down into smaller modules.

Client constructor no longer takes an Activity.

Client initialization now only fetches client configuration.

A separate initialization method (loadSocialProviders) has been added for social providers configuration.

The WebViewProvider social login flows now use a Custom Tab.

Internal login callback no longer opens a custom tab and now silently obtains an authorization code.

All errors are now communicated through the failure callback channel; Android Activity result codes no longer need to be manually inspected.

An ErrorCode enumeration class documents all ReachFive API and SDK errors.

The SuccessWithNoContent<Unit> type has been removed; all success callbacks now only use Success<T> or Success<Unit>.

loginWithWeb enables SDK integrators to delegate login to another ReachFive first-party identity client such as web page they control.

onLoginActivityResult handles all login flow results and automatically calls the appropriate internal completion flow. SDK integrators no longer have to match on request codes themselves. The method ignores any request code that does not concern the SDK.

SDK integrators can use ReachFive.resolveResultHandler to let the SDK automatically wire the appropriate activity result handler (i.e., onLoginActivityHandler or onAddNewWebAuthnDeviceResult).

onLoginWithWebAuthnResult : result is now automatically handled in onLoginActivityResult

onSignupWithWebAuthnResult : result is now automatically handled in onLoginActivityResult

Social login providers that did not support webviews are now fixed by virtue of using custom tabs.

Social login errors have been improved.

Activity callback methods no longer throw exceptions when the request code does not concern an SDK flow. Instead, no action is taken and a debug-level log is emitted.