I am implementing Firebase App Indexing as mentioned in official firebase documentation here: https://firebase.google.com/docs/app-indexing/ios/app.
The universal links are enabled and work fine for search results from different browsers like Safari and Chrome. They also work for other applications. But when I tap on a search result from the Google Search App in iOS. It does not take me to my app. Also on long pressing a link in the Google app does not provide an option to open link using my App. This option is however shown when I long press on links from other applications.
Does it have something to do with the Google Search app disabling the universal links deliberately. Is it possible for individual applications to prevent Universal Links from opening other applications?
Or does Apple apply restrictions itself for certain apps?
Indeed, some apps disable the capability of deep linking using Universal Links. Some notable examples: Facebook, Instagram.
Some of these apps allow deep linking via URI schemes (the old iOS 9- way of deep linking), but there is no promise that this behaviour will be persisted.
I'm guessing most of these apps would like to have the user stay within their own in-app browser instead of switching to another app.
I never tried the Google Search app, but if your universal link works perfectly in Safari and not in the Google Search app, that may be the case. In that scenario you'll need your click domain server to redirect the user to the store or some landing page, based on the User Agent of the incoming browser.
Related
I am planning to use app link from FBSDK to invite using my iOS app via email.
I know if my iOS app was installed on the device it will be opened when I select the link and handle invite token in URL.
But how about if my app was not installed?
After user install it from App Store can I handle invite token also?
Hope anyone used to work with this scenario can help me.
There are a lot of reasons why what you're trying to do won't come out the way you want it to. Let's dive in...
App Links don't work anymore
Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:
A set of meta tags to add to the web page destination of a standard http:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.
App Links were supposed to be an open-source standard to change the world, making app-to-app deep linking simple and universal. Unfortunately Facebook has decided they actually don't want that world (it's much better for them to keep users inside the Facebook app — see Instant Articles if you don't believe me), meaning the App Links standard is essentially dead. It's no longer supported on the iOS Facebook app, and Applinks.org isn't even a separate website now.
App Links were not designed to work with email (or essentially any app except Facebook)
Even if it were still supported by Facebook, the App Links standard has a critical flaw: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps.
To function as you want, where deep linking can occur from links in emails, the routing engine component would need to be implemented in any email app where your link could possibly be clicked. This was never going to happen for apps like the default iOS Mail app from Apple, or the Gmail app, for example.
App Links had no meaningful support for deferred deep linking
Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first) requires a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do. You'll notice that neither of the two App Links components included a remove server to retain link data through install, so deferred deep linking was never properly supported in the core App Links standard. Facebook ads make use of the partial support for deferred deep linking offered by the FBSDK in conjunction with App Links, but this only works when the link/ad is clicked within a Facebook app and the receiving app has the FBSDK integrated.
Deferred deep linking is tough anyway
Moving on from App Links, deferred deep linking is still complicated. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to send the user to the correct item, and they actually aren't supported in a lot of places.
Deep linking out of email on iOS is very hard
Almost all email links involve some sort of click tracking, which is always implemented as a link wrapping redirect. This isn't technically a problem if the user doesn't have your app installed, but if they do, Universal Links don't work with wrapped links. If you're building it yourself, you'll either need to completely disable click tracking in your emails, or accept that deep links won't work there.
Bottom Line
App Links were never the solution you needed. A free service like Branch.io (full disclosure: they're so awesome I work with them) or Firebase Dynamic Links is what you need. Both services support deferred deep linking, out of Facebook or almost any email app. Branch is more powerful and offers far more features, and works with major email senders to offer a solution for deep linked email (the only one on the market today).
I've added app links headers for my web site with metadata for my iOS app, but they don't open app when post is clicked. Is app links works as described in documentation in 2017? (https://developers.facebook.com/docs/applinks/add-to-content)
This is expected behavior
Unfortunately it is not currently possible to directly launch a third-party app from within the iOS Facebook app. This is a known issue that Facebook has essentially written off as wontfix. This is still possible in the Android Facebook app, but it's unfortunate they haven't been more transparent about the change to the iOS version because there is quite a bit of confusion about it.
Instagram is a special case because it is a Facebook-owned app and gets different treatment.
But you can work around it
Services like Branch.io (full disclosure: I am on the team) get around this by implementing a judicious combination of App Links, URI schemes, and iOS Universal Links. Essentially what you need to do is open a page in the webview and then have a button or other user-driven CTA event that launches the app from there. It's an extra step for the user, but currently the best workaround. If you just want to be able to post a link that goes into your app when it is installed and otherwise goes to a webpage (or the App/Play Store), then Branch links are definitely your simplest solution.
Branch link routing logic
I have deep link generated using branch.io shared to twitter, email and Facebook.But clicking on the links in respective social networks works only in twitter, which opens the installed application.Facebook and email are not opening my application installed.Please help.
I'm adding a note here for any who may coming across this ticket while researching similar issues.
Branch links are intended to open their associated apps when the app is installed on a device - or to redirect the user to the app's page on the App or Play Store if the app is not installed. Unfortunately, there are certain applications that prevent Branch links from functioning as intended. Generally speaking, these tend to be apps employ captive webviews. Some apps, Slack for example, allow users to turn off captive webviews and use Chrome or Safari - which solves this issue. Other apps, like Facebook, do not have such a workaround.
Branch's current recommendation for partners using Branch links in Facebook posts is to leverage iOS Deepviews. When iOS Deepviews are enabled, clicking on a Branch link in the Facebook feed will open the Facebook webview with the Deepview. The CTA button in such Deepviews works properly as a Universal Link, opening the app or leading users to the App Store as appropriate. Link information from the original Branch link will be available to the app when opened in this fashion, and Branch attribution and analytics will also work properly. This is the most robust app linking experience that can currently be achieved from the Facebook feed. Although not ideal because of the introduction of an additional Deepview, every other option involves some type of tradeoff.
Branch Deepviews can be enabled at the app level (i.e. for all of the app's links), at the link level, or specifically for Facebook and/or Twitter. Note that enabling this last option (always showing Deepviews only when links are clicked from Facebook and/or Twitter) does require assistance from Branch - partners can reach out to them at: support#branch.io.
On iOS, problems with an app's Universal Linking configuration can also lead to issues like the one reported here and are extremely common. Branch has made a Universal Linking Validtor tool available to help identify and resolve issues with Universal Linking. This tool can be found here: https://dev.branch.io/getting-started/universal-linking-validator/guide/. A troubleshooting guide is also available, here: https://support.branch.io/solution/articles/6000153326-ios-universal-links-troubleshooting-guide.
As a general recommendation, test Branch links and ensure they are working properly from a standard app (like Notes on iOS) before testing in social media posts.
I am trying to implement Branch marketing links in my app. I want for example to be able to create a link to share with users that will route them to a particular screen in the app. I noticed from the Branch docs that for some apps the link just opens the app store and not the actual app (even if it is installed). Being based in Asia I have the feeling that most of our customers will be wanting to share the link via an unsupported app such as Line. If a user is redirected to the app store via the link and then taps “open app”, what happens? Is the link meta data lost? Does the meta data only remain if the link is opened in an app such as mail or notes?
Alex from Branch.io here:
This list in the Branch documentation gives a partial list of apps that support Universal Links, but unfortunately it is not complete. We've tried to cover the most common apps.
Line is using a custom webview (not SFSafariViewController). It doesn't support Universal Links for the initial click, but this is one of the edge cases where Branch can detect the originating app and do some custom behavior. For Line, we trigger your app's URI scheme. This means the behavior your users see when clicking a Branch link from within Line is the same as Universal Links, even though Universal Links isn't actually the protocol being used.
If you want to handle other apps where Branch doesn't have a workaround like this, you could try enabling the deepviews feature. This will cause the link to open a content preview with a button to launch the app (or forward to the App Store if not installed).
When a user with the app already installed clicks the Open button on the App Store page, all the meta data is preserved and they will still be deep linked. Branch doesn't know (or care!) what happens between when the user clicks the link and the app launches, so that gives you plenty of flexibility.
Universal Links have some restrictions - not from Branch but from Apple's implementation. One of these restrictions is Universal Links cannot be opened from SFSafariViewController.
From Branch's docs, Line is not explicitly mentioned but other popular messaging apps may be of interest. I don't have Line myself but whether Line launches websites in it's own browser or the Safari app may give you a clue.
Facebook Messenger - works conditionally
WeChat - works conditionally
Twitter - works conditionally
LinkedIn - works conditionally
Any app using SFSafariViewController - works conditionally
I'm looking at some ad SDKs and it's difficult for me to find a way to present them without leaving the app. I've tried a handful of them but lets say AdMob for purpose of answering this question.
Is there a way to present AdMob ads in an in-app browser once they are clicked? Or would I have to use a different SDK if I want to achieve that.
If the answer is the latter, what well known Ad SDKs would let me do that?
Opening the target page in Safari and not in an in-app browser is on purpose: Safari allows to better track the users. The reason is related to the cookie handling: Safari stores cookies globally while the UIWebView based in app-browsers have a cookie store restricted to a single app. Therefore with in-app browsers, you cannot track users across apps.
However, there is a solution to mitigate the problem provided you have a certain control about the ads (and aren't simply taking the from a network).
An ad can consist of more than just an image with a target link. It can contain interactive elements. You can take advantage of it by creating an ad that opens an overlay when tapped. The overlay shows a web page within your app. The user can then either close it or tap a link that takes her to a further web page shown in Safari.
The standard API to implement an overlay supported by most ad SDKs is MRAID. Google Mobile Ads SDK (formerly known as AdMob SDK) supports it. The Google SDK additionally supports the AdMob SDK.
Good examples for such ads can be found on a Google support page. Specifically check out "Sample Code for an expandable ad (MRAID)" and "Target window: in-app overlay window".