WKWebView, and to support App to App authentication with banks that have implemented it.
Before you begin
- An iOS project in Xcode where you can integrate a
WKWebView. - Access to your website’s server to host the
apple-app-site-associationfile. - An Apple Developer account to create and use App IDs and provisioning profiles.
- A Meld API key and the ability to call
/bank-linking/connect/startto obtain a widget URL.
Project Setup
Step 1: Universal Links Setup
Universal Links provide a seamless user experience by connecting a URL to a specific part of your iOS app, bypassing the browser. This guide is designed for beginners and explains how to set up and use Universal Links in your iOS applications.Universal Links Step 1: Enable Associated Domains
- Create App ID: Log into the Apple Developer Portal, go to “Certificates, Identifiers & Profiles,” and create a new App ID for your project. Ensure that you enable “Associated Domains”.
- Update Xcode Project: In Xcode, open your project settings, select your target, and go to the “Signing & Capabilities” tab. Add the “Associated Domains” capability by clicking the “+” icon and selecting it from the list.
Universal Links Step 2: Configure Your Website
- Create Apple-App-Site-Association File: You need to create a JSON file named apple-app-site-association (without any file extension) and host it at the root of your HTTPS-enabled web server or in the .well-known
subdirectory. The content should look like this:
JSON
- Replace TEAMID.BUNDLEID in the above code with your actual team ID and bundle identifier. The paths array should contain the URLs you want to link to your app.
- Host the File: Ensure the apple-app-site-association file is accessible via HTTPS without any redirects at https://
<yourdomain>.com/apple-app-site-association.
Universal Links Step 3: Configure Associated Domains in Xcode
- Modify Entitlements: In your Xcode project, under the “Associated Domains” capability you added earlier, add an entry: applinks:
<yourdomain.com>
Universal Links Step 4: Handle Universal Links in Your App
- Update AppDelegate: Open AppDelegate.swift and implement the following
function to handle incoming universal links:
Swift
Universal Links Step 5: Test Your Universal Links
- Prepare Your Device: To test on a real device, ensure the device has the provisioning profile that includes the Associated Domains capability.
- Test the Link: Send yourself an email or message with the link you configured earlier (e.g., https://
<yourdomain>.com/path/to/content). Tap the link on your device, and it should open your app directly, bypassing the browser.
Troubleshooting Tips
- Verify Your AASA File: Use online tools like Apple’s AASA validator to ensure your apple-app-site-association file is correctly configured and accessible.
- Check Console Logs: If the universal link is not working, check the device’s console logs for any errors related to universal links or associated domains.
Step 2: WKWebview Setup
WKWebview Step 1: Adding to View Controller
- Start by setting up a standard Xcode project and add a WKWebView to your ViewController. Ensure you configure the WKWebView’s javaScriptCanOpenWindowsAutomatically setting to true.
Swift
WKWebview Step 2: Load the Widget URL
- After adding the WKWebView to your ViewController as described in the previous step, load the Widget URL, which you can obtain from the connect/start API. Once the Widget URL is successfully loaded into the WebView, it will display the bank picker interface. Ensure proper error handling and network checks are in place to manage the loading process smoothly.
WKWebview Step 3: Updating the Code
- Add the following code:
WKWebview Step 4: Manage Navigation Requests
- To capture and address specific use-cases for specific service providers, developers need to manage all navigation requests within the WKWebView. This requires implementing the WKNavigationDelegate protocol, which provides methods to track and control the loading of web content. A crucial method to implement is webView(_:decidePolicyFor:decisionHandler:). This method determines whether a navigation request should proceed, be canceled, or handled differently based on the request’s characteristics.
Provider Specific Code
Depending on which provider(s) your app uses, you will have to configure some provider specific code in order to make app to app authentication work. This section details what that code is.MX
- This code needed since MX uses the custom URL schema and relies on loading the content inside the MX widget. It also extracts the url parts and loads inside the MX widget and decision handler cancels the navigating requests.
- handleOauthRedirect handles the APP to APP or APP to web passing
- The web view loaded in the case of MX is handled as follows in webView(_:decidePolicyFor:decisionHandler:):
Plaid and Finicity
- To manage HTTPS requests from Plaid and Finicity, handle the navigation within the webView(_:decidePolicyFor:decisionHandler:) method of the WKNavigationDelegate. Use the decision handler to allow navigation when these requests occur, enabling the WKWebView to securely load the relevant webpage.
- Plaid specific: Upon completing the Plaid process, it is essential to pass the oauth_state_id to the Meld backend. This should be done along with the initial URL that was saved earlier in the process. This specific code block is only for Plaid, and does not need to be implemented for Finicity.
Listening to Front End Events
- This section applies to all service providers. Handle the UI requests so that app to web request can be handled internally.
- Meld emits events to inform the status of the handshake.intercept.