Eu enviei o seguinte feedback hoje. Se você planeja alterar seu modelo de negócios de um modelo de antecedência paga para Freemium, leia este relatório e evite um dia de dor de cabeça e estresse.
Título: O código de exemplo para uma mudança de modelo de negócios foi escrito por alguém que nunca enviou um aplicativo para a App Store
Descreva o problema e quais etapas podemos tomar para reproduzi -lo:
O exemplo do código -fonte usando em Suportar mudanças no modelo de negócios usando a transação de aplicativos Não funciona se você estiver usando convenções atuais do XCode e App Store. Além disso, o ambiente da Sandbox usa as mesmas convenções desatualizadas.
E quando você usa esse código de amostra, que você não pode testar no simulador de transação do XCode ou no ambiente do Testflight Sandbox, ele falhará espetacularmente no dia do lançamento. Você será inundado com solicitações de suporte de pessoas que esperam ver um pagamento pela versão anterior e estará em um estado de pânico porque não tem idéia do que diabos está acontecendo. E eu mencionei que você não pode testar isso em produção?
O código de amostra implica que o originalAppVersion é uma string que é separada por períodos (“.”). O ambiente Sandbox retorna um valor de “1.0”, que reforça essa noção de que é um valor que se separa por períodos.
Não é.
Se você tivesse Leia a documentação do Xcodevocê saberia que ele gera automaticamente a info.plist de um aplicativo. Essa tem sido a configuração padrão há muito tempo – a maioria dos desenvolvedores não tem idéia de que essa é uma opção configurável: eles preenchem o número “versão” e “construir” nas configurações gerais do alvo e são feitas com ela.
Para a maioria, o número de compilação será apenas um único número que incrementa cada vez que você enviar ao Testflight (e eventualmente à App Store).
Quando GERETE_INFOPLIST_FILE está ativado, ele define o valor da tecla CFBNDLEVERSION no arquivo info.plist para o valor do número de compilação (current_project_version, ou o “Build” em configurações gerais). E isso significa que sua info.plist está recebendo uma CFBNEAVERSÃO SEM períodos.
Então, o que acontece quando você usa este código?
let versionComponents = appTransaction.originalAppVersion.split(separator: ".") let originalMajorVersion = versionComponents(0)
Bem, se você é um desenvolvedor SWIFT inexperiente, seu aplicativo vai travar com um índice de matriz que está fora dos limites. Aqueles de nós que são mais cuidadosos em nosso código de processamento de recebimento irão pular sobre o originalMajorVersion porque versionComponents está vazio.
E é aí que os e -mails dos clientes começam a chegar.
Felizmente, existe isso Nugget of Information descrevendo originalAppVersion:
A OriginalAppversion permanece constante e não muda quando o cliente atualiza o aplicativo. O valor da string contém o valor original do CFBUNDLESHORTVSIONSTIONSTRING para aplicativos em execução no macOS e o valor original do CFBNleDLeverSion para aplicativos em execução em todas as outras plataformas.
Então, mesmo que o CFBNELDERVERSION fosse Originalmente pretendido como um formato maior/menor/patchseu uso atual é como um número inteiro único que incrementa quando você se envia ao TestFlight. Portanto, o código acima está esperando “1.0” e está realmente recebendo “83”.
(E por que diabos é diferente no macOS? Você percebe que os aplicativos de plataforma cruzada são uma coisa, certo?)
Novamente, você não tem como testar essa teoria além de passar pela revisão de aplicativos (com uma revisão acelerada, se você tiver sorte). E se você tiver ainda mais sorte, você terá pessoas no Mastodon que confirmarão Que esse código de amostra é uma merda. Algumas horas depois, você respira um suspiro de alívio quando as pessoas começarem a dizer que as coisas estão funcionando bem.
E então, no dia seguinte, você escreverá este relatório de bug e o publicará publicamente porque ninguém mais deveria ter suportar o estresse causado por esse código desleixado.