Universal links with redirects not working in iOS
Company domain links end up in the iOS app. Links with redirects through MailChimp to company's website from email website end up in the iOS app.
But links which redirect to company domain website through MailChimp tracking link tapped in mail app (Mail, Gmail etc) end up in Safari in company's web site.
Is there any workaround to make MailChimp email links with redirect work as universal links and bring up the iOS app?
Answer
I have actually developed a workaround for this.
We created an app that had the function to allow a user to sign in by generating a magic access link. The user would download and install the app, enter their email address and the server would send them an email containing a link in the form of: https://www.example.com/app/accesslink/{{tokenHere}}
We created an AASA file and uploaded it to our domain (www.example.com) for example :) https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html
Most users could generate an access link fine, tap it and the app would load. We had handlers on the app to pick up the token and authenticate them etc.
The problem came when some email providers rewrote the access link in the email. This especially happened to corporate users who had URLblockers installed.
To work around this we created a rewrite rule on the server to rewrite www.example.com/app/accesslink/{{anythingHerer}} to a static file on the server called '404accesslink.html' (the filename is arbetary, the server was asp.net IIS in this case). We then edited the '404accesslink.html' as follows to include the following meta:
<script>
document.writeln('<meta name="apple-itunes-app" content="app-id={{APP_ID_HERE}}, app-argument=' + document.location.href + '">');
</script>
Because the file was served over a rewrite the location.href value was an exact match for the access link. This tricked iOS into opening the app and passing the path to it. We could then pick it up in the handler as normal and authenticate the user.
We wrote some simple instructions in case opening the app wasn't automatic and the page was displayed (although in our tests this didn't happen).
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<script>
document.writeln('<meta name="apple-itunes-app" content="app-id=XXXXXXXXXX, app-argument=' + document.location.href + '">');
</script>
<style>
body {
padding-top: 5%;
color: #FFF;
font-size: 1em;
font-family: Arial, Helvetica, sans-serif;
text-align: left;
background: #00338D;
margin: 50px;
}
h1 {
font-weight: normal;
font-size: 1.8em;
}
a {
color: #FFF;
font-weight: bold;
text-decoration: none;
}
</style>
<title>XXXXXXXXX</title>
<body>
<h1>Please select 'Open' in the app banner displayed at the top of this page to open the app with your access link.</h1>
<p>If you do not see the app banner above then please close your browser and sign into the app using your email address and the password you used to register for the event.</p>
<p>If you do not know your password then you can <a href="https://XXXXXXXXXXXXX/account/mobileforgot/">reset it by following this link</a>.</p>
<p>Thank you,</p>
<p>XXXXXXXXXXXXX team</p>
</body>
</html>
The meta would probably be better if it was set and rendered server side as opposed to using JS client side, but it worked none the less.
Before this was done: If any system rewrote/wrapped the app link the app wasn't associated with the new URL and when the user tapped the URL it was opened in Safari.
After this was done: If any system rewrote/wrapped the app link the app wasn't associated with the new URL and when the user tapped the URL it was opened in the app.