Branch.io parameters missing when appended to an existing link

Question

I am trying to make it so a user clicks a Branch.io link in the form https://a.test-app.link/identifier?foo=bar and then be redirected to the AppStore to download the app. The app should then be able to grab the foo parameter during launch.

To debug this I have followed this procedure:

1. Create the link under the test environment.
2. Tap the link on the device.
3. Install app with Xcode.

4. Launch the app and read the parameters during launch with

   let branch = Branch.getTestInstance()
   branch.setDebug()
   branch.initSessionWithLaunchOptions(launchOptions, andRegisterDeepLinkHandler: { params, error in
       if error == nil {
           // params are the deep linked params associated with the link that the user clicked -> was re-directed to this app
           // params will be empty if no data found
           print(params)
       }
   })
   

I have also set the correct API tokens in the info.plist file.

From what I understand, I should be getting by now my foo parameter within the params dictionary, but this is not happening. The only way to get parameters to work is by adding static ones using the dashboard. Furthermore, I'm even getting old parameters in the params dictionary that I have already removed from the dashboard, but no sign of the URL query parameters.

Does anyone have an idea of what I'm doing wrong?

Thanks

Answer 1

We have an update and a probable cause, and this ended up being much more interesting than expected!

TL;DR: passing link data as a query string parameters works for both app.link and test-app.link. The real cause behind these symptoms is something else, but would never be encountered by a normal user.

Symptoms

Link parameters appended to an existing Branch link (for example: https://bnpo.app.link/identifier?foo=bar) do not reliably show up inside the app.

Cause

It turns out that at some point, Apple changed the behavior of mobile Safari so that when you enter a URL that is also in your history, Safari actually preloads the page as you type. To the Branch servers, this looks exactly the same a regular visit, so we create device fingerprints for each one of these 'visits'. You can actually see this in action by going to the Link Clicks page on your Branch dashboard, entering the URL for a Branch that you have visited before into the Safari address bar, and then watching all the link 'clicks' roll in.

The problem is the Branch SDK consumes device fingerprints sequentially from oldest to newest. If you have previously visited https://bnpo.app.link/identifier while testing, and then re-enter that URL with an appended query parameter (https://bnpo.app.link/identifier?foo=bar), Safari has already loaded https://bnpo.app.link/identifier before you even have a chance to type in ?foo=bar.

This means your device now has two different fingerprints outstanding:

1. One for https://bnpo.app.link/identifier
2. Another for https://bnpo.app.link/identifier?foo=bar

Even though you press Go to trigger the launch of the app with the URL https://bnpo.app.link/identifier?foo=bar, the fingerprint for https://bnpo.app.link/identifier already exists, and is consumed first within the app because it is a older (by a second or two, depending on how fast you type).

If you then exit the app and launch it again immediately, you'll get the next fingerprint with the extra parameter.

Solution

This is a situation that would come up fairly easily during testing, but that real-life users are almost never going to encounter. It only occurs when manually typing in a URL that has already been visited, and then appending additional query parameters to it.

For testing purposes, simply relaunch your app repeatedly until you get no data (+clicked_branch_link: 0) from the Branch init() call during launch (to use up any outstanding fingerprints), and then either...

1. Type out your URL in full using Notes and paste it into Safari
2. Just open the URL from inside Notes

We'll add a cautionary note summarizing the above in our documentation. Thanks for bringing it to our attention!