Assinatura e notarização de apps para Mac, em termos simples

Resposta curta

A assinatura põe seu nome no app e mostra que ele não mudou. A notarização envia o app para a análise automática da Apple. O stapling anexa o resultado, para que ele possa ser verificado offline. Você faz nessa ordem, e as faz por último, depois que o build estiver pronto.

Se você só rodou seu app pelo Xcode, esta parte da distribuição pode parecer um muro de certificados. As ideias são simples, e são só três. Para todos os detalhes, com os documentos da Apple linkados, leia o que é a notarização em um Mac. Este post é a versão curta para criadores.

As três etapas

A assinatura é o seu nome no app. Um certificado Developer ID da Apple diz quem o fez, e a assinatura mostra que nada mudou desde então. Obter esse certificado exige uma inscrição no Apple Developer Program, a US$ 99 por ano.
A notarização é uma análise automática. Você envia o app assinado, o serviço da Apple procura conteúdo malicioso e problemas de assinatura, e, se não encontrar nenhum, emite um ticket. Ninguém na Apple usa o seu app, e não é a App Review.
O stapling anexa esse ticket ao seu arquivo, para que um Mac possa verificá-lo sem estar online.

Se você vende só pela Mac App Store, pula as duas últimas. A Apple assina os apps da loja, e a documentação dela diz que o processo da loja tem verificações de segurança equivalentes.

O que seus usuários veem se você pular isso

Elas recebem um aviso. O macOS diz que não consegue verificar o app, e desde o macOS Sequoia, o Control-clique não passa mais por ele. A pessoa precisa ir em Ajustes do Sistema e escolher Abrir mesmo assim. Algumas pessoas desistem nesse ponto, e eu não as culpo. O que significa “A Apple não pôde verificar” mostra o mesmo aviso do lado delas, e vale a pena ler uma vez.

A ordem que economiza sua tarde

Termine o build. Qualquer alteração feita depois de assinar quebra a assinatura.
Assine primeiro o código aninhado, como frameworks e helpers, depois o próprio app. Use o hardened runtime e um timestamp seguro, porque a notarização exige os dois.
Coloque-o em um DMG se for assim que você distribui, e assine esse também.
Envie com notarytool. A Apple diz que a análise geralmente leva menos de uma hora.
Leia o log, mesmo quando der certo.
Faça o stapling com stapler.

Verifique o seu próprio build

spctl -a -vv /Applications/YourApp.app
xcrun stapler validate /Applications/YourApp.app

Você quer source=Notarized Developer ID no primeiro, e uma mensagem de sucesso no segundo. Cole o que você obtiver no explicador de notarização, e ele dirá o que cada linha significa, ou avisará se não reconhecer algo. Ele lê o texto no seu navegador e não envia nada para lugar nenhum.

Depois faça o teste que pega mais problemas: baixe o seu próprio build pelo navegador em outro Mac ou outra conta de usuário, e abra-o. O checklist de lançamento traz este e os outros passos em ordem.

O que notarizado não significa

Não significa que é bom, privado ou seguro. Significa que a análise automática da Apple não encontrou nada que ela conhecesse. Tome cuidado para não prometer mais do que isso no seu site. Como saber se um app para Mac é seguro explica o que cada verificação pode e não pode provar, do ponto de vista do usuário.

O que o MacPip faz com isso

O MacPip pede downloads assinados e notarizados. Apps de código aberto são bem-vindos sem isso, e o relatório deles diz isso. Um selo azul significa que uma pessoa verificou o app na data indicada, e a assinatura e a notarização aparecem no relatório só quando as confirmamos em uma cópia baixada. Não é garantia de segurança, e nossas regras dizem isso. Quando seu build estiver pronto, você pode listá-lo de graça.