SoftwareSe sua equipe distribui aplicativos para Mac fora da Mac App Store, vale conferir agora quais certificados Developer ID assinam os apps e instaladores. A autoridade antiga da Apple expira em 1º de fevereiro de 2027. A mudança não derruba todo app já instalado: o impacto mais direto é sobre instaladores .pkg assinados com certificados afetados e sobre a assinatura das próximas versões. Para evitar uma falha de instalação no lançamento, a equipe precisa identificar o emissor, emitir certificados pela autoridade G2 e testar o fluxo completo antes do prazo.
A Apple publicou o aviso em 1º de outubro de 2026. Segundo a comunicação oficial para desenvolvedores, os certificados da autoridade antiga deixam de servir para assinatura em fevereiro. A Apple também diferencia o que acontece com os dois tipos de entrega: instaladores .pkg afetados deixam de instalar; apps para Mac já assinados e notarizados com um timestamp seguro continuam funcionando, enquanto atualizações futuras precisam usar um novo certificado e incluir esse timestamp.
O prazo afeta todos os apps para Mac?
Não. O aviso trata de certificados emitidos pela subautoridade antiga do Developer ID. A documentação da Apple recomenda olhar no portal Certificates, Identifiers & Profiles e verificar o emissor no Keychain Access; a data de validade, sozinha, não prova que um certificado está na cadeia afetada. No campo “Organizational Unit” do emissor, Apple Certification Authority identifica a subautoridade anterior; G2 identifica a atual. A instrução de migração da Apple descreve essa conferência e os passos para emitir a substituição.
Também é importante separar assinatura de app e assinatura de pacote. A Apple usa Developer ID Application para assinar o app, plug-in ou binário distribuído fora da loja. Developer ID Installer assina o pacote .pkg que instala o app. Uma equipe pode ter os dois tipos, com certificados de nomes parecidos, e precisa conferir cada um. A página de certificados Developer ID explica qual certificado corresponde a cada artefato e observa que o papel de Account Holder é necessário para criá-los.
Apps instalados e pacotes de instalação não têm exatamente o mesmo comportamento. Um app existente, assinado e notarizado com timestamp seguro, não precisa ser reinstalado só por causa dessa troca. Ainda assim, uma atualização futura terá de ser assinada pela identidade nova. Já um instalador .pkg precisa de atenção especial: é o fluxo de instalação que a Apple diz que deixa de funcionar quando o certificado da autoridade antiga expirar. Se o produto usa perfil Developer ID para recursos como CloudKit ou notificações, confira também a validade desse perfil; ele é uma peça separada da cadeia de assinatura.
Etapas para identificar a cadeia afetada e testar a troca antes do prazo. Diagrama editorial da Pump com base na documentação da Apple.
Como preparar a migração sem interromper a distribuição
Comece fazendo um inventário dos apps, plug-ins, imagens de disco, pacotes .pkg e rotinas de atualização que a equipe distribui fora da Mac App Store. Inclua os builds arquivados que ainda são usados para atualizações e os pipelines de CI que guardam a identidade de assinatura. Em seguida, registre para cada item o tipo de certificado e o emissor. Não confie apenas no nome ou na data de vencimento que aparece no portal: a orientação da Apple é confirmar a autoridade pelo emissor.
Para gerar substitutos, escolha Developer ID Application e Developer ID Installer separadamente, se ambos forem usados, e selecione G2 Sub-CA quando o portal perguntar pela autoridade. A Apple avisa que escolher outra opção pode gerar um certificado ligado à cadeia antiga. O certificado da G2 pode ser emitido até 2031, mas cada certificado emitido por ela tem validade de um ano e exige renovação anual. Isso transforma a migração em uma mudança de processo, não em uma tarefa única sem manutenção. A página de atualização da autoridade intermediária Developer ID explica também que é necessário manter a autoridade antiga instalada enquanto certificados antigos ainda forem usados para assinar.
Depois, atualize o ambiente de build: cofre de segredos, keychain das máquinas de CI, identidade selecionada pelo Xcode ou pelo script de distribuição, permissões da chave privada e documentação de release. Gere uma versão de teste com o certificado novo, passe pelo processo de notarização e instale o .pkg em um Mac limpo. A Apple descreve a notarização como uma verificação automatizada do software assinado, e recomenda consultar o log quando uma submissão falha; a documentação de distribuição e notarização ajuda a revisar essa parte. Não conclua a migração só porque o certificado apareceu no portal: confirme que o artefato final foi assinado e que o fluxo de instalação funciona.
Para produtos ainda avaliando a forma de distribuição, a decisão também passa por arquitetura e custo de manutenção. Nosso guia sobre app nativo, híbrido ou PWA ajuda a comparar o papel de uma versão para Mac com alternativas web e multiplataforma. E, ao organizar prazos de desenvolvimento, vale considerar as etapas de planejamento, testes e publicação de um aplicativo, incluindo a validação de assinatura e entrega.
O que fazer agora
Se o produto é distribuído apenas pela Mac App Store, ou se não há app para Mac assinado com Developer ID, a mudança pode não exigir ação imediata. Para quem distribui fora da loja, a checagem é concreta: identificar a cadeia, substituir os certificados afetados, atualizar o pipeline e validar uma instalação limpa. A recomendação é não esperar a virada de fevereiro: separar um build de teste neste ciclo dá tempo para encontrar uma identidade antiga em automações esquecidas e corrigir a distribuição antes que clientes encontrem um instalador que não abre.
