Deferred Deep Linking in iOS

Question

We\'re trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many

Answer 1

My answer from HERE

Apple no longer supports Deep Links. It is now called Universal Links and works a bit differently.

Source

Now that Apple no longer supports URI schemes for deep linking, developers must implement Universal Links in order to deep link properly on iOS. If you are already using URI schemes, check out our blog on transitioning to Universal Links.

From: HERE

And HERE is another article on Universal Links and what they are.

Answer 2

We've successfully used the clipboard (NSPasteboard) to achieve this: the web page that processes the redirect to the app store does a paste to the mobile device's clipboard before letting the user download the app. Once the app is installed, it uses NSPasteboard on first launch to check for an appropriately coded string. This string can contain the text of interest or, more securely, a token used to fetch interesting data from the backend. In Objective C:

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;

The clipboard can be cleared once the app is done with it, to avoid repeating the same action.

Answer 3

There is a good solution here: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

Basic workflow:

• User selects domain link on web.
• Link sets referral ID to cookie.
• User redirected to app store.
• On app launch, load referral page in SFSafariViewController.
• Referral page checks for cookie and if it exists calls a deeplink into the app with the referral ID.

Answer 4

We have also attempted to do this ourselves and I will try to break down the different steps here.

Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).

Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.

The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.

The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.

Here is a summary of the steps:

1. User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
2. User 2 visit Web Page P
3. P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
4. User 2 goes to the app store and downloads your App A
5. User 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
6. S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.

Hope this help!

Edit 04/24:

Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.

Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.

Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.

It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.

During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.

Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.