FAQ de migração do SDK para iOS
Esta página responde a perguntas frequentes sobre a migração do SDK Appboy legado para iOS (também conhecido como SDK Objective-C) para o SDK Swift da Braze.

AppboyKit (também conhecido como o SDK Objective-C) não é mais suportado e foi substituído pelo Swift SDK. Não receberá mais novos recursos, correções de bugs, atualizações de segurança ou suporte técnico—no entanto, o envio de mensagens e a análise de dados continuarão a funcionar normalmente. Para saber mais, veja Apresentando o Novo SDK Braze Swift.
Suporte de versão e fim de vida útil
O Appboy iOS SDK 4.7.0 chegou ao fim de vida útil?
Sim, o Appboy iOS SDK 4.7.0 (e todas as versões 4.x) chegou ao fim de vida útil. Nenhuma correção de segurança ou correção crítica de bug é fornecida. Embora o envio de mensagens e a análise de dados continuem funcionando normalmente, a versão 4.7.0 deve ser tratada como sem suporte do ponto de vista de segurança.
Qual é a versão mínima do Swift SDK para suporte em produção?
As versões principais atuais (16.x e posteriores) são o alvo de suporte contínuo, correções de bugs e novos recursos. Versões secundárias mais antigas podem não receber manutenção contínua.
Bibliotecas de compatibilidade
BrazeKitCompat e BrazeUICompat são compatíveis para uso em produção no Swift SDK 17.x?
Sim, BrazeKitCompat e BrazeUICompat são compatíveis para uso em produção durante a migração. Elas são posicionadas como um “ponto de passagem” de migração mínima para ajudar você a migrar do SDK do Appboy para o Swift SDK com o mínimo de alterações no código, e não como uma solução de longo prazo. Embora sejam formalmente compatíveis e ainda recebam correções de bugs, a intenção é que eventualmente você migre dessas bibliotecas de compatibilidade para as APIs modernas do Swift SDK.
Quando BrazeKitCompat e BrazeUICompat serão removidas?
A equipe do Swift SDK planeja descontinuar a biblioteca BrazeKitCompat, mas nenhum cronograma específico foi anunciado ainda. É recomendável planejar a migração completa para as APIs modernas do Swift SDK (BrazeKit, BrazeUI) em vez de depender das bibliotecas de compatibilidade indefinidamente.
Inicialização atrasada
Posso atrasar a inicialização do SDK até depois do consentimento do usuário?
Sim. O Swift SDK suporta inicialização atrasada, o que é útil para apps que precisam aguardar o consentimento do usuário antes de iniciar o SDK. Chame Braze.prepareForDelayedInitialization() (opcionalmente com um parâmetro analyticsBehavior) no início de application(_:didFinishLaunchingWithOptions:), e depois inicialize o SDK chamando o inicializador padrão da Braze após o consentimento ser obtido.
Para detalhes de implementação, consulte Configurar a inicialização atrasada.
Qual é a versão mínima do Swift SDK necessária para a inicialização atrasada?
O Swift SDK 11.2.0 é a versão mínima para inicialização atrasada. A robustez de push e deep link para inicialização atrasada foi aprimorada na versão 14.1.0. O Swift SDK 17.0.0 está bem acima desses dois limites.
O que acontece com os eventos recebidos antes da inicialização do SDK?
Quando o SDK é inicializado, os itens na fila são processados. No entanto, o comportamento varia por canal:
| Canal | Comportamento antes da inicialização |
|---|---|
| Tokens por push | Enfileirados; processados na inicialização |
| Aberturas/análise de push | Enfileirados por padrão (configurável para descartar via analyticsBehavior) |
| Deep links | Enfileirados; processados na inicialização |
| In-App Messages | Não armazenados em buffer antes da inicialização; exigem que o SDK esteja em execução |
| Content Cards | Não armazenados em buffer antes da inicialização; sincronizados do servidor após a inicialização |

In-App Messages e Content Cards recebidos antes da inicialização não têm garantia de entrega. Certifique-se de que o SDK esteja inicializado antes de tentar exibir esses canais.
Pacotes de recursos e integração com SPM
Por que estou vendo um erro de tempo de execução sobre braze-swift-sdk_BrazeUI.bundle ausente?
Isso não é um bug conhecido do SDK e provavelmente se deve a uma configuração incorreta da integração. A partir do Swift SDK 12.0.0, os XCFrameworks estáticos incluem recursos diretamente, em vez de depender de pacotes de recursos externos.
Quais são os requisitos de SPM/Xcode/archive para incorporação de recursos?
A partir do Swift SDK 12.0.0, você deve selecionar Embed & Sign para os XCFrameworks da Braze nas configurações do seu projeto no Xcode — isso se aplica tanto às variantes estáticas quanto às dinâmicas. Essa é a causa raiz mais comum para erros de pacote ausente durante o archive ou o lançamento.
Como substituir pacotes de recursos para sistemas de build não padrão?
Para sistemas de build não padrão (Tuist, Bazel, Buck, CI), use as APIs de substituição aprovadas:
BrazeKit.overrideResourcesBundle(observe o plural “Resources”)BrazeUI.overrideResourcesBundle(observe o plural “Resources”)
O singular overrideResourceBundle foi descontinuado no Swift SDK 8.1.0 e não deve ser usado.
Identidade do usuário e tokens por push
Existe uma lista de verificação para preservar perfis, associações de dispositivos e tokens por push?
Não existe uma lista de verificação oficial específica para migração na documentação. Recomendamos que você realize as seguintes etapas de validação:
- Confirme que
registerDeviceTokenou a automação de push está configurada corretamente após a migração. - Verifique a contagem de usuários registrados para push no dashboard antes e depois do lançamento.
- Faça uma verificação pontual de alguns IDs externos específicos para confirmar que as associações de dispositivos permanecem intactas.
O changeUser garante que os tokens por push acompanham o novo usuário?
Não há garantia explícita documentada por escrito. No entanto, a intenção do design é que os tokens por push acompanhem o dispositivo, não o usuário. Chamar changeUser deve reassociar o token de dispositivo existente ao novo perfil de usuário. Você deve testar o changeUser, verificar no dashboard e confirmar que o token aparece no novo perfil antes de fazer o lançamento em massa.