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: .externalApp)
    ]
)

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 two 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.

FacebookProvider(
    variant: "ios", (1)
    prefersLoginTracking: .limited (2)
)
1 Available from Reach5Facebook 7.1.0.
2 Available from Reach5Facebook 7.2.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 (one of .facebook, .google, .line, .bconnect), an optional variant, and a mode controlling how the session’s redirection reaches the app:

  • .sdkScheme (default): custom scheme, works on all supported iOS versions.

  • .externalApp: out-of-band — the flow ends in an external app (e.g. a banking app) that reopens yours via a universal link, forwarded to ReachFive through application(_:continue:restorationHandler:). Requires the applinks: Associated Domain.

  • .universalLink (iOS 17.4+): in-band — the universal-link redirect is intercepted directly inside the authentication sheet. Requires the webcredentials: Associated Domain.

See the "Associated Domains" section of Getting Started for the entitlement setup.

WebProvider(name: .bconnect, variant: "natif", mode: .externalApp)
A provider configured on your client with no matching entry in providersCreators still logs in, falling back to .sdkScheme automatically. Add an explicit WebProvider only when you need .externalApp/.universalLink, or a specific variant.
Integrating a universal-link provider? See the universal-link checklist.
To implement your own provider (native SDK, custom flow) instead, see Implement a custom provider.

Some web providers finish login on an https universal link instead of the custom scheme. Use the checklist for your WebProvider mode; you do not need a custom provider unless none of the built-in options fit.

  • .externalApp

  • .universalLink (iOS 17.4+)

Login may hand off to an external app (e.g. a banking app) that reopens yours via a universal link.

Do not use loadLoginWebview: the callback is delivered through application(_:continue:), not an embedded webview.

If iOS terminates your app while the user is in the external app, the in-flight login is lost and must be restarted (see application(_:continue:restorationHandler:)).

This is the same flow as the default custom-scheme login, but the OAuth redirect_uri is the provider’s https:// universal link and the authentication sheet intercepts it in-band meaning no external-app handoff.

  • Configure the provider and variant on your ReachFive Console.

  • Whitelist the provider’s universalLink URL in Allowed Callback URLs (see Clients).

  • Register a WebProvider with mode: .universalLink in ReachFive(providersCreators:) (iOS 17.4+).

  • Initialize the SDK so provider configurations are fetched and getProvider can resolve your provider (see applicationDidFinishLaunchingWithOptions(_:)).

  • Add webcredentials:${host} to Associated Domains and the matching webcredentials section in apple-app-site-association (see apple-app-site-association).

  • Call getProvider(name:).login(…​) with a Presentation built from a UIViewController attached to a window; see getProvider for details.

No application(_:continue:) wiring is required for login completion; the ASWebAuthenticationSession completes inside the sheet.

Do not use loadLoginWebview: use WebProvider or webviewLogin with a secure session instead of an embedded webview.

None of these fit your case? See Implement a custom provider to implement your own.
R5 AI Assistant

Confirm Deletion