Is there any better solution for using deep links in iOS which has 100% success rate.
We started using Universal links in my projects. The problem with universal links is, sometimes they stop working (like redirecting to browser etc.) So every time when a user faces this issue our customer support team needs to help the users by making them to try few workarounds like:
1) Enabling the universal links again by copy paste on Notes, iMessage etc.
My requirement is when user clicks on a link from his email, I need to open my app and based on the context/meta-data passed form that deep link, I will handle the situation in my code. If we cannot deal this, what would be the suggested fallbacks when it redirects to browser ??
Related
I am using branch for deep linking on facebook as well as twitter. Deep linking opens up my app successfully and I am also able to retrieve all the parameters correctly. But at one instance, it stopped working and said developers are working on it and after 2 days started working again after I submitted a ticket to Branch and without me changing anything. But this weird stopping and starting of link is not good for app users. Can someone from Branch help me know the possible cause for the same, as for the live app, this would create a problem?
The reason why you are experiencing this issue is that apps like Facebook, Twitter, Instagram and Snapchat prevent users from opening a third-party app via Universal Links. One way to mitigate this issue is to use forced redirections via URI Schemes on the in-app browser. You can enable forced redirections on Branch links by appending $uri_redirect_mode=2 as a query parameter.
eg:
https://example.app.link/j93str?$uri_redirect_mode=2
If you are still experiencing issues, please write to integrations#branch.io with a video recording of the link redirection behavior and one of our engineers would be able to help you with this.
Branch documentation includes two types of method calls - synchronous and asynchronous calls to method that generates url. If we are using asynchronous call, it would take time to give us the url so need to check for url first before posting it on social sharing and if we are using synchronous call, we get a short url which can be easily shared to social sites. This is what made a difference for me!!
I implemented universal link to my iOS app. It directs user to application if url has this "www.websiteurl.com/suburl/*.com" pattern.
I want this work only if user click this url from google search result. If user is already in website I want to open url in website either not open the application. How can I prevent it?
edit: I implemented Support Universal Links documentation.
Yes, this is possible, but I don't recommend it. If the user has the app installed, it seems like you should want to open the app as soon as possible since it is a much better experience. Anyways, here's my solution.
Option 1
Short answer: Wrap your website links in javascript
Why? according to the Apple standards of Universal Links, a link must be clicked on by a user to trigger the Universal Link, therefore if you set up all of your links on your website to be handled by javascript, the app will never open from inside your website.
Therefore, change
Link
Into a javascript call
Link
And open the link from javascript
function clickLink(link) {
window.open(link);
}
Option 2 (Better option)
Use a third-party like Branch links for all of your deep linking so that you can pass more context from web to app allowing the user to continue the same experience on mobile that they were just having on the web. Native is a much better experience 99.9% of the time and it converts users at a much higher rate than web.
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).
My company has an app (iOS and Android), to which the following scenarios applies. I'm trying to help point my engineers and product team in the right direction.
When one of our users clicks on a content link from one of our emails, or Tweets or Facebook posts, and they're on their mobile device, we prompt the user with a link to download our app. This is similar to what many apps do, including LinkedIn (see i.stack.imgur.com/glSgJ.png).
I imagine this is mildly effective of driving awareness and downloads of a native app, for new users who came in from social media and various web sources. However, it is not helpful at all for a user like me who already has the app!
1) clicking "No Thanks" keeps me on the mobile web (when I want to be in the native app), and
2) clicking "Download the App" takes me to iTunes App Store page for an app I already own.
SUPER ANNOYING. As a result, I have to manually open the app, and search for the content in question. I'm guessing most users don't do this. More importantly, depending on the UI/UX of the app, I may never get there!
Again, I know we are handling mobile web visits in the same way many other companies (including LinkedIn) do, but it seems we are leaving a lot of potential native app use on the table. I want our engineers to build that elusive 3rd option, "Open In App".
Spotify and Rdio have solved this very nicely. Here are deep content links (in the case of these companies, to a specific song) for the two apps respectively:
http://open.spotify.com/track/2SldBUTJSK6xz43i8DZ5r2
http://rd.io/x/QF3NK0JKWmk
If you have a moment, first grab the free version of Rdio or Spotify apps. Then, if you open those links above from an iOS device, you will see how nice the experience is, for existing native app users: Rdio has a nice "Tap to open in Rdio" link (http://i.stack.imgur.com/B7PuE.png), and Spotify's link is even more clear, "I have Spotify" (http://i.stack.imgur.com/Q3IV6.png). Both apps also include a link to download the app, for new app users. More importantly, both apps cookie the user: future visits to links (whether from email, Twitter, Facebook, etc) on mobile web automatically open the app, instead of prompting you to choose each time. SUPER CONVENIENT.
Questions:
1) How do they accomplish this? I'm initially only concerned about iOS (on which I tested this), but this same situation should apply to Android.
2) Why aren't more apps doing this? It doesn't seem like rocket science, so am I missing a key reason why this might be a bad idea? Half of my problem is convincing the use case.
3) Why don't I see discussions about this technique? I've searched a ton for an iOS solution. I come up with a lot of discussion about URL registrations (mainly app-to-app), but no one actually referring to the type of scenario I describe (mobile web prompt to open native app).
It seems that with minimal engineering, app developers could dramatically increase native app use, converting from mobile web. :)
Android supports deep linking. Please refer to
http://developer.android.com/training/app-indexing/deep-linking.html
Tapstream's deferred deep links can send users to specific views within apps (iOS only), even when the app isn't yet installed on their device.
We are using ShareKit, an excellent open source framework for integrating social sharing services into iOS apps. We have been seeing lately that sharing to FaceBook triggers a captcha prior to submission almost every time. Needless to say, this experience is not what we want to offer our users.
In addition to that, if the user has keyed in any additional text or edited the post, receiving the captcha will ignore the extra text and only post the text that was pre-filled by the app when it popped the FBConnect dialog.
Has anyone else run across this? Is there some activity that might be causing the captcha to pop up that Facebook might consider a red flag?
As background, this app has been in the app store for almost a year, and this is the first time we're seeing this behavior.
The captcha being required is likely related to the content you're posting - this is especially likely if you're on a shared domain with many other apps or websites - try sharing the individual links and images manually on Facebook.com to see if any throw a captcha there.
The other issue, that the content is partially lost after the captcha sounds like it could be a bug, you should file it at Facebook's API bug tracker at http://bugs.developers.facebook.net with repro instructions