AULA 15 / 30 · Implementação e consentimento
iOS: callback, ausência de match e preservação Google
Trate os estados do SDK sem fabricar campanha.
Guia baseado em documentação e PRs consultados. SDKs/API citados ainda têm alterações em draft; confirmar release e homologação.
Ver implementação e critérios de aceite →O que a branch entrega
O PR iOS #2, aberto e draft, retira first_open manual e acrescenta overload com consentimento e Google preservado. Mantém completion, campanha, propriedades e dryRun. A consulta não encontrou uma release SPM/Pod criada para essa alteração.
Ausência de match
O contrato legado trata HTTP 404 como UTMData vazio sem erro. O app precisa distinguir resposta vazia, permissão negada, timeout e match válido. Resposta vazia não é autorização para preencher Meta ou Google por preferência.
Google preservado e consentimento
O overload interrompe a rede quando consentimento está negado. No caminho nativo Google preservado, devolve UTMs vazios e não injeta campanha. Confirme a política no app em vez de inferi-la a partir de um parâmetro isolado.
O que o simulador não prova
Os testes Swift verificam comportamento sem rede. O exemplo compilado com plist de placeholder não valida Firebase real. Release, configuração do projeto, aparelho, deferred linking e dedupe seguem etapas próprias de homologação.
CONTRATO / EXEMPLO
Assinatura do PR iOS #2 · ainda em draft
// Assinatura inspecionada; release SPM/Pod e aparelho ainda precisam de homologação.
public func firstOpen(
with bundle: MatchBundle,
consentGranted: Bool,
preserveNativeGoogleAttribution: Bool,
completion: @escaping ((UTMData?, String?) -> Void)
)Confirme versão, ambiente e políticas na documentação vinculada. Exemplos não ativam coleta ou produção.
SUA VEZ
Leve a aula para a prática
Registre quatro resultados de completion, a ação esperada do app e a evidência Firebase correspondente.
Baixar checklist de homologação ↓Confira o aprendizado
Documentação e evidências
Consultadas em 03/10/2026. Os exercícios e números desta aula são fictícios.