Comment configurer les Smart App Banners de Safari pour optimiser vos redirections iOS

Comment ajouter un Smart App Banner à mon site web ? Pour ajouter un Smart App Banner, vous devez insérer la balise meta apple-itunes-app dans l'en-tête HTML de votre site, définir votre app-id unique et transmettre des paramètres de routage via l'attribut app-argument pour activer le lancement natif de l'application depuis Safari et les replis vers l'App Store.

Un Apple Smart App Banner est un composant promotionnel natif de Safari déclaré via une balise meta HTML. Il affiche une invitation discrète au téléchargement ou à l'ouverture de l'application en haut des pages web sous iOS et iPadOS. Rendu directement par WebKit, il détecte si l'application est installée : il présente un bouton « Ouvrir » qui transmet des paramètres contextuels aux applications installées, ou un bouton « Voir » qui dirige les utilisateurs non équipés vers l'App Store.

Pourquoi les Smart App Banners de Safari restent essentiels pour l'acquisition sur iOS

Intégration native à Safari : Zéro charge JavaScript et rendu cohérent au niveau de l'OS

Le Smart App Banner natif d'Apple constitue un pont intégré entre le contenu web et les applications iOS. Contrairement aux bannières JavaScript personnalisées qui nécessitent une manipulation du DOM côté client, des bibliothèques de style tierces et des recalculs de mise en page constants, les Smart App Banners natifs sont rendus directement par WebKit au niveau du système d'exploitation.

Comme WebKit gère la mise en page nativement, la bannière ne génère aucune surcharge d'exécution JavaScript et ne bloque pas le thread principal du navigateur lors du chargement initial de la page. La bannière s'affiche de manière cohérente sur les formats iOS et iPadOS, s'adaptant harmonieusement aux rotations de vue, aux zones de sécurité (Safe Area) des modèles d'iPhone récents et aux paramètres d'accessibilité du système comme le Texte dynamique.

Éliminer la friction de recherche en magasin : Récupération automatique de l'icône, du titre, de la note et du prix

Configurer une invitation promotionnelle standard sur le web oblige généralement les équipes marketing à interroger manuellement les API de l'App Store pour afficher les icônes actuelles, les titres des développeurs, les prix localisés et les notes globales. Lorsque les métadonnées de l'application changent (mise à jour d'icône pour une campagne saisonnière, promotion de prix de lancement), les bannières personnalisées statiques deviennent rapidement obsolètes.

Les Smart App Banners natifs éliminent cette charge de maintenance. En lisant un app-id valide, WebKit communique directement avec les services locaux de l'App Store pour récupérer automatiquement les métadonnées de production de l'application. Safari affiche l'icône officielle de l'App Store, le titre, la note actuelle et le prix localisé (ex: « Gratuit » ou devise locale) sans que les développeurs web n'aient à coder en dur des éléments marketing ou à gérer des tables de chaînes localisées.

Détection d'état au niveau système : Comment WebKit distingue les utilisateurs ayant installé l'application

Un défi persistant du routage web-vers-application est d'identifier si l'appareil visiteur possède déjà l'application native. Pour des raisons de confidentialité et de sécurité, les sandboxes des navigateurs interdisent strictement au JavaScript des pages web d'interroger les registres d'applications locales ou d'inspecter les listes de paquets installés.

Les Smart App Banners natifs résolvent ce défi au niveau de la plateforme. Safari détermine si l'application est disponible sur l'appareil à l'aide de mécanismes au niveau du système inaccessibles au JavaScript des pages web. Si l'application correspondant au app-id déclaré est installée, Safari affiche un bouton d'appel à l'action (CTA) « OUVRIR ». Si l'application est absente, la bannière affiche un CTA « VOIR ». Cette détection s'effectue entièrement dans la limite du système d'exploitation, évitant le fingerprinting côté client tout en aidant les visiteurs à recevoir une invitation précise et exploitable.

Comment structurer correctement la syntaxe de la balise meta Apple iTunes App

Dissertation des attributs de balise essentiels : app-id et app-argument

Le Smart App Banner natif se configure via un seul élément HTML <meta> placé à l'intérieur du <head> du document. L'attribut name doit être défini exactement sur apple-itunes-app, tandis que l'attribut content accepte une chaîne de paires clé-valeur séparées par des virgules :

<meta name="apple-itunes-app" content="app-id=123456789, app-argument=myapp://product/detail/1024?campaign=spring_sale">

La documentation actuelle d'Apple sur les Smart App Banners définit deux paramètres principaux pris en charge :

• app-id (Requis) : L'identifiant numérique unique attribué à l'application dans App Store Connect. Cet identifiant permet à WebKit de résoudre la fiche produit correcte et d'interroger la disponibilité de l'application locale.
• app-argument (Optionnel) : Une chaîne URI valide (telle qu'un schéma d'URL personnalisé ou un Universal Link HTTPS) que Safari transmet à l'application native lorsque l'utilisateur appuie sur « OUVRIR ».

Les anciennes références aux Smart App Banners documentaient un paramètre supplémentaire, affiliate-data, utilisé pour le suivi des partenaires. Comme la documentation actuelle d'Apple ne liste plus affiliate-data comme paramètre standard, traitez les métadonnées d'affiliation comme un comportement hérité, sauf vérification séparée conforme aux directives actuelles des partenaires Apple Services.

Règles de formatage strictes : Validation des délimiteurs par virgule et des guillemets

L'analyseur de métadonnées de WebKit applique des règles structurelles rigides. Les erreurs de syntaxe courantes entraîneront l'ignorance de la balise par Safari :

• Les attributs dans la chaîne content doivent être séparés par des virgules, pas par des points-virgules ou des barres verticales.
• Les valeurs d'attribut ne doivent pas contenir d'espaces non encodés ni de caractères virgule bruts.
• Les valeurs d'attribut ne doivent pas être entourées de guillemets imbriqués dans la chaîne d'attribut content principale.

Une balise correctement formée adhère à la spécification suivante :

<meta name="apple-itunes-app" content="app-id=987654321, app-argument=https://app.example.com/promo/summer?source=safari_banner">

Exigences de rendu côté serveur : Rendu fiable des métadonnées du Smart App Banner dans l'en-tête initial

Les architectures frontend tentent fréquemment d'injecter ou de mettre à jour la balise <meta name="apple-itunes-app"> dynamiquement en utilisant des frameworks JavaScript côté client (comme React, Vue ou Angular) après l'évaluation des paramètres de routage des applications monopages (SPA).

Pour un comportement déterministe du Smart App Banner, effectuez le rendu de la balise meta apple-itunes-app dans le <head> initial du document. Apple recommande la génération côté serveur de app-argument ; ne comptez pas sur des mutations du DOM côté client après chargement via document.head.appendChild() ou modification d'attribut, car WebKit analyse les métadonnées du document lors de l'évaluation initiale du flux de document et pourrait ne pas réévaluer les configurations de bannière lors de modifications ultérieures du DOM côté client.

Validation de la conformité WebKit aux normes de métadonnées documentaires W3C

L'élément apple-itunes-app est conforme à la Spécification de métadonnées documentaires HTML5 du W3C, qui autorise des extensions spécifiques aux fournisseurs au sein des éléments <meta> standard. WebKit adhère aux normes d'analyse URI RFC 3986 lors de l'évaluation de la charge utile app-argument imbriquée.

Mécanismes techniques de transmission de paramètres via App Argument

Encodage des charges utiles de deep link dans la chaîne app-argument : Schémas vs URLs HTTPS

L'attribut app-argument établit un routage contextuel vers l'application native. Les équipes web peuvent fournir soit un schéma URI personnalisé, soit un Universal Link HTTPS :

1. Schéma d'URL personnalisé (myapp://product/detail/1024?id=1024) : Lance l'application et transmet la charge utile aux délégués d'URL personnalisés natifs. Les schémas personnalisés permettent un réveil direct de l'application, mais n'offrent pas de repli web indépendant s'ils sont copiés en dehors de Safari.
2. Universal Link HTTPS (https://app.example.com/detail/1024?id=1024) : Transmet une URL de domaine vérifiée. Cela assure une analyse unifiée des paramètres via les délégués Universal Link tout en maintenant une destination web entièrement accessible sur d'autres plateformes.

Gestion de l'échappement des paramètres de requête pour éviter la troncature d'URL dans WebKit

Lors de la transmission de jetons de suivi, de codes de parrainage ou de charges utiles imbriquées dans app-argument, les développeurs doivent structurer l'URL correctement. Comme WebKit utilise des virgules pour séparer les attributs dans la chaîne content, une virgule non encodée dans un paramètre de deep link tronquera prématurément le app-argument.

Préservez la syntaxe d'URL standard (scheme://host/path?query) tout en encodant les caractères réservés — tels que les virgules, espaces ou délimiteurs imbriqués — au sein des valeurs de paramètres de requête. Dans les fichiers source HTML, toutes les esperluettes (&) reliant plusieurs paramètres de requête doivent être correctement échappées en & :

<!-- Malformé : La virgule non encodée tronque l'analyse de l'attribut -->
<meta name="apple-itunes-app" content="app-id=123, app-argument=myapp://route?filter=red,blue">

<!-- Valide : Structure URL standard avec esperluette échappée HTML et valeurs de paramètres encodées -->
<meta name="apple-itunes-app" content="app-id=123, app-argument=myapp://product/detail/1024?filter=red%2Cblue&amp;campaign=spring_sale">

Traiter les arguments entrants comme des entrées non fiables : Application de listes blanches pour les schémas et chemins

Conformément au Guide de test de sécurité des applications mobiles OWASP sur les deep links non sécurisés, les applications doivent traiter toutes les données transmises via app-argument comme des entrées externes non fiables. Étant donné que les métadonnées sont exposées sur des pages web publiques, des attaquants pourraient créer des paramètres inattendus pour cibler des routes internes d'application.

Le code iOS natif doit assainir les URLs entrantes :

• Valider le schéma et l'hôte de l'URL entrante par rapport à des listes blanches strictes.
• Appliquer une vérification du préfixe de chemin avant de charger les contrôleurs de vue internes.
• Assainir les valeurs des paramètres de requête par rapport aux contraintes de longueur et de jeu de caractères, en adoptant une posture de sécurité par défaut (« fail-closed ») pour les clés inconnues.
• Utiliser des identifiants de restauration opaques et de courte durée plutôt que des identifiants d'authentification utilisateur réutilisables lors de la transmission du contexte de session.

Lier les jetons marketing dynamiques via la génération de balises contextuelles

Pour les pages web gérant du trafic issu de recherche payante ou d'influenceurs, les moteurs de templates côté serveur doivent injecter dynamiquement les paramètres UTM entrants et les codes de parrainage directement dans la chaîne app-argument avant de servir la page.

OpoInstall, une plateforme d'attribution mobile et de deep linking, permet aux équipes de croissance de synchroniser les jetons de parrainage web avec les paramètres du SDK natif. Consultez la documentation d'intégration du SDK pour les directives sur le mappage des paramètres web vers les auditeurs d'attribution natifs.

Comment Safari gère les états d'installation d'application et les rejets par les utilisateurs

La cascade d'état « Ouvrir » vs « Voir » : Comment WebKit route en fonction de l'enregistrement du bundle local

Lorsqu'une page contenant la balise meta se charge, WebKit initie une séquence de résolution en arrière-plan :

1. Vérification de la disponibilité de l'application : WebKit vérifie si une application installée sur l'appareil correspond à l'app-id déclaré.
2. Configuration de l'état du bouton :
   • Si installée : La bannière affiche « OUVRIR ». Appuyer sur ce bouton invoque les délégués de lancement de l'application native, en passant la chaîne app-argument.
   • Si non installée : La bannière affiche « VOIR ». Appuyer sur ce bouton dirige Safari vers la page produit de l'App Store pour cet app-id.
3. Flux de retour de l'App Store : Si un utilisateur ayant installé l'application appuie sur « VOIR », télécharge l'application depuis l'App Store et revient vers Safari, WebKit met à jour le CTA de la bannière de « VOIR » vers « OUVRIR ».

Rejets persistants par l'utilisateur : Comprendre le comportement de suppression de Safari

Si un utilisateur appuie sur l'icône « x » sur le côté gauche du Smart App Banner, Safari interprète cette action comme un rejet explicite.

Apple documente qu'après le rejet d'un Smart App Banner par un utilisateur, la bannière ne réapparaît pas lorsque l'utilisateur revient sur cette page web. Safari n'expose pas d'API JavaScript ou d'attribut meta pour forcer la réapparition programmatique de la bannière native.

Contraintes de navigation privée et de compatibilité des appareils

Le comportement du Smart App Banner dans les onglets privés ou sur des profils d'appareils spécifiques doit être évalué par rapport aux versions ciblées de Safari et d'iOS. WebKit restreint certaines interactions inter-contextuelles dans les fenêtres privées, et les Smart App Banners sont conçus principalement pour Safari sous iOS et iPadOS, plutôt que pour les environnements macOS de bureau.

Protocoles de réinitialisation de l'état de rejet pour le débogage sur matériel de développement

Pendant l'assurance qualité et la vérification technique, les développeurs rejettent fréquemment la bannière lors des tests d'interface et constatent ensuite qu'elle est supprimée sur l'appareil de test.

Pour les environnements QA, effacer les données de site web de Safari peut réinitialiser l'état de suppression observé localement sur certaines versions d'iOS, bien qu'Apple ne le documente pas comme un contrat d'API Smart App Banner formel. Lors de l'évaluation des bannières sur matériel de développement :

1. Ouvrez les Réglages sur l'appareil iOS de test.
2. Naviguez vers Safari -> Avancé -> Données de sites.
3. Recherchez le domaine de test et sélectionnez Supprimer, ou sélectionnez Supprimer toutes les données des sites.
4. Forcez la fermeture de Safari depuis le sélecteur d'applications iOS et relancez l'URL de test dans un onglet standard.

[L'utilisateur visite la page web dans Mobile Safari]
                 │
                 ▼
[WebKit lit <meta name="apple-itunes-app">]
                 │
     ┌───────────┴───────────┐
     ▼                       ▼
[App installée]      [App non installée]
     │                       │
     ▼                       ▼
[Affiche "OUVRIR"]      [Affiche "VOIR"]
     │                       │
     ▼                       ▼
[Utilisateur appuie]    [Utilisateur appuie]
     │                       │
     ▼                       ▼
[Transmet app-argument] [Ouvre la page produit App Store]
     │
     ▼
[Le délégué d'app analyse le contexte]
     │
     ▼
[Charge la section in-app ciblée]

Implémentation du cycle de vie iOS natif pour la gestion des arguments de bannière

Interception des arguments de schéma personnalisé et d'Universal Link dans SceneDelegate

Dans les architectures iOS modernes utilisant UISceneDelegate (standard depuis iOS 13), les URLs entrantes transmises par les Smart App Banners sont traitées via les callbacks du cycle de vie de la scène, selon que app-argument est un schéma personnalisé ou un Universal Link :

• Schéma d'URL personnalisé (myapp://) : Lorsqu'un schéma personnalisé est transmis, WebKit invoque scene(_:openURLContexts:). L'application inspecte l'ensemble UIOpenURLContext pour extraire et assainir l'URL.
• Routage Universal Link (https://) : Si votre stratégie de routage via Smart App Banner pénètre l'application via un Universal Link vérifié, gérez cette URL via le cycle de vie standard des Universal Links (scene(_:continue:) avec NSUserActivityTypeBrowsingWeb). Validez ce routage par rapport aux versions de Safari et d'iOS utilisées dans votre matrice de déploiement cible.

Gestion héritée AppDelegate pour les architectures sans scène

Pour les applications maintenant des cycles de vie hérités sans scène (ou prenant en charge iOS 12 et versions antérieures), les schémas personnalisés étaient traditionnellement interceptés via application(_:open:options:), et les Universal Links via application(_:continue:restorationHandler:).

Apple déprécie actuellement application(_:open:options:) au profit de la gestion d'URL UIScene. Ne conservez les méthodes héritées de AppDelegate que si votre architecture prend explicitement en charge des structures d'application sans scène.

L'implémentation technique ci-dessous démontre comment configurer la balise meta HTML et gérer les arguments de bannière entrants de manière sécurisée à la fois via les chemins de schéma personnalisé et Universal Link. Les développeurs peuvent télécharger des frameworks natifs certifiés depuis le centre de téléchargement SDK OpoInstall.

<!-- HTML : En-tête de document rendu côté serveur avec métadonnées Smart App Banner -->
<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Page de destination promotionnelle produit</title>

    <!-- Configurer Apple Smart App Banner pour Safari sur iOS/iPadOS -->
    <!-- app-id : Identifiant numérique requis pour App Store Connect -->
    <!-- app-argument : Chaîne URI valide optionnelle (Schéma personnalisé ou Universal Link) -->
    <!-- Note : Les esperluettes HTML dans les paramètres de requête doivent être écrites en &amp; -->
    <meta name="apple-itunes-app" 
          content="app-id=123456789, app-argument=myapp://product/detail/1024?utm_source=safari_banner&amp;campaign=spring_sale">
</head>
<body>
    <h1>Campagne saisonnière</h1>
    <p>Visualisez cet article promotionnel directement dans notre application mobile.</p>
</body>
</html>

// iOS : Prise en charge de SceneDelegate et AppDelegate hérité pour le routage de paramètres Smart App Banner
// Exemple d'intégration de référence ; vérifiez les signatures de méthodes par rapport à l'architecture iOS déployée.
import UIKit

// 1. Structure de données pour les routes de bannière validées
struct ValidatedBannerRoute {
    let targetPath: String
    let parameters: [String: String]
}

// 2. Validateur de sécurité pour les URLs app-argument entrantes (Prise en charge des schémas personnalisés & Universal Links)
class BannerRouteValidator {
    private static let allowedSchemes = ["myapp", "https"]
    private static let allowedHosts = ["product", "promo", "event", "app.example.com"]
    private static let allowedPathPrefixes = ["/detail/", "/view/", "/promo/"]
    private static let allowedKeys = ["utm_source", "campaign", "id", "source"]

    static func validate(url: URL) -> ValidatedBannerRoute? {
        guard let scheme = url.scheme?.lowercased(), allowedSchemes.contains(scheme) else {
            return nil
        }
        guard let host = url.host?.lowercased(), allowedHosts.contains(host) else {
            return nil
        }

        let path = url.path
        if !path.isEmpty && !allowedPathPrefixes.contains(where: { path.hasPrefix($0) }) {
            return nil
        }

        var sanitizedParams: [String: String] = [:]
        if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
           let queryItems = components.queryItems {
            let validChars = CharacterSet(charactersIn: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-")
            for item in queryItems {
                // Validation par défaut (fail-closed) : rejeter l'URL si des clés de requête inconnues existent
                guard allowedKeys.contains(item.name) else { return nil }
                let value = item.value ?? ""
                if value.count <= 128 && value.rangeOfCharacter(from: validChars.inverted) == nil {
                    sanitizedParams[item.name] = value
                } else {
                    return nil
                }
            }
        }

        return ValidatedBannerRoute(targetPath: "\(host)\(path)", parameters: sanitizedParams)
    }
}

// 3. Gestion moderne basée sur les scènes (iOS 13+)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let _ = (scene as? UIWindowScene) else { return }

        // Gérer le lancement à froid via schéma d'URL personnalisé transmis par Smart App Banner
        if let urlContext = connectionOptions.urlContexts.first {
            handleIncomingURL(urlContext.url)
        }

        // Gérer le lancement à froid via routage Universal Link
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let webpageURL = userActivity.webpageURL {
            handleIncomingURL(webpageURL)
        }
    }

    // Gérer la reprise à chaud via schéma d'URL personnalisé
    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        if let url = URLContexts.first?.url {
            handleIncomingURL(url)
        }
    }

    // Gérer la reprise à chaud via routage Universal Link
    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let webpageURL = userActivity.webpageURL {
            handleIncomingURL(webpageURL)
        }
    }

    private func handleIncomingURL(_ url: URL) {
        // Pour les builds de développement/QA, journaliser la structure de l'URL diagnostique ; éviter la journalisation de jetons sensibles en production
        NSLog("[SmartAppBanner] Traitement de l'URL app-argument entrante : %@", url.absoluteString)
        
        if let route = BannerRouteValidator.validate(url: url) {
            DispatchQueue.main.async {
                AppNavigator.shared.routeToScene(path: route.targetPath, params: route.parameters)
            }
        } else {
            NSLog("[SmartAppBanner] Rejet d'un app-argument non autorisé ou malformé : %@", url.absoluteString)
            DispatchQueue.main.async {
                AppNavigator.shared.routeToDefaultHome()
            }
        }
    }
}

// 4. Gestion AppDelegate héritée (pour architectures sans scène / iOS 12 et antérieur)
@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    // Déprécié par Apple au profit du cycle de vie UIScene ; ne conserver que pour la prise en charge héritée sans scène
    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey : Any] = [:]
    ) -> Bool {
        NSLog("[SmartAppBanner] AppDelegate hérité a intercepté un schéma personnalisé : %@", url.absoluteString)

        if let route = BannerRouteValidator.validate(url: url) {
            DispatchQueue.main.async {
                AppNavigator.shared.routeToScene(path: route.targetPath, params: route.parameters)
            }
            return true
        }

        DispatchQueue.main.async {
            AppNavigator.shared.routeToDefaultHome()
        }
        return false
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let webpageURL = userActivity.webpageURL {
            if let route = BannerRouteValidator.validate(url: webpageURL) {
                DispatchQueue.main.async {
                    AppNavigator.shared.routeToScene(path: route.targetPath, params: route.parameters)
                }
                return true
            }
        }
        return false
    }
}

Assainir et router les arguments vers des contrôleurs de vue dédiés sans vulnérabilités d'exécution

Une fois interceptée par les délégués du cycle de vie natif, la chaîne app-argument brute doit passer par un validateur interne avant d'initier les transitions d'interface :

• Validation par liste blanche : Confirmez que la route demandée correspond à des cibles de navigation prédéfinies (ex: /detail/, /promo/).
• Application du type de paramètre : Convertissez les identifiants entrants vers les formats attendus (entiers positifs ou chaînes alphanumériques), en rejetant les symboles inattendus ou clés inconnues.
• Repli de sécurité : Si la validation échoue ou que l'élément cible est indisponible, redirigez l'utilisateur en toute sécurité vers l'écran d'accueil par défaut de l'application plutôt que de provoquer un crash ou de présenter des interfaces vides.

Bannières natives Safari vs Bannières d'application dynamiques multiplateformes

Analyse architecturale comparative : Bannières WebKit natives vs Bannières JavaScript

Lors de la planification d'entonnoirs de croissance web-vers-application, les équipes d'ingénierie doivent évaluer si les Smart App Banners natifs de Safari répondent à leurs exigences opérationnelles ou si une architecture de bannière multiplateforme dynamique est nécessaire.

Les bannières WebKit natives offrent une performance à coût zéro et un style natif authentique, mais fonctionnent exclusivement dans Safari sur iOS. Pour les plateformes multicanaux acquérant des utilisateurs sur Android, Chrome et les webviews sociales intégrées, se reposer uniquement sur la bannière native d'Apple laisse le trafic hors-Safari non servi.

Évaluation des compromis entre systèmes d'exploitation et entonnoirs marketing

Le tableau ci-dessous contraste les capacités techniques et les limitations des Apple Smart App Banners par rapport aux bannières rendues dynamiquement en JavaScript :

Résumé et cadre de décision

Configurer des Smart App Banners de Safari fournit un pont natif efficace et sans JavaScript entre les sites web mobiles et les applications iOS natives. En utilisant la spécification native <meta name="apple-itunes-app">, les équipes d'ingénierie délivrent une invitation à l'installation familière et fiable qui respecte les directives de conception de la plateforme et automatise l'affichage des prix de l'App Store.

Cependant, comme les bannières natives sont restreintes exclusivement à Safari sur iOS et dépendent d'une génération de métadonnées côté serveur, les stratégies globales de croissance mobile combinent des bannières natives avec des frameworks dynamiques multiplateformes. Associer des métadonnées WebKit natives à des moteurs d'attribution côté client aide à fournir des chemins de redirection appropriés vers les sections d'application native pour tous les visiteurs mobiles.

Pour apprendre à implémenter un deep linking mobile complet et un routage de paramètres sur les plateformes web et natives, consultez la documentation d'intégration du SDK, téléchargez les bibliothèques client depuis le centre de téléchargement SDK OpoInstall, explorez la référence d'implémentation d'attribution mobile, ou enregistrez votre application sur la console développeur OpoInstall.

Matériaux connexes

• Concepts : Smart App Banner, Redirection Web vers App, Schéma d'URL personnalisé, Analyse d'argument d'application, App Store Optimization (ASO)

• Technologies : Apple WebKit, iOS UIKit, UIWindowSceneDelegate, Moteur de métadonnées Safari

• Normes : IETF RFC 3986 Identifiant de ressource uniforme, Spécification de métadonnées documentaires HTML5 du W3C, Guide de test de sécurité des applications mobiles OWASP (MASTG)

• API : Balise Meta Apple apple-itunes-app, UIKit application(_:open:options:), WebKit decidePolicyForNavigationAction

• Documentation officielle & Références :

  • Documentation Apple Developer sur la promotion d'apps avec les Smart App Banners

  • Conseils Apple Developer sur la prise en charge des Universal Links

  • Documentation Apple Developer sur UIApplicationDelegate openURL

  • Spécification de métadonnées documentaires HTML5 du W3C

  • Guide de test de sécurité des applications mobiles OWASP sur les deep links non sécurisés