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.
Related
Senario: User scans a QR code with a unique universal link into our app to "redeem" their code.
They scan the code which goes to a webpage with a link to download the app.
The user downloads the app.
Returns to the web page and there is a link within the page which is the same link as the QR code.
We assume tapping the (same) URL would trigger the universal link but it does not.
The universal link works fine from email or other apps (after its been installed)
How can we fix this bad UX, is there a HTML component or redirect we need to consider when tapping the basic link on the Web page. How can we make the link initiate the "deeplink" into the app now its installed. The banner at the top is displayed but its not the ideal flow.
The user cannot scan the QR code again - they must go through the download and "reopen" app in one flow.
Universal links do not trigger in Safari. This is intentional behavior confirmed by Apple engineers in the forums (sorry, don't have a link right now). Their reasoning: if you're already in the browser eco-system you usually do not want to be redirected to an app, but want to stay in the browser.
What you can do is have your app implement a custom URL scheme, and your web page can then check if your custom URL scheme is supported and open it.
We have enabled Adjust universal deeplinks for our apps. We have done all the setup required for deeplink to work. Also our Adjust deeplink works fine when we open it from apps like 'Slack' or 'Notes'. But when we try to open same deeplink from Instagram, user is redirected to App store every time even when app is already installed.
I have got an article regarding Deeplinking on iOS from Instagram and I read there that it will not work until it's paid add. Does anyone have any clear idea about it?
Instagram requires deeplink / universal link to have a path appended to it, or the user will be taken to the store even if the app is installed.
E.g. this link will take user to the store:
https://app.adjust.com/x00abc1?deeplink=adjust%3A%2F%2F
however this one will open the app (if installed)
https://app.adjust.com/x00abc1?deeplink=adjust%3A%2F%2Fyour_path
Interestingly, this path does not have to be valid, there just needs to be a path. I.e. if the client / partner only wants the deeplink to open the app, they can add any invalid path. This will lead to the deeplink opening the app, but being served a path it does not recognise, which leads to the app simply not opening said path, but the app will be open.
Note: Some special characters, like ? are not technically a path, and will therefore not provide the desired behaviour.
we are currently in the process of linking our web portal to our native app (iOS). In the first step, we will try to implement some Deeplinks.
Therefore it is planned to host the "apple app site association file" on the domain (e.g portal.example.com) and provide deeplinks with the help of Universal Links. However, before we start the implementation, there are some questions left:
Let's say we have only 3 URLs that should deeplink to the app. Each of them will get an own row in the paths section:
portal.example.com/functions/firstfunction
portal.example.com/functions/secondfunction
portal.example.com/functions/thirdfunction
If the User now opens the first URL, he will be asked if he wants to open it in the app, right? Let's pretend the user accepts and opens the URL in the app. What happens if he then goes back to the portal and tries to open the second URL? Will he be asked again, or will the app remember the decision and open any URL from the aasa file in the app?
What happens if we use wildcards and write the path like this:
"portal.example.com/functions/*"
Thank you and bg!
Let me first correct you:
If you use 'universal links', and you open any url, then it will not first ask you that "open in app" and then if denies then to webpage.
But it will be work in this manner:
You must be opening URL in iOS device's safari browser(it will not work for other browsers).
It will first open the webpage. If it finds 'apple-app-site-association' file on that website + It also finds the app with same path in its associated domains section installed on device. Then it will show top bar like below image:
Now, if use clicks on this OPEN button, then only your app is going to be opened. If you come back from app to website, this will remain as it is on top.
Answer to your second question: If you provide only specific domains, then the above popup will be visible only for specific webpages. If you are using wildcards, then all webpages which comes under that wild card, will have top bar like above image.
One more thing to note while you are developing above feature: Universal links get associated while you install the app OR update to new version. So, while developing app - let you have installed app without any associated domains, now you added associated domains in app, and installed app again(via xcode) on your device, and open the webpage in safari. Then above will not work. To make it work, either you have to remove/uninstall the app first and then install it again OR you have to change the version.
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.