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?
Related
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.
Currently we have universal links which look like http://example.com/sharing/< id >/ which open our iOS app through the safari smart banner. But smart banners sucks, so we'd like to use the Branch.io journeys banner, which actually appears when people load the page. Since these links are already in the wild, they need to continue to work have have some way into the app. In the future we'll generate branch.io sharing links from inside the app, but these landing pages on the web will continue to exist.
I'm calling branch.init('key_test_foo'); from javascript, and the Journeys banner appears. It only ever shows the "Get" button and never "Open". I'm not clear how I pass the object ID through branch.io so that the app can navigate to the right place.
The app is built in Xamarin, and I think I have the integration built correctly following the example. It is not in our production build through the app store, I'm just running the app through the debugger in Visual Studio.
I'd even settle for an "Open in App" link like imgur has, as long as there's something I can click in safari to open the app in the right place.
I don't feel like I should have to "make a link" every time this page gets viewed, right?
EDIT:
One additional question. I think I want to change my og:url so that when facebook scrapes my page, it will open through branch (instead of back to my site). But how would I set that? Facebook isn't going to run any JS when it loads the page is it? Can I just set it to my.app.link and magic will happen from the al:ios:url that drives the deeplink routing?
I think this: https://stackoverflow.com/a/34596340/401636 might be the solution.
1. The Journey's banner navigating to your app.
Branch uses the domain of the format -alternate.app.link domain for the link behind the Journeys button. To ensure that clicking on Journeys CTA, navigates to your app ensure that you have added the -alternate.app.link domain for your app in the 'Associated Domains' file. You can check the documentation providing information on how to add the domains here.
2. The Get v/s Open issue for the Journeys CTA
Branch uses a variable has_app to determine whether the device has the app or not. For this variable to be set to true, a user should click on the Journey CTA and be redirected to the app (not the App Store). Also, the issue of the CTA not updating is common during development, because the app is frequently re-installed on the device. Due to this testing, the flag, has_app, goes in a faulty state.
To force reset the has_app variable to change the Journey's banner CTA from 'Download' to 'Open', please follow these steps:
Click on the Download button - this should redirect to the Play or App Store
Install the app
Return to the web page with the Journeys banner, which should still display the Download button
Tap on the Download button again - the app should open
Close and then re-load the web page with the Journeys banner - the banner should now have an "Open" button
Tap on the "Open" button
Please note that the above steps are required only during development mode for testing purposes. Out in the wild in production, users will not see this issue. Also, it might take some time (as long as 30 minutes) for the flag to updated.
3. Navigating to the right place in your App
If you plan on using your old domain links for deeplinking, you can update your Link domain on the Branch dashboard to the domain your links are currently using. You can then recreate the links again with the Branch API. Please note, Branch will be the authoritative registrar for your domain and you cannot host anything on this domain.
If you do not wish to do that, you can append additional link parameters to your Journeys button. These link parameters will be available in your app when the user clicks on the Journey CTA and is redirected to the App Store/your app. You can refer to the documentation here for more information.
For both the above scenarios, in order to read the link parameters in your app, you should integrate the Branch SDK in your Xamarin app. (Reference documentation here)
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.
Would like to know if expected behavior on deep linking using branch.io so when clicked on should check for app availability and prompt customer on iOS device to
Prompts to download app in App Store if not installed
Open in iOS app seamlessly if installed
If customer declines app download it will open in iOS mobile browser
My concern is this deep link behavior on a desktop experience. When a user clicks the same url I am being told this will take them to the iTunes app store resulting in a poor experience. Is this a correct statement? Is there any way to provide a better experience to the end user.
Thanks in advance!
I am being told if the same url is opened in Windows10 it will take me to the App
For example
1. Users opens email with deeplink url
2. what is expected behavior on mobile device with app installed that deep link
For iOS redirects, you'll have to set yourself up for Universal Linking per the documentation here:
https://dev.branch.io/getting-started/universal-app-links/guide/ios/
This is very important for redirect behavior on iOS 9 and later. Please note that not all 3rd party apps and browsers support Universal Linking functionality yet, so you should test on iOS from iMessage or Notes initially.
As for Desktop, you can set your Desktop redirect on the Link settings page - this will not take users to the App store/Play store on Desktop, but to the page you set. You can use the Branch hosted text-me-the-app page if you want to have this as your default for Branch redirects, or your site homepage, or any other page of your choosing. You can add Deeplink data that will be used for all redirects by adding key/value pairs in the SDK or manually when creating a marketing link from the Branch Dashboard. You can also set a $deeplink_path value that will be honored for a specific link, and you can further set a $desktop_url that will override defaults if you want a different redirect for a specific link.
There are many options and ways for you to configure how your redirects work - all of this is up to how you set your Link Settings on the Dashboard, and if you choose to override these defaults for any particular link. For example, you might have default redirects to the App store set for iOS and a desktop URL set to your main webpage on Link Settings. In this case, a link created without modifying these values will take the user to the App store on iOS (or the App if installed), and to the desktop URL specified in Link settings if clicked from Desktop. If, however, you want to override and set $desktop_url as something else for a given link, say, to a specific page on your webpage using the $desktop_url key, on iOS the redirects will be the same but on desktop you will be taken to the set $desktop_url. For any of these scenarios you can specify Deeplink Data to be passed through.