Como Corrigir Incompatibilidade de Bundle ID e App ID Prefix em Links Universais do iOS

opoinstall
2026-08-18
5 min read

Por que a incompatibilidade de Bundle ID interrompe os Links Universais do iOS? Uma incompatibilidade de Bundle ID interrompe os Links Universais quando o Application Identifier assinado do aplicativo não corresponde à entrada correspondente no AASA (appID/appIDs) para o domínio associado, fazendo com que a verificação de domínios associados falhe.

Um Bundle ID (CFBundleIdentifier) é uma string exclusiva que identifica um aplicativo iOS individual dentro do ecossistema da Apple. Em arquiteturas de Links Universais, o Bundle ID é concatenado com o Application Identifier Prefix para formar o Application Identifier, que o sistema operacional valida com o arquivo apple-app-site-association hospedado para autorizar o tratamento nativo de URLs.

Termo Definição
Bundle ID O identificador DNS reverso exclusivo atribuído a um alvo de aplicativo iOS no Xcode (CFBundleIdentifier).
Application Identifier Prefix O prefixo do App ID atribuído nas configurações da conta de Desenvolvedor da Apple (frequentemente, mas nem sempre, idêntico ao Team ID).
Links Universais O mecanismo padrão da Apple para rotear URLs HTTPS da web diretamente para visualizações nativas de aplicativos.
Associated Domains O direito (entitlement) do Xcode que declara quais domínios da web um aplicativo está autorizado a manipular (applinks:).
Arquivo AASA O arquivo JSON (apple-app-site-association) hospedado em um domínio para autorizar o tratamento de URLs de aplicativos.

Cadeia de Diagnóstico Canônica

O diagrama abaixo ilustra a sequência de verificação em várias camadas executada durante a instalação do aplicativo e a validação do domínio:

Layer 1: Signed App Binary
       │
       ├── application-identifier (<Prefix>.<BundleID>)
       ├── com.apple.developer.team-identifier
       └── com.apple.developer.associated-domains (applinks:example.com)
                    │
                    ▼
Layer 2: AASA Delivery & CDN Ingestion
       │ (Apple-managed infrastructure retrieves origin AASA)
                    ▼
Layer 3: AASA Schema & Pattern Matching
       │ (Validates appIDs array and components/paths routing rules)
                    ▼
Layer 4: Device Association State
       │ (Operating system registers verified domains in local database)
                    ▼
Layer 5: Application Routing Execution
       │ (System routes matching URLs to application lifecycle handlers)
Advanced 5-layer technical architecture diagram illustrating the iOS Universal Links verification chain from signed binary entitlements to native app execution on a warm soft cream grid backdrop.

Checklist de Correção Rápida: Rotina de Diagnóstico de 30 Segundos

Quando os Links Universais caírem inesperadamente para o tratamento na web, verifique estes itens em ordem:

  • Extrair Identificador Assinado: Inspecione o direito embutido do binário compilado para obter o application-identifier exato (<Prefix>.<BundleID>).
  • Verificar o Formato do Direito: Confirme se com.apple.developer.associated-domains contém o nome do host exato (por exemplo, applinks:subdomain.domain.com) sem caminhos desnecessários, strings de consulta ou barras finais.
  • Auditar o AASA de Origem: Busque https://subdomain.domain.com/.well-known/apple-app-site-association e certifique-se de que o Application Identifier assinado esteja listado textualmente em appIDs.
  • Validar a Correspondência de Caminho: Confirme se a URL de destino corresponde aos padrões de components ou paths definidos na configuração do AASA.
  • Verificar o Escopo do Domínio: Certifique-se de que o direito de domínio associado cubra o nome do host de destino e que a configuração AASA correspondente esteja disponível para esse nome do host. Para subdomínios, use um nome de host explícito ou a forma de curinga *. suportada, conforme apropriado.
  • Isolar Modos de Desenvolvimento: Use ?mode=developer em compilações assinadas para desenvolvimento para ignorar o armazenamento em cache da CDN da Apple durante a iteração.

Por que a Precisão do Bundle ID e do Application Identifier é Importante

A Anatomia de um Application Identifier

A verificação de Links Universais não avalia o nome de exibição do aplicativo, o esquema de URL interno ou o nome do pacote. De acordo com a documentação da Apple sobre applinks.Details, o modelo de segurança depende estritamente do Application Identifier totalmente qualificado, estruturado como:

Application Identifier=ApplicationIdentifierPrefix  +  "."  +  CFBundleIdentifier\text{Application Identifier} = \text{ApplicationIdentifierPrefix} \;+\; \text{"."} \;+\; \text{CFBundleIdentifier}

Onde:

  • ApplicationIdentifierPrefix: O prefixo do App ID atribuído na configuração da sua conta de Desenvolvedor da Apple (por exemplo, 9JA723G82S). Para muitas contas de desenvolvedor modernas, esse valor corresponde ao Team ID de 10 caracteres, mas os engenheiros devem verificar o prefixo real em seu Portal do Desenvolvedor da Apple em vez de assumir que os dois são intercambiáveis.
  • CFBundleIdentifier (Bundle ID): A string sensível a maiúsculas e minúsculas com o DNS reverso definido nas configurações de compilação do alvo (por exemplo, com.example.mobileapp).

No arquivo JSON apple-app-site-association (AASA) hospedado, essa string composta aparece dentro da matriz appIDs ou nas entradas de dicionário appID (por exemplo, 9JA723G82S.com.example.mobileapp). Se houver discrepância de caracteres, diferença de maiúsculas e minúsculas ou espaço à direita entre o direito embutido do binário compilado e a entrada AASA hospedada, a verificação do domínio falhará.

Uma incompatibilidade de Bundle ID é uma das causas de maior prioridade a serem verificadas durante a triagem de integração, mas não é o único motivo pelo qual um Link Universal pode cair para a web.

Como os Domínios Associados e o AASA Estabelecem uma Associação Bidirecional

Ao contrário dos esquemas de URL personalizados, que qualquer aplicativo instalado pode declarar sem verificação de domínio, os Links Universais estabelecem uma associação segura e bidirecional:

  • Declaração de Aplicativo para Domínio: O aplicativo iOS compilado declara que reivindica a propriedade de um domínio da web específico, incluindo o direito com.apple.developer.associated-domains em sua assinatura de código.
  • Autorização de Domínio para Aplicativo: O domínio da web confirma que concede autorização de roteamento a aplicativos específicos hospedando o arquivo JSON AASA em https://<domain>/.well-known/apple-app-site-association ou https://<domain>/apple-app-site-association.

Durante a instalação ou atualizações de aplicativos, o sistema operacional verifica o direito de Domínios Associados assinado do aplicativo em relação à configuração AASA recuperada para o domínio. O Application Identifier usado para a associação do aplicativo deve corresponder ao identificador correspondente declarado na configuração AASA. Após a correspondência do identificador, a URL solicitada também deve satisfazer as regras configuradas de components ou paths.

O Sintoma da Falha: Por Que Identificadores Incompatíveis Forçam Fallbacks para a Web

Quando ocorre uma incompatibilidade de Application Identifier, o iOS normalmente não exibe uma incompatibilidade de Application Identifier como uma exceção de tempo de execução fatal. Em vez disso, a falha é refletida no estado de verificação de domínios associados, no diagnóstico do dispositivo ou no comportamento de fallback para a web resultante:

  • Tratamento do Sistema: Quando a associação de domínio falha, o sistema não invoca o aplicativo por meio do caminho verificado do Link Universal. Dependendo de como a URL foi aberta e do contexto do navegador ao redor, a URL permanece ou retorna para o tratamento na web, em vez de ser entregue ao aplicativo nativo.
  • Impacto na Experiência do Usuário: Quando um usuário toca em um link da web correspondente em Mensagens, E-mail ou Safari, o sistema falha em reconhecer um mapeamento de aplicativo nativo autorizado e abre a URL da web no navegador.

Consulte Também: Bundle ID ──> Arquitetura de Links Universais

Como a CDN da Apple Busca e Armazena em Cache os Arquivos AASA

O Handshake de Instalação e a Mecânica da CDN da Apple

Quando um aplicativo contendo o direito com.apple.developer.associated-domains é instalado ou atualizado, o sistema estabelece ou atualiza uma relação de domínio associado:

  • Scraper Mediado por CDN: Quando o sistema estabelece ou atualiza uma relação de domínio associado, ele obtém os dados AASA do domínio por meio da infraestrutura de domínios associados da Apple e usa esses dados para verificar a associação.
  • Ciclo de Vida de Cache Independente: A CDN gerenciada pela Apple controla seu próprio ciclo de vida de atualização e cache, portanto, não se deve assumir que uma atualização de origem se torne imediatamente visível através da CDN. Ao testar alterações, use o modo alternativo de desenvolvimento documentado quando apropriado e inspecione o estado de associação do dispositivo.
  • Requisitos do Servidor de Origem: O servidor web de origem deve servir o arquivo AASA via HTTPS com um certificado TLS válido e confiável (certificados autoassinados são rejeicionados), usando o tipo MIME application/json. A hospedagem AASA não deve depender de redirecionamentos HTTP; o endpoint AASA deve retornar o arquivo diretamente com um HTTP 200 OK.

Consistência do Formato JSON AASA

As versões modernas do iOS oferecem suporte à sintaxe granular do dicionário components, mantendo a compatibilidade com versões anteriores com as matrizes legadas paths.

De acordo com a Nota Técnica TN3155 do Desenvolvedor Apple sobre Depuração de Links Universais, dentro de uma determinada entrada details, os desenvolvedores devem usar a estrutura moderna appIDs + components ou a estrutura legada appID + paths; não misture as duas estruturas na mesma entrada, pois configurações mistas podem produzir um comportamento de verificação inesperado.

Exemplos AASA mais antigos incluíam comumente "apps": []. Para implantações direcionadas a lançamentos modernos de sistemas operacionais da Apple, esta chave não é necessária; retenha-a apenas ao dar suporte a versões legadas de SO que a esperam especificamente.

Protocolo de Diagnóstico: Fluxo de Trabalho de Resolução Passo a Passo

Etapa 1: Inspecionar os Direitos do Aplicativo Assinado com codesign

Para determinar se um IPA exportado ou build de depuração contém exatamente o Application Identifier e os Domínios Associados esperados, inspecione a assinatura de código do binário diretamente usando o utilitário de linha de comando codesign do macOS. Verifique application-identifier, com.apple.developer.team-identifier e com.apple.developer.associated-domains juntos.

O perfil de provisionamento mostra quais recursos e domínios o perfil permite; o executável assinado (codesign) mostra o que o binário enviado realmente contém.

Etapa 2: Auditar o Esquema JSON AASA Hospedado

Verifique se o servidor de origem hospeda um arquivo AASA válido que seja publicamente acessível sem autenticação ou redirecionamentos. Observe que exemplos AASA mais antigos incluíam comumente "apps": [], enquanto as configurações modernas direcionadas a lançamentos contemporâneos do iOS omitem esta chave.

O esquema JSON AASA padrão abaixo ilustra o roteamento de caminho adequado usando a estrutura moderna appIDs e components:


```json
{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "9JA723G82S.com.example.mobileapp",
          "9JA723G82S.com.example.mobileapp.staging"
        ],
        "components": [
          {
            "/": "/product/*",
            "comment": "Matches product detail routes"
          },
          {
            "/": "/invite/*",
            "?": { "ref": "?*" },
            "comment": "Matches referral links with custom query parameters"
          },
          {
            "/": "/help/*",
            "exclude": true,
            "comment": "Excludes customer support URLs from native routing"
          }
        ]
      }
    ]
  }
}

Etapa 3: Executar Ferramentas CLI de Diagnóstico (codesign, swcutil, curl)

Nas versões do macOS que fornecem diagnósticos swcutil, use a ferramenta para inspecionar ou validar dados de domínios associados. Como as opções de comando podem variar entre versões de SO e toolchain, confirme as opções disponíveis com swcutil --help antes de executar os fluxos de trabalho de diagnóstico abaixo:

# 0. Confirm available options (syntax may vary by OS and toolchain release)
swcutil --help

# 1. Unpack the exported IPA archive
unzip -q YourApp.ipa -d UnpackedApp

# 2. Extract and inspect signed entitlements directly from the executable binary
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
/usr/libexec/PlistBuddy -c "Print" signed-entitlements.plist

# 3. Check whether the AASA data can be downloaded for the domain using swcutil (macOS diagnostic tool)
sudo swcutil dl -d custom.opwakeup.com

# 4. Validate AASA pattern matching against a specific URL using swcutil
sudo swcutil verify -d custom.opwakeup.com -j ./apple-app-site-association -u https://custom.opwakeup.com/product/123

# 5. Query the Apple-managed Associated Domains CDN diagnostic endpoint directly
curl -i https://app-site-association.cdn-apple.com/a/v1/custom.opwakeup.com

Inspecione o endpoint de CDN de Domínios Associados gerenciado pela Apple ao solucionar problemas de dados AASA entregues na borda. Trate este endpoint como infraestrutura de diagnóstico em vez de um contrato de API público.

Etapa 4: Usar o Modo de Desenvolvedor de Domínios Associados para Testes AASA

De acordo com a documentação da Apple sobre Como Configurar Domínios Associados, a Apple fornece um modo alternativo para desenvolvimento. O modo developer (?mode=developer) permite que dispositivos de desenvolvimento elegíveis contornem a CDN gerenciada pela Apple e busquem o arquivo AASA diretamente do domínio associado via HTTPS.

A configuração abaixo demonstra como declarar o Modo de Desenvolvedor em configurações de direitos do Xcode separadas:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com</string>
    </array>
</dict>
</plist>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com?mode=developer</string>
    </array>
</dict>
</plist>

Assim que o sistema operacional estabelece a associação de domínio, o roteamento em nível de aplicativo manipula payloads de URL de entrada usando delegados de ciclo de vida padrão do UIKit ou SwiftUI:

import UIKit

// ----------------------------------------------------------------------------
// 1. UIKit AppDelegate Implementation
// ----------------------------------------------------------------------------
@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        return true
    }

    // Standard Apple Universal Link Continuation Callback
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        
        guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
              let incomingURL = userActivity.webpageURL else {
            return false
        }
        
        print("Handling verified Universal Link: \(incomingURL.absoluteString)")
        
        // Dispatch incomingURL to internal router or SDK layer for parameter extraction
        return handleIncomingRoute(incomingURL)
    }

    private func handleIncomingRoute(_ url: URL) -> Bool {
        // Application-level destination routing logic
        // Note: Returning true indicates the app handled the activity, not that URL parsing succeeded.
        return true
    }
}

// ----------------------------------------------------------------------------
// 2. SceneDelegate Lifecycle Implementation (iOS 13+)
// ----------------------------------------------------------------------------
class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let incomingURL = userActivity.webpageURL {
            print("Cold-launch Universal Link: \(incomingURL.absoluteString)")
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb,
           let incomingURL = userActivity.webpageURL {
            print("Foreground Universal Link: \(incomingURL.absoluteString)")
        }
    }
}

Para habilitar o Modo de Desenvolvedor no lado do cliente em hardware físico:

  1. No iOS 16+, navegue até Ajustes > Privacidade e Segurança > Modo de Desenvolvedor e ative-o (reinicialização do dispositivo necessária).
  2. Navegue até Ajustes > Desenvolvedor > Desenvolvimento de Domínios Associados e alterne a chave para ON.
  3. Instale a compilação de desenvolvimento assinada com um perfil de provisionamento de desenvolvimento contendo o direito ?mode=developer.
  4. Nota de Produção: Mantenha ?mode=developer restrito a configurações de desenvolvimento e testes internos, e não o inclua no direito de domínios associados de produção, a menos que sua implantação exija e suporte explicitamente essa configuração.

Árvore de Decisão de Causa Raiz

Universal Link falls back to web handling
        │
        ├── Does signed application-identifier match AASA appIDs?
        │       ├── NO ──> Correct App ID Prefix or Bundle ID in AASA
        │       └── YES
        │
        ├── Does associated-domains entitlement list the exact domain?
        │       ├── NO ──> Add applinks:<domain> to target entitlements
        │       └── YES
        │
        ├── Does sudo swcutil dl -d <domain> succeed?
        │       ├── NO ──> Fix origin HTTPS, TLS certificates, or 301/302 redirects
        │       └── YES
        │
        ├── Does sudo swcutil verify match the target URL path?
        │       ├── NO ──> Correct components or paths syntax in AASA
        │       └── YES
        │
        └── Check device association state and internal application routing handlers
Technical flowchart decision tree for diagnosing iOS Universal Links web fallback root causes across binary entitlements, AASA schemas, and CDN caching on a warm cream grid background.

Matriz de Diagnóstico: Causas Raiz de Falhas em Links Universais

Modo de Falha Causa Raiz Subjacente Comportamento Observado do Sistema Remediação Recomendada
Erro de Digitação no Bundle ID Sensibilidade a maiúsculas/minúsculas ou incompatibilidade de caracteres em appIDs do AASA O link abre o navegador em vez do aplicativo nativo Corrija a string no JSON AASA e faça o novo deploy para a origem
Incompatibilidade de App ID Prefix Uso de prefixo incorreto em vez do App ID Prefix de Desenvolvedor real A associação de domínio falha durante a instalação Verifique o Application Identifier Prefix no Apple Member Center
Incompatibilidade de Subdomínio O direito aponta para www.example.com enquanto o AASA está em example.com O aplicativo falha ao reivindicar links do subdomínio Hospede um arquivo AASA dedicado em cada subdomínio reivindicado ou configure o curinga
Redirecionamento HTTP no Endpoint O servidor de origem retorna um redirecionamento 301 ou 302 para a URL AASA O scraper da CDN da Apple rejeita o arquivo AASA Configure o servidor web para retornar 200 OK diretamente
Inconsistência de Formato AASA Mistura de appID/paths legados com appIDs/components modernos Correspondência de caminho inconsistente ou parcial Padronize usando a sintaxe moderna appIDs + components
Incompatibilidade de Padrão de URL O AASA é baixado com sucesso, mas a URL solicitada não corresponde aos padrões O link abre no navegador web Verifique a sintaxe do caminho e componentes usando swcutil verify
Modo de Desenvolvedor Deixado na Versão de Lançamento A compilação de distribuição retém o modo alternativo de desenvolvimento Direito não padrão na compilação de distribuição Remova ?mode=developer na configuração de build de Release

International enterprise comparison matrix chart illustrating iOS Universal Link failure modes, root causes, system behaviors, and remediation steps with distinct status badges on a warm cream grid backdrop.

Implementando Configuração de Ambiente Duplo no Xcode

Gerenciando Vúltiplas Configurações de Build (Debug, Staging, Production)

Pipelines de desenvolvimento empresarial frequentemente gerenciam Bundle IDs distintos em ambientes de build (por exemplo, com.example.app.debug, com.example.app.staging, com.example.app).

Para manter Links Universais funcionais em todas as configurações de build:

  • Declarações AASA Explícitas: O arquivo AASA hospedado deve listar explicitamente o Application Identifier totalmente qualificado de cada ambiente em sua matriz appIDs:

    "appIDs": [
      "9JA723G82S.com.example.app",
      "9JA723G82S.com.example.app.staging",
      "9JA723G82S.com.example.app.debug"
    ]
    
    
  • Direitos Específicos do Alvo: Use configurações de build do Xcode para vincular arquivos .entitlements distintos por configuração de build, garantindo que os domínios de produção não sejam consultados por builds de depuração internos.

Gerenciando Identificadores de Alvo

Para solução de problemas de Links Universais, use o Bundle ID exato e o Application Identifier Prefix da compilação assinada, em vez de depender de identificadores curinga. Trate cada nome de host explicitamente: se o aplicativo reivindica example.com e www.example.com, configure as entradas de domínios associados correspondentes e garanta que cada nome de host sirva os dados AASA apropriados. Garanta que o direito esteja configurado no alvo que realmente manipula os Links Universais e verifique quaisquer alvos de extensão de aplicativo ou watchOS separadamente, quando aplicável.

Validando Perfis de Provisionamento Embutidos e Binários Assinados em CI/CD

Automatize a verificação de direitos e Application Identifier dentro de scripts de build de integração contínua antes de enviar binários para o TestFlight:

# Automated CI validation script
security cms -D -i /path/to/embedded.mobileprovision > provision.plist

# 1. Inspect profile entitlements for allowed Associated Domains
/usr/libexec/PlistBuddy -c "Print :Entitlements:com.apple.developer.associated-domains" provision.plist

# 2. Extract actual signed entitlements from the compiled executable binary
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
SIGNED_APP_ID=$(/usr/libexec/PlistBuddy -c "Print :application-identifier" signed-entitlements.plist)
echo "Extracted Signed Application Identifier: $SIGNED_APP_ID"

# 3. Validate that signed Associated Domains match the target domain
/usr/libexec/PlistBuddy -c "Print :com.apple.developer.associated-domains" signed-entitlements.plist

# 4. Verify that the signed App ID exists in the hosted AASA file via Python
python3 -c "
import json, sys
signed_id = sys.argv[1]
data = json.load(open('apple-app-site-association'))
app_ids = [app for detail in data.get('applinks', {}).get('details', []) for app in detail.get('appIDs', [])]
if signed_id not in app_ids:
    print(f'AASA mismatch: {signed_id} not found in AASA appIDs: {app_ids}')
    sys.exit(1)
print(f'AASA consistency check passed: {signed_id} registered')
" "$SIGNED_APP_ID"

Se o script de verificação for encerrado com um código de erro, abandone o pipeline de build para evitar o envio de binários de deep linking não funcionais para produção.

International 4-step developer workflow flowchart for automating iOS Universal Link App ID and AASA verification in CI/CD build pipelines on a warm soft cream grid background.

Critérios de Correspondência de Links Universais

Para garantir um roteamento confiável, as seguintes condições devem ser atendidas simultaneamente:

Signed App Configuration:
application-identifier = <ApplicationIdentifierPrefix>.<CFBundleIdentifier>
com.apple.developer.associated-domains = applinks:<hostname>

AASA Configuration:
appIDs = [..., "<ApplicationIdentifierPrefix>.<CFBundleIdentifier>", ...]
components / paths = Matching target URL paths and query parameters

System Eligibility:
1. Associated Domains entitlement explicitly contains the target hostname.
2. The signed Application Identifier matches an authorized entry in the domain's AASA appIDs.
3. The incoming URL satisfies the AASA routing patterns.
4. Device association state and user/browser context permit native application delegation.

Mesmo quando o direito, a associação AASA e o padrão de URL correspondem, o roteamento observado ainda pode depender do estado do dispositivo e do contexto do usuário ou do navegador. Por exemplo, quando um usuário toca em um link universal enquanto já está navegando no mesmo domínio no Safari, o sistema operacional pode respeitar a intenção do usuário de permanecer no Safari.

Perguntas Frequentes (FAQ)

Qual é o formato exato do identificador de aplicativo no arquivo AASA?
O identificador de aplicativo deve ser formatado estritamente como `<ApplicationIdentifierPrefix>.<CFBundleIdentifier>`, onde `<ApplicationIdentifierPrefix>` é o prefixo do App ID associado ao aplicativo na sua conta de Desenvolvedor da Apple (por exemplo, `9JA723G82S`) e `<CFBundleIdentifier>` é o Bundle ID (por exemplo, `com.example.app`), resultando em `9JA723G82S.com.example.app`. Não assuma que o prefixo é sempre idêntico ao Team ID; verifique o valor no perfil de provisionamento do aplicativo.
Por que meu Link Universal funciona no Modo de Desenvolvedor, mas falha em produção?
O Modo de Desenvolvedor (`?mode=developer`) permite que dispositivos de desenvolvimento elegíveis ignorem a CDN gerenciada pela Apple e busquem o arquivo AASA diretamente do seu servidor web de origem via HTTPS. Se os Links Universais falharem em produção, as causas comuns incluem um certificado TLS inválido no seu servidor de origem, um redirecionamento HTTP no endpoint AASA ou o payload AASA de produção contendo um erro de formatação rejeitado pelo scraper da CDN da Apple.
Posso usar asteriscos curingas na matriz appIDs do AASA?
Para solução de problemas de Links Universais, use o Application Identifier explícito do aplicativo assinado (`<App ID Prefix>.<Bundle ID>`) e declare esse identificador na configuração AASA. Não use um curinga como substituto para o identificador real do aplicativo.

Resumo e Estrutura de Decisão

A confiabilidade do roteamento de Links Universais depende do alinhamento exato, nível por caractere, em três nós: a configuração do App ID do Portal do Desenvolvedor da Apple, o direito com.apple.developer.associated-domains do Xcode e o arquivo JSON apple-app-site-association hospedado. Um SDK de terceiros ou framework de roteamento não pode consertar uma associação de domínio do sistema operacional que falhou; ele só pode processar a URL depois que o iOS entregou com sucesso o Link Universal para o aplicativo. Se os Links Universais estiverem associados corretamente no nível do sistema operacional, mas a extração de parâmetros falhar, inspecione a camada de roteamento em nível de aplicativo separadamente da camada de associação de domínio.

Se o seu aplicativo também exigir restauração de parâmetros de links dinâmicos e roteamento de integração após o sucesso da associação do Link Universal, o OpoInstall fornece uma camada de SDK opcional para esse fluxo de trabalho em nível de aplicativo.

Para saber mais sobre padrões de configuração de domínio e integração de deep linking, revise a documentação de deep linking do OpoInstall.

Materiais Relacionados

  • Conceitos: Verificação de Application Identifier, Validação de Esquema AASA, Armazenamento em Cache CDN da Apple, Extração de Direitos

  • Tecnologias: Links Universais do iOS, Direitos do Xcode, Portal do Desenvolvedor da Apple, Credenciais da Web Compartilhadas

  • Padrões: IETF RFC 8259 (Intercâmbio de Dados JSON), Especificação TLS 1.3

  • Ferramentas de Diagnóstico: Ferramenta CLI Apple codesign, Ferramenta macOS swcutil, Consulta de Cache CDN Gerenciada pela Apple

Documentação Oficial

Share this article