Pergunta

Estou tentando fazer upload de um aplicativo para a App Store do iPhone, mas recebo esta mensagem de erro do iTunes Connect:

O binário que você enviou é inválido.A assinatura era inválida ou não foi assinada com um certificado de envio da Apple.


Observação:Os detalhes da pergunta original foram removidos, pois esta página se transformou em um repositório para todas as informações sobre as possíveis causas daquela mensagem de erro específica.

Para obter informações gerais sobre como enviar aplicativos do iPhone para a App Store, consulte Etapas para fazer upload de um aplicativo do iPhone para a AppStore.

Foi útil?

Solução

Pela minha experiência, o Xcode ocasionalmente fica confuso sobre qual certificado de assinatura usar.Adquiri o hábito de sair e reiniciar o Xcode após qualquer alteração nas configurações de assinatura de código (e fazer uma compilação limpa) para solucionar esse problema.

Outras dicas

Eu só queria mencionar que também tive o problema com o ZIP da linha de comando também.O problema está na maneira como ele lida com links simbólicos por padrão.Usando:

zip -y -r meuapp.zip meuapp.app

Resolvi esse problema.

Eu tive o mesmo problema e resolvi desta forma:

Os certificados de propriedade foram instalados na minha máquina de desenvolvimento e mobileprovision.embedded foi incluído no arquivo de distribuição.Depois de mais ou menos uma hora pesquisando e pesquisando no Google, encontrei a origem do erro.Dentro do Xcode eu copiei a configuração do Release e criei uma nova configuração de distribuição e depois mudei a identidade de assinatura para meu certificado de distribuição.Porém, mesmo tendo sido atualizado na GUI o arquivo do projeto não foi atualizado corretamente.

Se você encontrar o mesmo erro, procure no diretório [ProjectName].xcodeproj o arquivo project.pbxproj e abra-o em seu editor favorito.Procure a seção Distribuição.O meu quebrado ficou assim:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};

Você pode ver que a identidade de assinatura e o perfil de provisionamento estão incorretos na segunda seção.Edite-o para corresponder à primeira seção, reconstrua e você estará pronto para prosseguir.O final ficou assim:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};

guias mudaram para proteger os inocentes

Mesmo problema, solução diferente.

No meu caso, eu estava compactando o arquivo usando zip -r myapp.zip myapp.appAcontece que o comando zip estragou o pacote.Compactá-lo do localizador fez com que funcionasse.

Eu tive o mesmo problema e depois de tentar várias coisas - removi os direitos .plist dos direitos de assinatura de código (deixei em branco) e ele foi compilado corretamente e carregado FINALMENTE.

Boa sorte a todos :-D

Outro ponto de dados:por um tempo, meu aplicativo funcionou.Agora adicionei suporte para compras no aplicativo e, de repente, ele falha com um problema de "binário inválido/assinatura inválida".Após uma análise cuidadosa, descobri que o valor do identificador de aplicativo no arquivo plist de direitos estava desativado.

Provavelmente, isso tem a ver com o fato de eu ter substituído o perfil de provisionamento de um curinga para um específico do aplicativo (obrigatório para compras no aplicativo).O ID do aplicativo errado foi qualificado no perfil antigo.Não correspondia ao ID do aplicativo no info.plist, mas aparentemente o iTunes perdoou isso.

Então, para recapitular:

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*

está bem, enquanto

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo

causa "Binário inválido".

Eu também tive o mesmo problema, ao construir percebi que o provisionamento não foi adicionado na construção.

A solução para mim foi definir a compilação para o dispositivo iphone como onde normalmente uso o simulador, mas ele não incluirá o perfil de provisionamento...

Isso pode ser um erro de noob.Normalmente você não pode criar para o dispositivo, mas quando faz isso para distribuição, você pode.

Bem, depois de repetir as etapas várias vezes, finalmente consegui enviar meu aplicativo.

Não sei exatamente o que resolveu o problema, mas antes da tentativa bem-sucedida, fechei o Xcode e o Firefox e os reiniciei.Acho que um desses aplicativos tinha algum problema ruim.

Aqui está um problema que encontrei:Adicionei o binário ao Subversion antes de fazer o upload.Comparar/compactar o binário incluiu os diretórios .svn ocultos, o que atrapalhou a assinatura do código.

Tentei várias coisas depois de ler vários posts, incluindo os acima.O que finalmente funcionou para mim foi recomeçar completamente!Excluí todos os certificados e perfis de provisionamento associados ao meu aplicativo.

Recriei um novo certificado de desenvolvimento e um novo certificado de distribuição.Baixei o certificado intermediário novamente.Depois recriei o perfil de desenvolvimento e o perfil de distribuição.

Depois de instalar os três certificados (notei que desta vez a distribuição tinha chaves privadas e públicas) e os dois perfis de provisionamento (meu perfil de distribuição não foi sinalizado como não tendo um certificado válido!), tudo funcionou.

Depois que tomei a decisão de revogar tudo e começar de novo, levei apenas cerca de 5 minutos para criar o novo material e reinstalar.

Veja este link para a solução:

http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect

A resposta curta é: "Eventualmente, verifiquei novamente meu info.plist e descobri algo.Adicionei CFBundleIconFiles de acordo com as novas diretrizes, mas havia uma entrada vazia na lista de arrays.Eu removi e reenviei, e finalmente foi aceito!"

Eu tive um problema semelhante, mas no Monotouch.Descobri que meu perfil de lançamento foi configurado para usar certificados de desenvolvedor.Deveria ficar assim:enter image description here

Parece que esse problema tem muitas causas.Aqui está a solução para a minha:

Isto se aplica a qualquer pessoa que pertença a várias equipes de desenvolvimento (por exemplo,seus próprios aplicativos e suas empresas).

Se você criar a compilação com um conjunto de credenciais e assiná-la novamente com uma diferente (por exemplo,para distribuição ad hoc/appstore), você deve certifique-se de que a compilação foi originalmente construída e assinada com credenciais pertencentes à mesma equipe de desenvolvimento do iOS à qual pertencem as credenciais de distribuição com as quais você está assinando novamente.

Portanto, não crie com credenciais "Indy Dev Inc" e tente implantar com credenciais "Company Inc".Certifique-se de configurar as credenciais de desenvolvimento e distribuição da "Company Inc" e usá-las.

Postei mais informações sobre isso no meu blog: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

Eu tive o mesmo problema.Eu estava pronto para jogar a toalha nesse problema, mas descobri quando fui verificar meu código usando Murky.Eu sempre dou uma olhada nas diferenças nos arquivos que foram alterados antes de fazer o check-in.Ao fazer isso desta vez, percebi que o arquivo project.pbxproj havia mudado... e na seção Distribuição a entrada para “PROVISIONING_PROFILE[sdk=iphoneos*]” estava em branco.

Sair e reiniciar o Xcode não funcionou para mim.Em vez disso, entrei nas configurações do projeto e do destino e alterei a assinatura do código para selecionar diretamente meu perfil de distribuição, em vez de depender do recurso de seleção automática.Isso fez com que o arquivo project.pbxproj fosse preenchido com os valores corretos, embora o recurso de seleção automática supostamente selecionasse exatamente o mesmo perfil que selecionei manualmente.

Eu preciso de uma cerveja...

Depois de tentar todas as outras correções listadas aqui, registramos um TSI com a Apple.Depois de seguir todos os passos Nota Técnica TN2250 nosso problema foi causado porque um recurso selado estava ausente ou era inválido.No nosso caso foi ._.DS_Store.

O ".." é chamado de arquivo Apple Double e é o resultado da cópia da pasta Xcode Project, *descompactada*, de e para um sistema de arquivos que não suporta adequadamente os 'forks de recursos' do HFS+ (usados ​​para assinaturas de código).Esses extras ".." resultam e causam falha na verificação de assinatura de código.

Para limpar os arquivos Apple Double problemáticos da pasta do projeto Xcode, execute o comando dot_clean na pasta do projeto Xcode, faça uma compilação limpa e, em seguida, arquive novamente e tente enviar novamente.

dot_clean /the/path/to/xcode/project

Observação:Você pode simplesmente arrastar a pasta do projeto para o terminal para preencher automaticamente o caminho

Não há nenhuma mensagem quando você executa o comando, mas a compilação do projeto pode mostrar um aviso sobre o arquivo na próxima compilação.Você pode ignorar isso, o aplicativo será validado e enviado com sucesso.

Resolvi isso limpando o arquivo myProject.xcodeproj (clique com o botão direito, abra o pacote), o pacote continha arquivos do co-desenvolvedor, após excluí-los o problema foi resolvido

Para mim a solução foi criar uma certificação de distribuição em:Portal de provisionamento de desenvolvedores Apple.

Se valer a pena, quero acrescentar o que resolveu esse problema para mim.Eu tive um ?(ponto de interrogação) no título do meu aplicativo que estava causando o erro.

Recebi um binário inválido, se o aplicativo não usar notificação push remota, mas deixei o código para registrar push e os delegados de retorno de chamada para registrar/receber notificação remota sem comentar, mesmo que o código não seja usado.

Isto é recente.Minha última submissão na semana passada foi boa.Esta semana, ele retorna binário inválido.Felizmente, há um e-mail que explica o erro.

Eu estava tendo um problema semelhante, mas não uso entitlements.plist.No entanto, depois de uma dúzia de uploads com falha, verifiquei meu info.plist e descobri algo.Minha matriz CFBundleIconFiles tinha uma entrada vazia.Eu removi e reenviei, e finalmente foi aceito!

Sério, quão difícil seria para a Apple expor esse tipo de erro de validação?

Editar:Não é imediatamente aparente onde estão os CFBundleIconFiles porque eles usam um nome diferente.Na visualização de informações do projeto, clique em Ctl e selecione "Mostrar chaves/valores brutos" e então você verá as referências a CFBundleWhatever.No caso deste editor, ele estava tentando usar um arquivo icon=72-@2x.png inexistente.

Meus dois centavos:

Baixe a versão mais recente do Application Loader.Acabei de atualizar e agora recebo uma mensagem de erro diferente.

Acabei de passar por esse incômodo (de novo), mas desta vez descobri que meu perfil de distribuição tinha o status "Inválido".Se você acha que todo o resto está certo, verifique novamente o status no portal e renove/baixe novamente qualquer coisa que não esteja no estado Ativo.

Recebi um binário inválido após o upload de um aplicativo, sem nenhum acompanhamento por e-mail sobre o motivo da falha.Tentei fazer algumas coisas ao mesmo tempo e não tenho certeza de qual das opções a seguir realmente corrigiu o problema:

  1. MacBook Pro reiniciado
  2. Movi o código-fonte do meu projeto de uma unidade NTFS para uma unidade HFS+ e recompilei.

Tive um problema com isso e com o SDK 4.3 GM.Um de nossos aplicativos não passou do upload recebido.Acabou sendo um problema de perfil de provisionamento.Regenerei o perfil da app store e funcionou bem.

Minha solução envolveu a criação de um novo App ID.Não sei exatamente por que isso resolveu o problema, mas suspeito que possam ter sido identificadores de pacote incompatíveis - a criação do novo ID do aplicativo me forçou a ter certeza de que meu aplicativo e o iTunes esperavam a mesma coisa.

Outra solução:

Para mim, simplesmente definir os certificados de 'Liberação' em 'assinatura de código' corrigiu o problema.Eles foram inicialmente definidos como 'Não assinar código'.

Para mim, o problema foi resolvido salvando novamente uma imagem PNG com a opção não entrelaçada.Nas versões anteriores, png entrelaçados eram permitidos, mas saiba que essas imagens podem causar binário inválido.

Minha mensagem da maçã:Arquivo de ícone corrompido - O arquivo de ícone iconGQ@2x.png parece estar corrompido.Seu ícone não deve ser um arquivo PNG entrelaçado.

Você pode ver se o PNG está entrelaçado usando o comando “file” no terminal:Eva-Madrazos-MacBook-Pro-2: GQ 7 Integracion ADS EVA $ FILE *.png default.png:Dados de imagem PNG, 320 x 480, RGB de 8 bits/cor, não entrelaçado

Boa sorte, Eva

Quero salientar a possibilidade de enviar um e-mail à Apple e pedir que verifiquem seus logs.Eu fiz exatamente isso, depois de ter tentado muitas coisas primeiro.Foi necessário lembrá-los depois de quase quatro semanas, mas finalmente eles responderam e apontaram o local exato do problema.

O problema no meu caso foi que eu já havia tentado outros ícones de aplicativos e uma referência à imagem antiga ainda permanecia em ‘CFBundleIcons’.Usei a funcionalidade de arrastar e soltar para definir o ícone, mas não percebi que o conteúdo antigo não foi completamente limpo antes da nova referência ser adicionada.

Para ver a referência defeituosa foi necessário expandir as setas para visualizar cada um dos subelementos do arquivo plist.Uma dica é clicar com o botão direito no arquivo e selecionar a opção de visualização do conteúdo bruto.Dessa forma, você não precisará expandir nada.

Tentei todas as outras soluções propostas, mas nada ajudou.

Acabei criando um novo projeto Xcode e copie todo o meu código e recursos nele.Isso funcionou e meu aplicativo foi colocado na fila de revisão.

Eu também posso recomendar Notas técnicas da Apple sobre assinatura de código para depuração/verificação.

uuid não é permitido.Eu consertei removendo todos [[UIDevice currentDevice] uniqueIdentifier];

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top