The point is that I corectly set up universal links for my domain: example.com. And if within other or system app I tap on the link:
http://www.example.com/first/second then my app is being opened:) it just works.
But my links are linked to other domain otherdomain.com which redirects to example.com. And it is not going to work. What is the way to workaround this?
Is it possible to make it working withount removing redirection?
iOS considers what to do immediately after a link is tapped. If app exists, and the domain allow associated app to be opened via link, the app is being opened. There is no way to catch redirection.
First direct link is considered as not to be opened via app, and iOS does not track what is going on later. It doesnt care about redirections in context of universal links.
Related
I am using Firebase Dynamic Links to handle deep linking into my ios app (from external links) and this works fine.
My issue is when I try to handle a dynamic link that has been launched from inside the app. In particular, I am using Firebase in-app messaging with a dynamic link as the action on the card button.
I have added the capabilities and URL scheme to Xcode. The documentation states that I use the Firebase app bundle as the URL scheme value. The only thing that isn't clear is whether this means the Firebase project id or the dynamic link domain which is the one set in the capabilities tab as the applinks: value.
When I tap on the button to launch the dynamic link it does recognise it as a dynamic link (because it doesn't just open my hosting domain in the browser), but it redirects to the browser first and asks me if I want to open the app (that I just came from).
Does anybody know how to configure this behaviour so the links don't ask you first? Would this then immediately handle the link in the app?
UPDATE
I was able to get the app to handle the dynamic link immediately in the app by skipping the preview page. You do this by manually constructing the link and setting the efr=1 parameter. This article explains it all: https://firebase.google.com/docs/dynamic-links/create-manually
BUT - although my app was handling the deep-link, it STILL redirected to the browser where it attempted to load the web.app domain from hosting.
I feel this could be something to do with the URL types setting in Xcode which if set properly should prevent it from trying to handle links in the browser.
UPDATE UPDATE
For some reason, this just stopped redirecting to the browser and I have no idea why. I watched a Firebase video and the guy did mention something about iOS being weird, and that Safari can break dynamic links and he recommended always testing them from the notes app. Weird. I wonder if something got pwned somewhere. I will write up an answer. đź‘Ť
Not entirely sure why, but this just started to behave. The dynamic link I am using in the in-app messaging campaign is the long-form URL with the efr=1 parameter to skip the preview page in the browser.
So the usual flow for magic link is:
User clicks on the link in their email (e.g. www.domain.com/auth/:token)
Page is opened in the email’s in-app browser.
Token is stored in the in-app browser’s local storage and token is removed from the URL (either by redirection or some other method).
User is logged-in (in the in-app browser).
The problem happens if the user then clicks the “Open this app in Safari” (or another browser) in a mobile's in-app browser. The user will be logged-out since the local storage state is not carried over and the token was already removed from URL parameter. Unless the token is present as a query / parameter on every page URL which is unsecure and defeats the purpose of using local storage.
What is the best solution for this use case without providing a typical login flow (username/pw)? (Or is that the only way?) Seems like you cannot browse any app in iOS using a magic link via an actual browser app since the magic link will always come from your email app (and hence, will always be opened using the in-app browser).
To use a magic link in order to open your App from an anchor clicked into an email client, you need definitely to setup Universal Links.
That said, things are not always that simple. In some circumstances Universal Links won't work and will open directly into some in-app browsers instead opening your app, this occurs sometimes with the SafariViewController embedded into email clients as you noticed.
So what to do to make it work in all cases?
As you know an Universal Link should open your app if it is installed, but it should also open a fallback web-page in any other circumstances when your app cannot be opened. This is where you will make it bulletproof: on the fallback web-page make sure you put an obvious button with a "safety" second/backup Universal Link that will do the exact same action into your app.
It will work because if your Universal Link fails to open directly from the email client and opens a browser window by mistake, it will most probably open your app when triggered from the in-app browser fallback web-page.
At the end, you might want to focus and put an extra effort to setup a very nice design for your fallback web page, making it look like your app, to provide a good UX so that your users may not even notice that they went thru an extra-step…
I'm in the same boat with our webapp's passwordless login authentication. Did you end up using Universal Links to successfully overcome the issue?
I am having a real hard time finding an answer to this. I know that the app manifest itself can exclude links, but I have an active bug that is affecting users and updating the app is not a fix for current users unfortunately.
The issue is that on our mobile site, we have a flow where it redirects to another domain, an then redirects back. On that 2nd redirect back, if our app is installed on the device, the app will briefly open before switching back to the browser. When this happens, the page breaks (as the 2nd redirect is actually a form submission (a POST) and the app can't forward that POST on.
Is there a way we can add a header or a param or something to tell iOS to not try a deep/universal link? Something to just use safari?
Not with headers
Unfortunately, the device will only make a request to the Universal Link if it does not find a matching AASA file on your device. It will perform a handoff to your app which is done on the local OS with no requests. Therefore, there is no way to check the headers of the request if the device recognizes it as a Universal link.
Same domain fix
The only case in which Universal Link will use the browser if the app is installed is when a is already on the Universal Link domain when they click the universal link.
Example: If a user is on example.com on Safair, they have an AASA on their device that has applinks:example.com, and they click a link that redirects them to example.com/item123, they will not open the app.
In your case, you leave the domain and come back. Your best bet is to figure out a way to redirect the user while keeping them on the same domain. I know that probably doesn't help a ton, but that's your best bet.
I have Universal Linking setup in my app.
Now when browsing my website in Safari and visiting a UL registered link, it opens in safari and asks me if I want to open in my App.
Is there a way that it always opens in the app? No prompt to open in app, just open when it is installed, else continue in safari.
There are two different issues here:
1. In Safari, the URL of a Universal Link needs to be on a different domain/subdomain than the page on which it appears
Apple is very conservative with where Universal Links are allowed to work. One of the limitations in Safari is not allowing the app to open if the user is already browsing the same site (this sort of pages sense — if the user made the effort to open a site in Safari instead of the app, it could be annoying if every single link on that site tried to open the app, especially if the app isn't properly configured for deep link routing).
The workaround is to use a separate domain/subdomain for links you want to open the app. For example, if your site is on example.com, point any link you want to open the app to link.example.com and then redirect users without the app back to the main website or onward to the App Store. This is actually the system we built at Branch.io (which you could consider using instead of re-building it yourself!)
2. What you have described is not Universal Links behavior
Universal Links do not ask the user for confirmation before opening the app, even the first time. They always open the app immediately without even requesting the web page, until/unless the user explicitly disables them (which is actually rather easy to do). What you're describing is the behavior of custom URI schemes, so I suspect you may have a some sort of automatic redirect to the app's URI scheme on the page the Universal Link points to. This is actually not the best idea in most cases, since users without the app will see a nasty error message.
I have universal links working correctly, when the app is installed I see how the link opens the app, and when it's not installed opens the url in safari.
Actually what I would like to do is to redirect and go to the app store, so users can download the app directly.
Im going to include a redirect on the html file, because I know universal links don't support redirects a the http server config level (anyway I think this is for the manifest file only, apple-apps-site-association)
Anyone can confirm if this is the right way to do it, or the only way to do it? I don't like the idea to open safari first, load my html (with the redirect only) and then go to the store. Looks like there's no easier way to do it.
You're right: server-side redirects aren't allowed for the apple-app-site-association file. However, I believe once the user opens a Universal Link and (assuming the app is not installed) lands on the URL, all options are on the table (server-side, or otherwise).
If the page on the other end of your Universal Links URL contains an instant JS redirection to your app's App Store page, that should work just fine. Something like this:
window.location = 'itms-apps://itunes.apple.com/us/app/imdb-movies-tv/id342792525'
But yes, no matter how you do it, Safari is still going to open. It'll flash past so quickly that the user likely won't even notice. Here's a real-time recording I just made of the Branch.io deep linking service's demo app doing exactly this process:
From here: https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html
"When you support universal links, iOS 9 users can tap a link to your website and get seamlessly redirected to your installed app without going through Safari. If your app isn’t installed, tapping a link to your website opens your website in Safari."
You're not doing it wrong, that's just how they work.