Xcode

O caminho que envia um build para a App Store Na Parte 1 criamos o target de build MAS e na Parte 2 criamos os arquivos de configuração e a ramificação de código que separam os dois canais. O target FocusTimer MAS agora está em uma forma que pode ser colocada na App Store. Nesta parte final, vamos configurar o caminho para fazer o upload desse build para o App Store Connect e explicar como verificar os dois canais para que permaneçam íntegros daqui para frente, concluindo a série. ...

Tornando o target verdadeiramente “específico para MAS” Na Parte 1, registramos um Bundle ID exclusivo para MAS e duplicamos o target de build FocusTimer MAS. Mas esse target ainda é apenas uma cópia do target de distribuição direta. Um build MAS precisa diferir do build de distribuição direta em três aspectos. Entitlements — apenas o conjunto mínimo adequado para a App Store Info.plist — remova as chaves do Sparkle, adicione metadados da App Store Código — ramifique para que compile mesmo sem o Sparkle Neste artigo, vamos separar todos os três. ...

Outro canal de distribuição — a Mac App Store A série anterior cobriu a configuração inicial para distribuir um app macOS diretamente com um Developer ID. Uma vez que você tenha certificados, notarização, atualizações automáticas com Sparkle e um feed de atualizações hospedado, pode permitir que os usuários baixem um arquivo .dmg diretamente sem passar pela App Store. Esta série cobre a configuração inicial para colocar esse mesmo app na Mac App Store (MAS) também. Os dois métodos de distribuição não são uma escolha mutuamente exclusiva. Você pode operar um único app pelos canais de distribuição direta e da App Store ao mesmo tempo. A App Store tem a Apple gerenciando pagamentos, reembolsos e visibilidade nas buscas em seu nome, e traz maior confiança dos usuários, então operá-la junto com a distribuição direta é uma escolha comum. ...

A última peça — onde colocar as atualizações Na Parte 1 preparamos o certificado Developer ID e a notarização, e na Parte 2 preparamos a chave de assinatura do Sparkle. Isso significa que agora temos uma forma de assinar o app, notarizá-lo e verificar a autenticidade das atualizações. Mas o local apontado pelo SUFeedURL (https://updates.example.com/appcast.xml), que escrevemos no Info.plist do app na Parte 2, ainda não tem nada. Nesta parte final, vamos hospedar o feed de atualizações que vai naquele local e finalizar as configurações de build, completando toda a configuração inicial. ...

Atualizações automáticas e por que você precisa de mais uma camada de assinatura Na Parte 1, concluímos a configuração do certificado Developer ID e da notarização. Com isso, você está pronto para entregar o app aos usuários pela primeira vez. Mas um app não termina após um único lançamento — você precisa continuar enviando novas versões que corrigem bugs e adicionam funcionalidades. Para um app da Mac App Store, a App Store trata as atualizações para você. Um app distribuído diretamente não tem esse benefício, então você precisa incluir um recurso de atualização automática no próprio app. No macOS, o padrão de fato para esse papel é o framework de código aberto Sparkle. Com o Sparkle configurado, o app verifica periodicamente um “feed de atualizações (appcast)” e, se existir uma nova versão, notifica o usuário, faz o download e a instala. ...