Como configurar os Smart App Banners do Safari para impulsionar redirecionamentos no iOS

Como adiciono um Smart App Banner ao meu site? Adicionar um Smart App Banner requer inserir a meta tag apple-itunes-app no head do HTML do seu site, definindo seu app-id exclusivo e passando parâmetros de roteamento via app-argument para habilitar aberturas nativas do aplicativo no Safari e fallbacks para a App Store.

Um Apple Smart App Banner é um componente promocional nativo do Safari, declarado via meta tag HTML, que exibe um prompt discreto de download ou abertura no topo das páginas da web no iOS e iPadOS. Renderizado diretamente pelo WebKit, ele determina a disponibilidade local do aplicativo, apresentando um botão "Abrir" que transmite parâmetros contextuais para aplicativos instalados, ou um botão "Visualizar" que encaminha usuários sem o aplicativo para a App Store.

Por que os Smart App Banners do Safari continuam essenciais para a aquisição no iOS

Integração Nativa com o Safari: Sem sobrecarga de JavaScript e renderização consistente em nível de SO

O Smart App Banner nativo da Apple representa uma ponte integrada entre o conteúdo da web e os aplicativos iOS. Diferente de banners personalizados em JavaScript que exigem manipulação do DOM no lado do cliente, bibliotecas de estilo de terceiros e recálculos contínuos de layout, os Smart App Banners nativos são renderizados diretamente pelo WebKit em nível de sistema operacional.

Como o WebKit gerencia o layout nativamente, o banner produz zero sobrecarga de execução de JavaScript e não bloqueia a thread principal do navegador durante o carregamento inicial da página. O banner renderiza de forma consistente em diferentes formatos de iOS e iPadOS, adaptando-se suavemente a rotações de viewport, Safe Area insets em hardware moderno de iPhone e configurações de acessibilidade do sistema, como o Dynamic Type.

Eliminando o atrito de busca na loja: Busca automática de ícone, título, avaliação e preço

Configurar um prompt promocional padrão na web normalmente exige que as equipes de marketing consultem manualmente as APIs da App Store para exibir ícones de aplicativos atuais, títulos de desenvolvedor, preços localizados e avaliações agregadas. Quando os metadados do aplicativo mudam—como uma atualização de ícone para uma campanha sazonal ou uma promoção de preço de lançamento—banners personalizados estáticos tornam-se rapidamente obsoletos.

Os Smart App Banners nativos eliminam esse ônus de manutenção. Ao ler um app-id válido, o WebKit comunica-se diretamente com os serviços locais da App Store para buscar automaticamente os metadados de produção do aplicativo. O Safari exibe o ícone oficial da App Store, título, avaliação atual e preço localizado (por exemplo, "Gratuito" ou moeda local) sem exigir que desenvolvedores web façam hardcoding de ativos de marketing ou gerenciem tabelas de strings localizadas.

Detecção de estado em nível de sistema: Como o WebKit distingue usuários com e sem o app instalado

Um desafio persistente no roteamento web-to-app é identificar se o dispositivo visitante possui o aplicativo nativo instalado. Por motivos de privacidade e segurança, os sandboxes dos navegadores proíbem estritamente que o JavaScript da página web consulte registros de aplicativos locais ou inspecione listas de pacotes instalados.

Os Smart App Banners nativos resolvem esse desafio na camada de plataforma. O Safari determina se o aplicativo está disponível no dispositivo usando mecanismos em nível de sistema indisponíveis para o JavaScript da página web. Se o aplicativo correspondente ao app-id declarado estiver instalado, o Safari renderiza uma call-to-action (CTA) de "ABRIR". Se o aplicativo estiver ausente, o banner exibe uma CTA de "VISUALIZAR". Essa detecção ocorre inteiramente dentro do limite do sistema operacional, impedindo o fingerprinting no lado do cliente enquanto ajuda os visitantes a receber um prompt preciso e acionável.

Como estruturar corretamente a sintaxe da meta tag Apple iTunes App

Dissecando atributos centrais da tag: app-id e app-argument

O Smart App Banner nativo é configurado através de um único elemento HTML <meta> colocado dentro do <head> do documento. O atributo name deve ser definido exatamente como apple-itunes-app, enquanto o atributo content aceita uma string delimitada por vírgulas de pares chave-valor:

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

A documentação atual do Smart App Banner da Apple define dois parâmetros primários suportados:

• app-id (Obrigatório): O identificador numérico exclusivo atribuído ao aplicativo no App Store Connect. Este identificador permite que o WebKit resolva a listagem correta na loja e consulte a disponibilidade local do aplicativo.
• app-argument (Opcional): Uma string de URI válida (como um Custom URL Scheme ou um Universal Link HTTPS) que o Safari passa para o aplicativo nativo quando o usuário toca em "ABRIR".

Referências mais antigas de Smart App Banners documentavam um parâmetro adicional, affiliate-data, usado para rastreamento de parceiros. Como a documentação atual da Apple não lista mais affiliate-data como um parâmetro padrão, trate metadados de afiliados como comportamento legado, a menos que verificado separadamente em relação às diretrizes atuais de parceiros de Serviços Apple.

Regras de formatação rigorosas: Validando delimitadores de vírgula e citações de atributos

O analisador de metadados do WebKit impõe regras estruturais rígidas. Erros comuns de sintaxe farão com que o Safari ignore a tag:

• Atributos dentro da string content devem ser separados por vírgulas, não por ponto e vírgula ou pipes.
• Valores de atributo não devem conter espaços em branco não codificados ou caracteres de vírgula brutos.
• Valores de atributo não devem ser envolvidos em aspas aninhadas dentro da string do atributo content principal.

Uma tag corretamente formada segue a especificação abaixo:

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

Requisitos de renderização no lado do servidor: Renderizando metadados do Smart App Banner de forma confiável no head do documento inicial

Arquiteturas de front-end tentam frequentemente injetar ou atualizar a tag <meta name="apple-itunes-app"> dinamicamente usando frameworks JavaScript de front-end (como React, Vue ou Angular) após avaliar parâmetros de rota de Single-Page Application (SPA).

Para um comportamento determinístico do Smart App Banner, renderize a meta tag apple-itunes-app no <head> inicial do documento. A Apple documenta a geração de app-argument no lado do servidor; não dependa de mutações do DOM no lado do cliente pós-carregamento via document.head.appendChild() ou modificação de atributos, pois o WebKit analisa os metadados durante a avaliação inicial do stream do documento e pode não reavaliar configurações de banner em mudanças subsequentes no DOM.

Validando conformidade de meta tag do WebKit com os padrões de metadados de documento W3C

O elemento apple-itunes-app está em conformidade com a Especificação de Metadados de Documento HTML5 da W3C, que permite extensões específicas de fornecedor dentro de elementos <meta> padrão. O WebKit adere aos padrões de análise de URI RFC 3986 ao avaliar o payload app-argument aninhado.

Mecanismos técnicos de passagem de parâmetros via App Argument

Codificando payloads de deep link na string app-argument: Esquemas vs. URLs HTTPS

O atributo app-argument estabelece o roteamento contextual para o aplicativo nativo. Equipes web podem fornecer um URI scheme personalizado ou um Universal Link HTTPS:

1. Custom URL Scheme (myapp://product/detail/1024?id=1024): Inicia o aplicativo e entrega o payload aos delegados nativos de URL personalizados. Esquemas personalizados fornecem aberturas diretas, mas não oferecem um fallback web independente se copiados fora do Safari.
2. HTTPS Universal Link (https://app.example.com/detail/1024?id=1024): Passa uma URL de domínio verificada. Isso garante uma análise de parâmetros unificada entre delegados de Universal Link enquanto mantém um destino web totalmente acessível em outras plataformas.

Gerenciando o escape de parâmetros de consulta para evitar o truncamento de URL no WebKit

Ao passar tokens de rastreamento, códigos de referência ou payloads aninhados dentro do app-argument, desenvolvedores devem estruturar a URL corretamente. Como o WebKit usa vírgulas para separar atributos dentro da string content, uma vírgula não codificada dentro de um parâmetro de deep link truncará o app-argument prematuramente.

Preserve a sintaxe de URL padrão (scheme://host/path?query) enquanto codifica caracteres reservados—como vírgulas, espaços ou delimitadores aninhados—dentro de valores de parâmetros de consulta. Em arquivos de código-fonte HTML, quaisquer e-comerciais (&) que conectem múltiplos parâmetros de consulta devem ser devidamente escapados como &:

<!-- Malformado: Vírgula não codificada trunca a análise do atributo -->
<meta name="apple-itunes-app" content="app-id=123, app-argument=myapp://route?filter=red,blue">

<!-- Válido: Estrutura de URL padrão com e-comercial escapado em HTML e valores de parâmetros codificados -->
<meta name="apple-itunes-app" content="app-id=123, app-argument=myapp://product/detail/1024?filter=red%2Cblue&amp;campaign=spring_sale">

Tratando argumentos recebidos como entrada não confiável: Impondo listas de permissões de esquema e caminho

De acordo com a Orientação do Guia de Teste de Segurança de Aplicativos Móveis da OWASP sobre Deep Links Inseguros, os aplicativos devem tratar todos os dados entregues via app-argument como entrada externa não confiável. Como os metadados são expostos em páginas web públicas, invasores poderiam criar parâmetros inesperados para direcionar rotas internas do aplicativo.

O código nativo do iOS deve higienizar as URLs recebidas:

• Valide o esquema e host da URL recebida contra listas de permissões (allowlists) rígidas.
• Imponha a verificação de prefixo de caminho antes de carregar view controllers internos.
• Higienize valores de parâmetros de consulta contra restrições de comprimento e conjunto de caracteres, adotando uma postura de falha fechada (fail-closed) para chaves desconhecidas.
• Use identificadores de restauração opacos e de curta duração, em vez de credenciais de autenticação de usuário reutilizáveis ao passar o contexto da sessão.

Vinculando tokens de marketing dinâmicos usando geração de tag contextual

Para páginas web que lidam com tráfego pago ou de influenciadores, motores de template no lado do servidor devem injetar dinamicamente parâmetros UTM e códigos de referência recebidos diretamente na string app-argument antes de servir a página.

O OpoInstall, uma plataforma de atribuição móvel e deep linking, permite que equipes de crescimento sincronizem tokens de referência baseados na web com parâmetros do SDK nativo. Consulte a documentação de integração do SDK para diretrizes sobre como mapear parâmetros web para listeners de atribuição nativos.

Como o Safari lida com estados de aplicativos instalados e dispensas de usuários

A cascata de estado Abrir vs. Visualizar: Como o WebKit roteia com base no registro de bundle local

Quando uma página contendo a meta tag é carregada, o WebKit inicia uma sequência de resolução em segundo plano:

1. Verificação de disponibilidade do aplicativo: O WebKit verifica se um aplicativo instalado no dispositivo corresponde ao app-id declarado.
2. Configuração do estado do botão:
   • Se instalado: O banner exibe "ABRIR". Tocar neste botão invoca delegados de inicialização do aplicativo nativo, passando a string app-argument.
   • Se desinstalado: O banner exibe "VISUALIZAR". Tocar neste botão direciona o Safari para a página do produto na App Store para aquele app-id.
3. Fluxo de retorno da App Store: Se um usuário que não possui o app toca em "VISUALIZAR", faz o download do aplicativo na App Store e retorna ao Safari, o WebKit atualiza a CTA do banner de "VISUALIZAR" para "ABRIR".

Dispensas persistentes do usuário: Entendendo o comportamento de supressão do Safari

Se um usuário tocar no ícone "x" no lado esquerdo do Smart App Banner, o Safari interpreta essa ação como uma dispensa explícita.

A Apple documenta que, após um usuário dispensar um Smart App Banner, o banner não reaparece quando o usuário retorna a essa página web. O Safari não expõe uma API de JavaScript ou meta atributo para forçar a reexibição programática do banner nativo.

Navegação privada e restrições de compatibilidade de dispositivo

O comportamento do Smart App Banner em abas privadas ou perfis de dispositivos específicos deve ser avaliado em relação às versões de Safari e iOS direcionadas. O WebKit restringe certas interações entre contextos em janelas privadas, e os Smart App Banners são projetados principalmente para o Safari no iOS e iPadOS, e não para ambientes desktop macOS.

Protocolos de depuração para redefinir o estado de dispensa em hardware de desenvolvimento

Durante a garantia de qualidade e verificação de engenharia, desenvolvedores frequentemente dispensam o banner durante testes de UI e, posteriormente, encontram-no suprimido no dispositivo de teste.

Para ambientes de QA, limpar os dados do site no Safari pode redefinir o estado de supressão observado localmente em algumas versões do iOS, embora a Apple não documente isso como um contrato oficial de API do Smart App Banner. Ao avaliar banners em hardware de desenvolvimento:

1. Abra Ajustes no dispositivo de teste iOS.
2. Navegue para Safari -> Avançado -> Dados dos Sites.
3. Procure pelo domínio de teste e selecione Apagar, ou selecione Remover Todos os Dados dos Sites.
4. Forçar o encerramento do Safari no seletor de aplicativos do iOS e relançar a URL de teste em uma aba padrão.

[Usuário visita página web no Mobile Safari]
                 │
                 ▼
[WebKit lê <meta name="apple-itunes-app">]
                 │
     ┌───────────┴───────────┐
     ▼                       ▼
[App instalado]      [App não instalado]
     │                       │
     ▼                       ▼
[Renderiza "ABRIR"]  [Renderiza "VISUALIZAR"]
     │                       │
     ▼                       ▼
[Usuário toca no botão] [Usuário toca no botão]
     │                       │
     ▼                       ▼
[Passa app-argument]  [Abre página do produto na App Store]
     │
     ▼
[Delegate do App analisa contexto]
     │
     ▼
[Carrega cena in-app direcionada]

Implementação de ciclo de vida nativo do iOS para lidar com argumentos do banner

Interceptando argumentos de Custom Scheme e Universal Link no SceneDelegate

Em arquiteturas modernas de iOS utilizando UISceneDelegate (padrão no iOS 13 e posterior), as URLs de entrada entregues por Smart App Banners são processadas por callbacks de ciclo de vida de cena, dependendo se o app-argument é um esquema personalizado ou um Universal Link:

• Custom URL Scheme (myapp://): Quando um esquema personalizado é entregue, o WebKit invoca scene(_:openURLContexts:). O aplicativo inspeciona o conjunto UIOpenURLContext para extrair e higienizar a URL.
• Roteamento de Universal Link (https://): Se a sua estratégia de roteamento de Smart App Banner entrar no aplicativo através de um Universal Link verificado, manipule essa URL através do ciclo de vida padrão do Universal Link (scene(_:continue:) com NSUserActivityTypeBrowsingWeb). Valide esse roteamento em relação às versões de Safari e iOS usadas na sua matriz de implantação.

Manipulação legada no AppDelegate para arquiteturas sem Scene

Para aplicativos que mantêm ciclos de vida legados e sem cena (ou que suportam iOS 12 e anterior), esquemas personalizados eram tradicionalmente interceptados via application(_:open:options:), e Universal Links via application(_:continue:restorationHandler:).

A Apple atualmente descontinua application(_:open:options:) em favor do tratamento de URL do UIScene. Mantenha métodos de AppDelegate legados apenas se sua arquitetura suportar explicitamente estruturas de aplicativos que não sejam baseadas em cena.

A implementação técnica abaixo demonstra como configurar a meta tag HTML e manipular argumentos de banner recebidos com segurança, tanto por esquema personalizado quanto por Universal Link. Desenvolvedores podem baixar frameworks nativos certificados no centro de download do SDK OpoInstall.

<!-- HTML: Head do documento renderizado no servidor com metadados do Smart App Banner -->
<!DOCTYPE html>
<html lang="pt-br">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Página de Destino de Promoção de Produto</title>

    <!-- Configure o Apple Smart App Banner para Safari no iOS/iPadOS -->
    <!-- app-id: Identificador numérico obrigatório do App Store Connect -->
    <!-- app-argument: String de URI válida opcional (Custom Scheme ou Universal Link) -->
    <!-- Nota: E-comerciais de HTML em parâmetros de consulta devem ser escritos como &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>Campanha Sazonal</h1>
    <p>Veja este item promocional diretamente dentro do nosso aplicativo móvel.</p>
</body>
</html>

// iOS: Suporte a SceneDelegate e AppDelegate Legado para Roteamento de Parâmetros do Smart App Banner
// Exemplo de integração de referência; verifique as assinaturas de método em relação à arquitetura iOS implantada.
import UIKit

// 1. Estrutura de dados para Rotas de Banner Validadas
struct ValidatedBannerRoute {
    let targetPath: String
    let parameters: [String: String]
}

// 2. Validador de Segurança para URLs app-argument de entrada (Suportando Custom Schemes & 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 {
                // Validação de falha fechada: rejeita URL se chaves de consulta desconhecidas existirem
                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. Manipulação baseada em cena moderna (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 }

        // Lidar com inicialização fria via custom URL scheme entregue pelo Smart App Banner
        if let urlContext = connectionOptions.urlContexts.first {
            handleIncomingURL(urlContext.url)
        }

        // Lidar com inicialização fria via roteamento de Universal Link
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let webpageURL = userActivity.webpageURL {
            handleIncomingURL(webpageURL)
        }
    }

    // Lidar com retomada quente via custom URL scheme
    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        if let url = URLContexts.first?.url {
            handleIncomingURL(url)
        }
    }

    // Lidar com retomada quente via roteamento de Universal Link
    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let webpageURL = userActivity.webpageURL {
            handleIncomingURL(webpageURL)
        }
    }

    private func handleIncomingURL(_ url: URL) {
        // Para builds de desenvolvimento/QA, registre a estrutura da URL de diagnóstico; evite registrar tokens sensíveis em produção
        NSLog("[SmartAppBanner] Processando URL app-argument de entrada: %@", url.absoluteString)
        
        if let route = BannerRouteValidator.validate(url: url) {
            DispatchQueue.main.async {
                AppNavigator.shared.routeToScene(path: route.targetPath, params: route.parameters)
            }
        } else {
            NSLog("[SmartAppBanner] Rejeitado app-argument não autorizado ou malformado: %@", url.absoluteString)
            DispatchQueue.main.async {
                AppNavigator.shared.routeToDefaultHome()
            }
        }
    }
}

// 4. Manipulação AppDelegate Legada (para arquiteturas sem Scene / iOS 12 e anterior)
@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    // Descontinuado pela Apple em favor do ciclo de vida UIScene; mantenha apenas para suporte legado
    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey : Any] = [:]
    ) -> Bool {
        NSLog("[SmartAppBanner] AppDelegate legada interceptou esquema personalizado: %@", 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
    }
}

Higienizando e roteando argumentos para View Controllers dedicados sem vulnerabilidades de execução

Uma vez interceptada pelos delegados de ciclo de vida nativos, a string app-argument bruta deve passar por um validador interno antes de conduzir transições de UI:

• Validação de lista de permissões: Confirme se a rota solicitada corresponde aos destinos de navegação predefinidos (ex.: /detail/, /promo/).
• Imposição de tipo de parâmetro: Converta IDs recebidos para os formatos esperados (como números inteiros positivos ou strings alfanuméricas), rejeitando símbolos inesperados ou chaves desconhecidas.
• Fallback seguro: Se a validação falhar ou o item de destino estiver indisponível, encaminhe o usuário com segurança para a tela inicial padrão do aplicativo, em vez de travar ou apresentar interfaces vazias.

Banners Nativos do Safari Versus Banners de Aplicativos Dinâmicos Multiplataforma

Análise arquitetural comparativa: Banners WebKit nativos vs. Banners JavaScript

Ao planejar funis de crescimento web-to-app, equipes de engenharia devem avaliar se os Smart App Banners do Safari atendem aos seus requisitos operacionais ou se uma arquitetura de banner dinâmica multiplataforma é necessária.

Banners nativos do WebKit entregam desempenho de custo zero e estilo de SO autêntico, mas operam exclusivamente dentro do Safari no iOS. Para plataformas de múltiplos canais que adquirem usuários através de Android, Chrome e webviews sociais incorporadas, confiar apenas no banner nativo da Apple deixa o tráfego fora do Safari sem atendimento.

Avaliando trade-offs de recursos em diferentes sistemas operacionais e funis de marketing

A tabela abaixo contrasta as capacidades técnicas e limitações dos Smart App Banners da Apple em relação a banners renderizados dinamicamente via JavaScript:

Resumo e Estrutura de Decisão

Configurar Smart App Banners no Safari oferece uma ponte nativa eficiente e sem JavaScript entre sites móveis e aplicativos iOS nativos. Ao utilizar a especificação nativa <meta name="apple-itunes-app">, equipes de engenharia entregam um prompt de instalação familiar e confiável que respeita as diretrizes de design da plataforma e automatiza a exibição de preços da App Store.

No entanto, como os banners nativos são restritos exclusivamente ao Safari no iOS e dependem da geração de metadados no lado do servidor, estratégias abrangentes de crescimento móvel combinam banners nativos com frameworks dinâmicos multiplataforma. Emparelhar metadados nativos do WebKit com motores de atribuição no lado do cliente ajuda a fornecer caminhos de redirecionamento apropriados para cenas de aplicativos nativos entre todos os visitantes móveis.

Para saber como implementar deep linking móvel abrangente e roteamento de parâmetros entre plataformas web e nativas, consulte a documentação de integração do SDK, baixe as bibliotecas de cliente no centro de download do SDK OpoInstall, explore a referência de implementação de atribuição móvel ou registre seu aplicativo no console de desenvolvedor OpoInstall.

Materiais Relacionados

• Conceitos: Smart App Banner, Redirecionamento Web to App, Custom URL Scheme, Análise de App Argument, Otimização da App Store (ASO)

• Tecnologias: Apple WebKit, iOS UIKit, UIWindowSceneDelegate, Safari Metadata Engine

• Padrões: IETF RFC 3986 Uniform Resource Identifier, Especificação de Metadados de Documento HTML5 W3C, Guia de Teste de Segurança de Aplicativos Móveis (MASTG) da OWASP

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

• Documentação Oficial & Referências:

  • Documentação do Desenvolvedor Apple sobre Promoção de Apps com Smart App Banners

  • Orientação do Desenvolvedor Apple sobre Suporte a Universal Links

  • Documentação do Desenvolvedor Apple sobre UIApplicationDelegate openURL

  • Especificação de Metadados de Documento HTML5 da W3C

  • Guia de Teste de Segurança de Aplicativos Móveis da OWASP sobre Deep Links Inseguros