Hay algunas cosas que puede hacer para mejorar otras respuestas. Desde iOS 9, se puede abrir un enlace en un UIWebView o en un SFSafariViewController. Es posible que desee manejarlos de manera diferente.
El SFSafariViewController comparte cookies entre las aplicaciones y con el Safari incorporado. Por lo tanto, en su aplicación puede realizar una solicitud a través de SFSafariViewController que establecerá una cookie que dice "mi aplicación fue instalada". Por ejemplo, abre su sitio web pidiéndole a su servidor que configure dicha cookie. Luego, cada vez que reciba una solicitud de un SFSafariViewController, puede verificar esa cookie y redirigirla al MYAPP:// si la encuentra, o a la tienda de aplicaciones si no lo hace. No es necesario abrir una página web y hacer una redirección de JavaScript, puede hacer un 301 desde su servidor. Las aplicaciones como Messages o Safari comparten esas cookies.
El UIWebView es muy complicado ya que es totalmente aislado y no se comparten cookies con ninguna otra cosa.Por lo que tendrá que vuelve a los que se ha descrito en otras respuestas:
window.onload = function() {
var iframe = document.createElement("iframe");
var uri = 'MYAPP://';
var interval = setInterval(function() {
// Link to the App Store should go here -- only fires if deep link fails
window.location = "https://itunes.apple.com/us/app/my.app/id123456789?ls=1&mt=8";
}, 500);
iframe.onload = function() {
clearInterval(interval);
iframe.parentNode.removeChild(iframe);
window.location.href = uri;
};
iframe.src = uri;
iframe.setAttribute("style", "display:none;");
document.body.appendChild(iframe);
};
que he encontrado que es molesto que esto indicará al usuario si quieren salir de la aplicación actual (para ir a su aplicación) incluso cuando tu aplicación no está instalada. (empíricamente, eso solo parece ser verdad desde un UIWebView, si haces eso desde el Safari normal, por ejemplo, eso no sucederá) ¡pero eso es todo lo que tenemos!
Puede diferenciar el UIWebView del SFSafariViewController de su servidor, ya que tienen diferentes encabezado de agente de usuario: el SFSafariViewController contiene Safari mientras que el UIWebView no. Por ejemplo:
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Mobile/14E269
-> UIWebView
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E269 Safari/602.1
-> SFSafariViewController
Otras consideraciones:
- en el primer enfoque, es posible que desee para manejar las desinstalaciones: si el usuario desinstala la aplicación, todavía tiene una cookie que dice que la aplicación está allí pero no lo es, por lo que puede terminar con el mensaje
"Can not open URL". Lo he manejado quitando la cookie después de algunos intentos que no terminaron abriendo la aplicación (que lo sé porque en cada aplicación abierta estoy restableciendo esta cookie de intentos fallidos)
- En el segundo caso, no está claro si está mejor usando
setInterval o setTimeout. El problema con el tiempo de espera es que si se activa mientras está activada una solicitud, se ignorará. Por ejemplo, si abres el enlace de Messenger, el sistema operativo te preguntará "¿Dejar Messenger? Estás a punto de abrir otra aplicación" cuando el iframe intente cargar tu aplicación. Si no responde de ninguna manera dentro de los 500 ms del tiempo de espera, se ignorará la redirección en el tiempo de espera.
- Finalmente, aunque el
UIWebView es un espacio aislado, puede darle una cookie para identificarlo, pasarlo en su deeplink y guardar esta identificación como correspondiente al dispositivo con su aplicación en su servidor cuando se abra su aplicación. La próxima vez, si ve dicha cookie en la solicitud proveniente del UIWebView, puede verificar si coincide con un dispositivo conocido con la aplicación y redireccionar directamente con un 301 como antes.
Aquí está un ejemplo JS completo para iOS y Android aplicación de redirección: https://gist.github.com/FokkeZB/6635236#file-all-in-one-php – Justin