providerCreator

providerCreator is a protocol that defines specific social login providers (e.g., Google, Facebook, Apple) available in our iOS SDK. These specific providers use native calls or external libraries to authenticate users.

All providers except Apple that you configure in the ReachFive Console for which you don’t use a specific provider creator will authenticate through an ASWebAuthenticationSession.

You should define and configure these providers when you configure the iOS SDK.

Examples

static let reachfive: ReachFive = ReachFive(
    sdkConfig: sdkRemote,
    providersCreators: [
        GoogleProvider(),
        FacebookProvider(),
        AppleProvider(variant: "ios_native"),
        WeChat(),
        WebProvider(name: .bconnect, variant: "natif", mode: .customScheme)
    ]
)

Available provider creators

The providers who have a variant parameter have the following algorithm to choose a variant configured on the console.

  • If a variant is provided, the variant with the exact name, irrespective of case, is chosen. If no variant matches, the algorithm chooses the variant as if no variant was provided.

  • If no variant is provided, the first variant containing ios in its name, irrespective of case, if any, is chosen. Otherwise, the default variant is chosen.

Name Description

GoogleProvider

The object for configuring Google native provider for our iOS SDK.

Optionally takes a variant parameter.

GoogleProvider(variant: "native") (1)
1 Available from Reach5Google 7.1.0.

FacebookProvider

The object for configuring Facebook native provider for our iOS SDK.

This provider takes three optional parameters:

  • variant string: the provider variant to use.

  • prefersLoginTracking FBSDKLoginKit.LoginTracking: Indicates preference to the Facebook SDK for the limited or classic login. Facebook SDK is ultimately responsible for the decision.

  • appSwitch FBSDKLoginKit.AppSwitch: whether the login may open the native Facebook app instead of a Safari view controller. Defaults to .enabled; pass .disabled to always use the browser flow. It only takes effect when your Info.plist declares the fbauth2 scheme and Meta has enabled Fast App Switch for your Facebook application. See Fast App Switch.

FacebookProvider(
    variant: "ios", (1)
    prefersLoginTracking: .enabled, (2)
    appSwitch: .enabled (3)
)
1 Available from Reach5Facebook 7.1.0.
2 Available from Reach5Facebook 7.2.0.
3 Available from Reach5Facebook 9.0.0.

AppleProvider

Optionally takes a variant parameter.

Not specifying AppleProvider at all in the providerCreators array is equivalent to specifying AppleProvider with no variant. 
AppleProvider(variant: "native") (1)
1 Available from ReachFive 7.1.3.

WeChat

The object for configuring WeChat Connect for our iOS SDK.

WeChat() (1)
1 WeChat takes no parameters.

WebProvider

The object for configuring a web-only provider — one with no native SDK component, authenticated entirely through an ASWebAuthenticationSession.

Takes a name, an optional variant, and a mode controlling how the session’s redirection reaches the app:

  • .customScheme (default): the SDK’s custom scheme. Covers a redirect intercepted inside the sheet and one delivered to application(_:open:options) when a provider hands the flow off to their own native app.

  • .universalLink (iOS 17.4+): the universal-link redirect is intercepted directly inside the authentication sheet. Requires the webcredentials: Associated Domain and a universalLink on the provider’s backend configuration. See guides/apple-app-site-association.adoc#webcredentials.

WebProvider(name: .bconnect, variant: "natif", mode: .customScheme)
A provider configured on your client with no matching entry in providersCreators still logs in, falling back to .customScheme automatically. Add an explicit WebProvider only when you need .universalLink, or a specific variant.

Integrating a .universalLink provider? See .universalLink instead.

To implement your own provider (native SDK, custom flow) instead, see Implement a custom provider.

Use this only when the OAuth redirect_uri must be the provider’s https universalLink, intercepted inside the authentication sheet. This mode cannot complete a login that leaves the app for a third-party app. There is no fallback below iOS 17.4: login() fails with a TechnicalError if the OS is too old or the provider has no universalLink in its backend configuration.

None of these fit your case? See Implement a custom provider to implement your own.
R5 AI Assistant
The R5 AI assistant can make mistakes, verify answers.

Confirm Deletion