Not surprisingly, this abundant range of products selection attracts more and more users to visit the site each month and make a purchase. While the overall traffic from all platforms exceeded 500 million sessions, the vast majority of visits came from mobile – with mobile app and mobile web representing 78% and 13% respectively of the total visits. In terms of purchasing behavior, the native mobile app converted six times better than mobile web and hence it was imperative to find ways to nudge the user from the mobile web to the native app.

“It’s much easier to develop campaigns and create new banner designs without requiring lengthy development cycles, and we track key metrics including events related to app downloads and use,” Bukalapak Product Manager Bayu Adi Persada added.

In particular, Bukalapak’s goals were to:

• Promote awareness of the Bukalapak mobile app,
• Drive app installs and usage,
• Increase in-app conversions and the lifetime value (LTV) of the customers and,
• Improve user engagement and retention

To meet its goal, Bukalapak tried displaying an interstitial banner to users after they purchased on mobile web, but it negatively impacted their SEO. They also placed an app download link at the top of their navigation bar, but the average number of daily downloads only amounted to 400-500. In addition, the web engineers were spending time on building and optimizing these solutions in-house.

After a few attempts, they looked to Google for “how to increase traffic to mobile app from mobile web,” which led them to Branch’s Journeys Web to App Conversion product.

Tuning up the Journeys performance

After selecting and implementing Branch’s Journeys solution, Bukalapak saw an immediate increase in installs, but it took some testing and fine tuning before things really took off.

At first, Bukalapak put a very simple banner at the top of the screen without any filter, and then also used a simple button just like the one Airbnb has – the one that appears in the first time user visits the web.

However, these approaches only increased the overall app downloads by hundreds – barely reaching the target. After referencing related articles and working with a dedicated team of experts at Branch, they changed the approach by running multiple campaigns at once and targeted the same segment of users with multiple forms of banners. Here is a part of strategy that Bukalapak used:

1. First time mobile web visitor: show a simple smart banner or a floating button banner
2. Second time mobile web visitor: show a half screen banner promoting the chat in app feature.
3. Third time mobile web visitor: show a full-screen interstitial with an offer to complete purchase in-app.

Of course, at every stage the user’s preferences were paramount and no banner was shown to the user for 2 weeks if the use dismissed the banner even once. It ensured that the banners were not intrusive.

And, that’s when the magic happened.

The Results

So far, the number of app downloads has catapulted by six times and the team believes that there is still room for improvement.

In the first few months after implementation and testing, this is what Bukalapak achieved.:

• Average daily clicks rate increased 47x
• Average daily app download increased 5x
• Users acquired by Journeys are 2x more likely to convert/transaction compared to our global benchmark.

The post How Bukalapak drove a 5x increase in daily app installs appeared first on Branch.

PregBuddy is an integrated health and wellness platform supporting women during their pregnancies. They offer personalized healthcare via peer support, organized information, expert access for nutrition, fitness and emotional advice and affordable access to essential products and services through their journey. PregBuddy has seen an early traction of over 35,000 users, and has been growing organically by 20%, month-over-month. The majority of our users are first-time moms, living in nuclear families who find PregBuddy application very useful like a companion throughout her journey. We caught up with the team behind PregBuddy to learn more about how it has used Branch to capitalize on mobile growth.

The Problems We Needed to Solve

We wanted to find technical solutions for two key pieces of functionality:

1. Building a guest view of the articles inside our Android app

Expectant mothers want to share articles from PregBuddy with their better half, so that both can read and stay informed. The challenge was in the early days, we didn’t have a mobile website. Hence our articles were present only on the app, behind an authentication layer. This meant the father-to-be either had to log in or sign up on our app to read that article. There is a lot of friction when anyone who is not pregnant is asked to sign up on a pregnancy platform, so we wanted to make that experience smooth and seamless for both future parents.

2. Bringing users from Facebook Messenger to Android app

We allow any expectant mom to interact with PregBuddy via our Facebook Messenger bot. Our bot is capable of answering certain questions and showing relevant article snippets based on her current week of pregnancy. To read the entire article, we could show a mobile web view within the Messenger app itself, but we didn’t have one at that time. We wanted to make sure an expectant mom could read any number of articles by seamlessly transitioning from the bot to our Android app, without even signing up.

Solutions We Considered

In the beginning, we were planning to generate our own deep links and handle deferred deep linking using a custom system. When we looked at the solution Branch was offering and how easy it was, we decided to go ahead with it for faster go-to-market. Although it was a very new feature at the time, we also used Branch to index all the generated URLs automatically, thus helping us build our search engine optimization. We implemented our app indexing via Branch because Google’s App Indexing system required us to have weblinks, but we were app-only at that time.

How We Built It With Branch

Within our native app, we allowed users to share article links with friends/family via any medium. These article links were generated using the Branch SDK. Upon clicking a link, the receiver was able to preview the entire article, and could download the app to read more concent. After downloading, Branch would be automatically deep linked the receiver to the article that was shared, allowing them to read the entire article without signing up first.

We used a similar flow for our Messenger bot. Expectant moms were shown article snippets based on their requested topics. We used Facebook Messenger’s built in Carousel structure to display articles that the user could choose from. Each article had an associated Branch URL, which was set as the appropriate attribute in the carousel structure as follows:

params = {
  "access_token": BOT_ACCESS_TOKEN
}
headers = {
  "Content-Type": "application/json"
}
data = json.dumps({
  "recipient":
  {
    "id": recipient_id
  },
  "message":
  {
    "attachment":
    {
      "type":"template",
      "payload":
      {
        "template_type": "generic",
        "elements":
        [
          {
            "title": article_title1,
            "item_url": branch_url1,
            "image_url": img_url1,
            "subtitle": article_description1,
            "buttons":[
              {
                "type": "web_url",
                "url": branch_url1,
                "title": "Read more"
              }
            ]
          },
          {
            "title": article_title2,
            "item_url": branch_url2,
            "image_url": img_url2,
            "subtitle": article_description2,
            "buttons":[
              {
                "type": "web_url",
                "url": branch_url2,
                "title": "Read more"
              }
            ]
          },
          {
            "title": article_title3,
            "item_url": branch_url3,
            "image_url": img_url3,
            "subtitle": article_description3,
            "buttons":[
              {
                "type": "web_url",
                "url": branch_url3,
                "title": "Read more"
              }
            ]
          }
        ]
      }
    }
  }
})

# send the carousel message to the user
r = requests.post("https://graph.facebook.com/v2.6/me/messages", params=params, headers=headers, data=data)

Upon clicking or tapping a carousel item to read the entire article, users were redirected to the Play Store to install the app. After installation, they were taken directly to read the entire article without needing to register or sign in. We accomplished this by checking for the {code}articleId{code}, which is a referring parameter in our Branch links. If this parameter existed, we would show the corresponding article. If not, we would continue with our standard onboarding experience.

// check if it is an Auto Deep Link Launch
if(Branch.isAutoDeepLinkLaunch(this)) {
   String articleId =
       Branch.getInstance().getLatestReferringParams().getString("article_id");
  mArticle = DBHelper.getArticle(articleId);
} else {
// get the article from intent
   mArticle = getIntent().getParcelableExtra("article");
}

Creating Branch links to share articles is equally easy. We simply build a BranchUniversalObject, and then use it to generate a URL and list for Google App Indexing:

// create a BranchUniversalObject
branchUniversalObject =
   new BranchUniversalObject().setCanonicalIdentifier("article/" + articleId)
       .setCanonicalUrl("https://get.pregbuddy.com/article/" + articleId)
       .setTitle(title)
       .setContentDescription(description)
       .setContentIndexingMode(BranchUniversalObject.CONTENT_INDEX_MODE.PUBLIC)
       .addContentMetadata("article_id", articleId);

// call list on Google Search to add the item to the index
branchUniversalObject.userCompletedAction(BranchEvent.VIEW);
branchUniversalObject.listOnGoogleSearch(mCtx);

// call list on Google Search to add the item to the index
LinkProperties linkProperties = new LinkProperties().setChannel("facebook")
   .setFeature("sharing");
branchUniversalObject.generateShortUrl(mCtx, linkProperties,
   new Branch.BranchLinkCreateListener() {
       @Override public void onLinkCreate(String url, BranchError error) {
        mUrl = url;
           // handle on success link create
       }  });

Results

In the month after our Branch integration went live, we saw an increase in our organic installs of over 10%, as users were getting redirected from our Facebook messenger bot. We also noticed the total number of articles shared had gone up by 40% and the number of shares per user had increased by 1.3x. To verify these results, we reached out to our users who shared our articles with their partners, and they told us they liked the seamlessness with which they were able to share content between each other, without any discomfort.

Conclusion

Branch links helped us build a seamless integration between our Messenger bot and our Android application. By using Branch, PregBuddy has made it easier for thousands of expectant mothers to keep themselves informed, and share their journeys with their partners.

The post How PregBuddy Used Branch to Link Between Messenger Bot and Android App appeared first on Branch.

What are App Links?

In the mobile deep linking world, the term “App Links” can refer to either Android App Links or Facebook App Links. These are completely different concepts, so let’s look at what both of these are in detail:

Android App Links:

Android App Links are only available on Android Marshmallow (6.0) and upwards. They are HTTP URLs that can be used to link to content inside a native app if it is installed on the device.

For example, you have the URL https://example.com/product/red-shoes and the same content is also available on your native app. If the user clicks this link on an Android device and App Links are properly configured, the link will open the content on the native app if it’s installed, but would otherwise open the URL in the browser. This is a great experience for your user who has already invested in downloading the app and deserves a better native experience.

Android App Links are essentially identical to Universal Links on iOS, and have the same two major limitations:

• You must have a functional mobile website to fall back gracefully if the user does not have the app
• There are no built-in deferred deep linking capabilities.

To get started with Android App Links, you need to set up intent filters, add code to handle the incoming URLs, and make an association between your website and your app. Here is a great guide on how to set up Android App Links.

Also, keep in mind that you cannot depend completely on Android App Links for deep linking, especially if you support Android versions below 6.0. You’ll also need to implement URI schemes and Chrome Intents.

Facebook App Links:

First things first, Facebook App Links are not actually links. They are HTML meta tags on your web page, which the native Facebook clients scrape when a link to that page is shared. If the App Links meta tags are correctly configured, the behavior will be as follows:

1. Open the app directly if it is installed on the device.
2. Open the mobile website or the App/Play Store if app is not installed.

Here is an example of a page with Facebook App Links meta tags:

<html prefix="og: https://ogp.me/ns#">
<head>
  <title>The Rock (1996)</title>
  
  <meta property="og:title" content="The Rock" />
  <meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />
  
  <meta property="al:ios:app_store_id" content="342792525" />
  <meta property="al:ios:url" content="imdb://title/tt0117500" />
  <meta property="al:ios:app_name" content="IMDb Movies & TV" />
  
  <meta property="al:android:package" content="com.imdb.mobile" />
  <meta property="al:android:url" content="imdb://title/tt0117500" />
  <meta property="al:android:app_name" content="IMDb Movies & TV" />
 
...
</head>
...
</html>

The pain with Facebook App Links is that it seems Facebook has completely stopped supporting them on iOS without any public acknowledgement. This gives a pretty bad experience to users and causes frustration for app developers who follow Facebook’s official documentation (which has been broken since late 2015).

On iOS, the best workaround is to open a web preview of your app’s content (such as Branch’s free Deepviews or Journeys), and then display a call-to-action button that will successfully launch your app. On Android, you can still successfully use App Links to deep link the user into your app, but only from Facebook’s apps. You can learn more in our post about escaping the limitations of Facebook App Links with Branch Universal Links, or by requesting a Branch demo. 

Summary

It’s useful to learn about the underlying technologies of mobile deep linking, but in today’s world, no savvy developer should have to spend time implementing these standards alone. Hosted deep link platforms like Branch allow the technical details to be abstracted away, leaving reliable deep links that work everywhere.

The post What are App Links? appeared first on Branch.

However, one critical aspect of providing a great mobile app user experience is deep linking. Android and iOS each implement deep links differently, and hybrid app toolkits do not cover all the complications of setting up this important functionality on both platforms.

Two of the most important deep linking standards are Universal Links on iOS and App Links on Android. Universal Links were introduced by Apple in iOS 9 and have since been the only effective way of deep linking the user to the app if it is installed. Android App Links were introduced in Android 6.0 and work more or less in a similar fashion to Universal Links. You can read more about Universal Links here and App Links here.

Option 1: Manual Configuration

One way to enable deep links on both the platforms is to manually configure Universal Links using Xcode and App Links using Android Studio. But that will surely work against the goal of code consolidation, as you’d need to replicate deep link handling for each platform.

Option 2: Plugins

Some hybrid environments have plugins to automate deep linking configuration. However, even when these plugins work (they are often unsupported and out of date), they come with major caveats:

1. 1. You will need to manage and host your own AASA file for iOS.
   2. You will need to manage and host your own AssetLinks.json file for Android.
   3. Standalone plugins cannot support Deferred Deep Linking (deep links that work even if the app isn’t installed).
   4. Standalone plugins cannot give you analytics and attribution for your traffic, which is critical if you are trying to grow your app.

Option 3: Hosted Deep Links

Fortunately, there is a third option: hosted deep links from a platform like Branch. Branch supports all of the top hybrid app environments, meaning you can have both Universal Links and App Links configured with a simple setup that takes just a few minutes. In addition, you’ll get support for deferred deep linking, analytics for your traffic, and free support from real engineers. All you need to do is add the Branch SDK for your platform to your project, complete a few one-time configuration steps, and Branch will automatically take care of all the rest.

Branch is the quickest, easiest, most reliable way to configure deep linking in your app. Get started today!

The post Universal Links and App Links for Cordova, Ionic, Xamarin, React Native, Unity, Titanium, and more! appeared first on Branch.

Troubleshooting Universal Links

Universal Links can be tricky. So let’s do a quick diagnostic test on your setup:

1. Check if your applinks are registered with iOS as Universal Links:

Paste the link on the Notes app and long press it. If you see an option to Open in <<App Name>>, then it suggests that Universal Links were disabled for your domain name. Use the Open in <<App Name>> option to open the app. This will re-enable Universal Links for your domain. If you don’t see the option to Open in <<App Name>>, then it suggests that there is some error with the association that iOS makes between the domain and the app.

2. Check AASA file:

You need to first check if your AASA file is hosted on your domain and is getting served properly. If you are using Branch Universal Links, this step is not required as Branch takes care of serving a valid AASA file. However, if you are using your own hosted AASA file, you can use AASA file validator found here.

If your AASA file looks good, try to delete and reinstall the app. This will prompt iOS to re-scrape the AASA file. Then check whether applinks are registered with iOS using the steps from Step 1.

3. Check Associated Domains entry in your entitlements file:

Go to the Capabilities tab of your project file in Xcode and scroll down to Associated Domains. Ensure that associated domains are added in the form:applinks:<<yourdomainname>>*Note that this domain name needs to be the one where your AASA file is hosted.

If you see an error while adding the associated domains, please ensure that the right team is selected for your Xcode project and that the Bundle Identifier of your Xcode project matches the one used to register the App Identifier with Apple.

If there was an error with either of the above settings, please rectify that, delete the app on the test device, deploy a new build and test with steps in Step 1.

Some other things to keep an eye out for when dealing with Universal Links:

Universal links can be disabled

Yes, Universal Links can get disabled. When the user is deep-linked into an app via a Universal Link, iOS display a forward arrow button to the domain name at the top right of the screen. If the user inadvertently taps that, iOS will disable Universal Links for that domain-app pair. To re-enable Universal Links, user would have to long tap the link and select Open in <<appname>> option as detailed out in troubleshooting Step 1 above.

Universal Links do not work on Javascript redirects

For better or for worse, you cannot redirect to a link and expect it to open the app on iOS. Universal Links are designed to work on user intent and will not deep link if wrapped inside another domain that redirects to the associated domain.

Many apps don’t support Universal Links.

Universal Links are not yet supported on a lot of apps. If you are clicking the link from say Instagram, Twitter or Facebook, don’t expect the link to directly open your app. However, they do work from apps like Notes, iMessage, Slack, Whatsapp etc. Here is a detailed list that we continually update, along with info for how you can make them work on some unsupported apps.

If you are using Branch Universal Links, our integrations team, which gets tons of queries around Universal Links, has built a tool to validate Universal Links in your Xcode project. It can be found here and is pretty nifty when it comes to troubleshooting Universal Links.

If you aren’t using Branch Universal Links, now’s as good a time as any to request a Branch demo or to get started!

The post 3 Steps to Troubleshoot iOS 9 and iOS 10 Universal Links appeared first on Branch.

The AASA (short for apple-app-site-association) is a file that lives on your website and associates your website domain with your native app. In other words, it’s a safe way to prove domain ownership to iOS. With URI schemes, which were the standard way for opening apps on iOS until iOS 9, app developers could register any URI scheme of their liking and iOS, without any verification, would respond to those URI schemes by opening apps. For example, if an indie developer registers the fb:// URI scheme for a test app, there was nothing to stop that, even thoughfb:// is used by the Facebook native app. The AASA file makes Universal Links unique and secure because there is no way for an indie developer to host an AASA file on the facebook.com domain.

Let’s look at some basics of the apple-app-site-association file that will help you in building and hosting one on your domain.

The AASA file contains a JSON object with a list of apps and the URL paths on the domain that should be included or excluded as Universal Links. Here is a sample AASA file:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "3XXXXX9M83.io.branch-labs.Branchster",
        "paths": [ "NOT /e/*", "*", "/", “/archives/201?/* ]
      }
    ]
  }
}

In the AASA JSON, each app specific domain contains a dictionary of appID and paths. Let’s look at what each key in the AASA JSON object is:

• applinks: Since the AASA file can also serve other purposes (for example, Shared Web Credentials), the applinks object defines the section of the file used by Universal Links.
• apps: The apps array must be present, but will always be empty.
• appID: Built by combining your app’s Team ID* (or the Apple App Prefix) and the Bundle Identifier**. In the example above, 3XXXXX9M83 is the Team ID and io.branch-labs.Branchster is the Bundle ID.
• paths: Array of strings that specify which paths are included or excluded from association. You can use NOT (before the path – as in the example JSON above) to disable paths. In this case, all the links on this path will go to the web instead of opening the app. You can use * as a wildcard to enable all paths in a directory and ? to match a single character (/archives/201?/ example in the sample JSON). Please note that these strings are case sensitive and that query strings and fragment identifiers are ignored.

* Don’t know what your Team ID is? Head over to https://developer.apple.com/account and retrieve it from the Membership section.

** To retrieve the Bundle ID, head over to your Xcode project, select project and then the ‘General’ tab.

Hosting the AASA File on Your Domain

Once you are ready with your AASA file, you can now host it on your domain either at https://<<yourdomain>>/apple-app-site-association or at https://<<yourdomain>>/.well-known/apple-app-site-association.

While hosting the AASA file, please ensure that the AASA file:

• Is served over HTTPS.
• Uses application/json MIME type.
• Does not have an appended .json to the apple-app-site-association file name.
• Has a size not exceeding 128 Kb (requirement in iOS 9.3.1 onwards).

Supporting Multiple Apps on the Same Domain

You can support multiple apps on the same domain. To do that, you’d need to add a new appID, path dictionary to the details array in the AASA file to look something like this:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "3XXXXX9M83.io.branch-labs.Branchster",
        "paths": [ "NOT /e/*", "*", "/", “/archives/201?/* ]
      },
      {
         "appID": "3ZZZZZ9M94.io.branch-test.Branch",
         "paths": [ "NOT /e/*", "*", "/", “/archives/200?/* ]
      }
    ]
  }
}

If two or more apps associate with the same content path on the website then the order of the appID, paths dictionary in the details array will determine which app will get precedence.

Supporting Multiple Domains for the Same App

Each domain that the app needs to support has to have its own apple-app-site-association file. If the content served by domains is different, then the contents of the file will also be different to support the respective paths. Otherwise, the same AASA file can be used but it needs to be accessible on every supported domain. Also note that even though example.com and www.example.com might be serving the same content, you need to ensure that the AASA file is hosted on both these domains.

At Branch, we live and breathe deep links and have created an AASA validator to help you build your valid AASA file. You can find it here: https://branch.io/resources/aasa-validator/.

If you are using Branch links, you can bypass all the steps of building, validating, hosting and managing an AASA file by checking a single box on the Branch dashboard. We take care of all everything else under the hood for you.

If you aren’t using Branch links, now’s the time to request a Branch demo!

The post What Is An AASA (apple-app-site-association) File? appeared first on Branch.

Fynd, an online fashion discovery and eCommerce store, had already built a great user experience and gained almost 100k app downloads in a short time period and they decided to leverage their existing user base to bring them the next 100k users. Coupled with lucrative brand sales on its platform, Fynd introduced a refer and earn scheme for its app users. For every new referral, the referring and referred user would get INR 200 cashback that they could use on the platform for future purchases. The results of this well-crafted referral program were extremely rewarding.

Within a period of 30 days, Fynd organically acquired the next 900k app users and brought their cost of acquiring (CAC) down tremendously. To add to that, the percentage of users who were acquired via the referral program and completed a purchase, was 2x that of users acquired via inorganic/paid channels. Because of this, the cost per user, one of the most important metrics for eCommerce companies, was significantly reduced.

One key element of Fynd’s in-app referral program was the personalized onboarding for new users. By using deep links that ensured that the first screen that a new user sees after downloading and installing the app is customized to their journey (i.e the referral link the user was coming in from). It also removed the hassles of using referral codes as it was embedded in the referral deep link, taking away the barrier of finding and adding referral codes. Similarly, inviting friends to download the app was made easier using referral links that worked seamlessly across all channels.

“At the center of any good referral program is a seamless user experience that is highly contextual and that helps new users unlock platform’s value as quickly as possible.”

-Ronak Modi, Product Growth Manager at Fynd

Users could see the referral scheme up front on the home feed. The messaging and call-to-action was clear.

Having successfully built a virality engine in-app, Fynd is now working to re-introduce the referral program in the next season of brand sales and to increase web to app conversion organically by meaningfully nudging the mobile web users to the mobile app.

It’s important to remember, that early on in the mobile growth journey, it’s imperative that content sharing and referrals are built into the DNA of the app experience to organically increase app downloads and acquire high-quality users.

The post 100k to 1 Million: How Fynd Increased Their App Downloads in a Single Month appeared first on Branch.

Here’s a quick rundown of how deep linking in iOS, critical to Apple’s strategy on mobile search, has changed over the past 10 months.

iOS 9.0 – Introduction of Universal Links

In June 2015 at the Worldwide Developers Conference, Apple launched Universal Links, its long awaited foray into deep linking, with the premise that deep linking was a superior way to launch apps, navigate them, index content, and share results.

Pre-iOS 9.0, developers would use URI schemes to redirect the user to a specific piece of content within the app; this was the only available method to deep link in iOS and Universal Links made it easier for the users to navigate across — not just launch — apps with ease.

iOS 9.2 – The Fall of URI Schemes

With iOS 9.2, released in December 2015, Apple made changes to Safari which made it impossible to deep link to content within the app as the user was now redirected to the App Store regardless of whether or not the app is already installed. Developers were left with only Universal Links as an option to implement deep linking – a standard that Apple clearly wanted to push onto the community. This update hurt a lot of app developers, so we’ve created a guide if you’re still struggling to transition from URI schemes to Universal Links.

iOS 9.3 – The Trouble with Universal Links

With respect to deep linking specifications, nothing changed in iOS 9.3. However, around the time of iOS 9.3’s release, the rate of adoption for Universal Links significantly increased as bigger apps began to implement it. Deep linking via Universal Links received a great response from developers who had been trying hard to connect their in-app content to the world outside of their app.

One of the biggest advantages of Universal Links is that it is secure. Apple requires a configuration file to be uploaded on the domain name – called the Apple App Site Association (AASA) file. (You can use our new validator if you want to check to see if your AASA file is configured properly). Since the app owner has control over this, there is little chance that another app can associate itself with your links, which was not always the case while working with less secure URI schemes to launch apps.

However, despite the fact that Universal Links is secure, there are significant problems. For example, a poorly implemented Universal Link solution at Booking.com sent its app crashing on iOS 9.3 and exposed flaws in the iOS system.

Booking.com created an AASA file that was 2.3 MB in size, which was a bit too much to chew for iOS, resulting in app crashes and unresponsive links. Even though Booking.com quickly resolved the issue with a new, smaller AASA file, and Apple patched the underlying issue with the iOS 9.3.1 update, the lack of a gracious fallback for a system feature (i.e. web browsing) unearthed the vulnerabilities of the Universal Link system. The damage to Booking.com had already been done — thousands of users had already had negative experiences due to Universal Links.

Apple is definitely moving fast with Universal Links in a bid to win the war on mobile search with Google, but it needs to be wary of the consequences that a hurried solution can have on the user experience. After all, user experience is something that Apple prides itself on, and it has yet to be proven that the usefulness of Apple’s Universal Links trumps the damage to user experience that comes with its adoption.

Use the button below to get started with the most robust, easy-to-use Universal Links solution.

The post What Changed with Deep Linking on iOS 9.3 appeared first on Branch.