Binario de aplicación de iPhone no válido

https://stackoverflow.com/questions/47941

09-06-2019
|

Pregunta

Estoy intentando cargar una aplicación en la App Store de iPhone, pero aparece este mensaje de error de iTunes Connect:

El binario que has subido no era válido.La firma no era válida o no estaba firmada con un certificado de envío de Apple.

Nota:Los detalles de la pregunta original se eliminaron, ya que esta página se convirtió en un depósito de toda la información sobre las posibles causas de ese mensaje de error en particular.

Para obtener información general sobre cómo enviar aplicaciones de iPhone a la App Store, consulte Pasos para subir una aplicación de iPhone a la AppStore.

Solución

Según mi experiencia, Xcode ocasionalmente se confunde acerca de qué certificado de firma usar.Adquirí el hábito de salir y reiniciar Xcode después de cualquier cambio en la configuración de firma de código (y realizar una compilación limpia) para solucionar este problema.

Otros consejos

Solo quería mencionar que yo también tuve el problema con ZIP de la línea de comandos también.El problema radica en la forma en que maneja los enlaces simbólicos de forma predeterminada.Usando:

zip -y -r miaplicación.zip miaplicación.aplicación

Resolvió ese problema.

Tuve el mismo problema y lo resolví de esta manera:

Los certificados de propiedad se instalaron en mi máquina de desarrollo y mobileprovision.embedded se incluyó en el archivo de distribución.Después de aproximadamente una hora de buscar en Google y cavar, encontré la fuente del error.Dentro de Xcode copié la configuración de lanzamiento, creé una nueva configuración de distribución y luego cambié la identidad de firma a mi certificado de distribución.Sin embargo, aunque se actualizó en la GUI, el archivo del proyecto no se actualizó correctamente.

Si encuentra el mismo error, busque en su directorio [ProjectName].xcodeproj el archivo project.pbxproj y ábralo en su editor favorito.Busque la sección Distribución.Mi roto se veía así:

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;
};

Puede ver que la identidad de firma y el perfil de aprovisionamiento son incorrectos en la segunda sección.Edítelo para que coincida con la primera sección, reconstrúyalo y estará listo.El final quedó así:

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;
};

Guías cambiadas para proteger a los inocentes.

Mismo problema, diferente solución.

En mi caso, estaba comprimiendo el archivo usando zip -r myapp.zip myapp.appResulta que el comando zip arruinó el paquete.Comprimirlo desde el buscador hizo que funcionara.

Tuve el mismo problema y después de intentar varias cosas: eliminé los derechos .plist de los derechos de firma de código (simplemente lo dejé en blanco), se compiló bien y se cargó FINALMENTE.

Buena suerte a todos :-D

Otro dato:Por un tiempo, mi aplicación funcionó.Ahora agregué soporte para compras dentro de la aplicación y, de repente, falla con el problema "Binario no válido/firma no válida".Tras una mirada cuidadosa, descubrí que el valor del identificador de aplicación en el archivo plist de derechos estaba desactivado.

Lo más probable es que esto tenga que ver con el hecho de que reemplacé el perfil de aprovisionamiento de uno comodín a uno específico de la aplicación (requerido para compras dentro de la aplicación).La ID de la aplicación incorrecta calificaba en el perfil anterior.No coincidía con el ID de la aplicación en info.plist, pero aparentemente iTunes lo perdonó.

Entonces, para resumir:

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

está bien, mientras

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

provoca "Binario no válido".

También tuve el mismo problema: durante la compilación noté que el aprovisionamiento no se agregó en la compilación.

La solución para mí fue configurar la compilación en el dispositivo iPhone como donde normalmente uso el simulador, pero luego no incluirá el perfil de aprovisionamiento...

Esto podría ser un error de novato.Normalmente no se puede compilar en el dispositivo, pero cuando lo hace para distribución, sí puede hacerlo.

Bueno, después de repetir los pasos varias veces, finalmente logré cargar mi aplicación.

No sé exactamente qué lo solucionó, pero antes del intento exitoso, cerré Xcode y Firefox y los reinicié.Supongo que una de esas aplicaciones tuvo un mal efecto.

Aquí hay un problema con el que me encontré:Agregué el binario a Subversion antes de cargarlo.Al comparar/comprimir el binario se incluyeron los directorios .svn ocultos, lo que arruinó la firma del código.

Probé varias cosas después de leer varias publicaciones, incluidas las anteriores.¡Lo que finalmente funcionó para mí fue empezar de nuevo!Eliminé todos los certificados y perfiles de aprovisionamiento asociados con mi aplicación.

Recreé un nuevo certificado de desarrollo y un nuevo certificado de distribución.Descargué nuevamente el certificado intermedio.Luego recreé tanto el perfil de desarrollo como el perfil de distribución.

Después de instalar los tres certificados (me di cuenta de que esta vez la distribución tenía claves públicas y privadas) y los dos perfiles de aprovisionamiento (¡mi perfil de distribución no fue marcado como si no tuviera un certificado válido!), todo funcionó.

Una vez que tomé la decisión de revocar todo y empezar de nuevo, solo me tomó unos 5 minutos crear el nuevo material y reinstalarlo.

Vea este enlace para la solución:

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

La respuesta corta es: "Finalmente revisé dos veces mi lista de información y descubrí algo.Agregué CFBundleIconFiles según las nuevas pautas, pero había una entrada vacía en la lista de matrices.Lo eliminé y lo volví a enviar, ¡y finalmente fue aceptado!".

Tuve un problema similar pero en Monotouch.Descubrí que mi perfil de versión estaba configurado para usar certificados de desarrollador.Debe tener un aspecto como este: enter image description here

Parece que este problema tiene muchas causas.Aquí está la solución a la mía:

Esto se aplica a cualquier persona que pertenezca a varios equipos de desarrollo (p. ej.sus propias aplicaciones y sus empresas).

Si crea la compilación con un conjunto de credenciales y la vuelve a firmar con una diferente (p. ej.para distribución ad hoc/appstore), debe asegúrese de que la compilación se creó y firmó originalmente con credenciales que pertenecen al mismo equipo de desarrollo de iOS al que pertenecen las credenciales de distribución con las que está volviendo a firmar.

Por lo tanto, no cree con las credenciales de "Indy Dev Inc" y luego intente implementar con las credenciales de "Company Inc".Asegúrese de configurar las credenciales de desarrollo y distribución de "Company Inc", y úselas.

Publiqué más información sobre esto en mi blog: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

Yo tuve el mismo problema.Estaba listo para tirar la toalla con este problema, pero lo descubrí cuando fui a verificar mi código usando Murky.Siempre leo las diferencias de los archivos que cambiaron antes de registrarme.Al hacerlo esta vez noté que el archivo project.pbxproj había cambiado... y en la sección Distribución la entrada para "PROVISIONING_PROFILE[sdk=iphoneos*]" estaba en blanco.

Salir y reiniciar Xcode no funcionó para mí.En lugar de eso, entré en la configuración de mi proyecto y de destino y cambié la firma del código para seleccionar directamente mi perfil de Distribución en lugar de depender de la función de selección automática.Hacer esto provocó que el archivo project.pbxproj se completara con los valores correctos a pesar de que la función de selección automática supuestamente seleccionó exactamente el mismo perfil que seleccioné manualmente.

Necesito una cerveza...

Después de probar todas las demás soluciones enumeradas aquí, registramos una TSI con Apple.Habiendo seguido todos los pasos en Nota técnica TN2250 Nuestro problema se debió a que faltaba un recurso sellado o no era válido.En nuestro caso fue ._.DS_Store.

El ".." se llama un archivo Apple Double y es el resultado de copiar la carpeta del Proyecto Xcode, *descomprimida*, hacia y desde un sistema de archivos que no soporta adecuadamente las 'bifurcaciones de recursos' de HFS+ (usadas para firmas de código).Estos extras".." Los archivos resultan y provocan un error en la verificación de la firma del código.

Para limpiar los archivos problemáticos de Apple Double de la carpeta de su proyecto Xcode, ejecute el comando dot_clean en la carpeta de su proyecto Xcode, realice una compilación limpia y luego vuelva a archivar y volver a intentar enviar.

dot_clean /the/path/to/xcode/project

Nota:Puede simplemente arrastrar la carpeta del proyecto a la terminal para completar automáticamente la ruta

No aparece ningún mensaje cuando ejecuta el comando, pero la compilación del proyecto puede mostrar una advertencia sobre el archivo la próxima vez que cree.Puedes ignorar esto, la aplicación se validará y enviará correctamente.

Se resolvió esto limpiando el archivo myProject.xcodeproj (haga clic derecho, abra el paquete), el paquete contenía archivos del codesarrollador, después de eliminarlos, el problema se resolvió

Para mí la solución fue crear una certificación de distribución en:Portal de aprovisionamiento para desarrolladores de Apple.

Por si sirve de algo, quiero agregar qué fue lo que me solucionó este problema.Tuve un ?(signo de interrogación) en el título de mi aplicación que estaba causando el error.

Recibí un binario no válido, si la aplicación no usa notificaciones push remotas, pero dejé sin comentar el código para registrar push y los delegados de devolución de llamada para registrar/recibir notificaciones remotas, incluso si el código no se usa.

Esto es reciente.Mi última presentación la semana pasada estuvo bien.Esta semana, devuelve un binario no válido.Por suerte, hay un correo electrónico que explica el error.

Estaba teniendo un problema similar, pero no uso entitlements.plist.Sin embargo, después de una docena de cargas fallidas, revisé mi info.plist y descubrí algo.Mi matriz CFBundleIconFiles tenía una entrada vacía.Lo eliminé y lo volví a enviar, ¡y finalmente fue aceptado!

En serio, ¿qué tan difícil sería para Apple exponer ese tipo de errores de validación?

Editar:No es inmediatamente evidente dónde están los CFBundleIconFiles porque usan un nombre diferente.En la vista de información del proyecto, haga clic en Ctrl y seleccione "Mostrar claves/valores sin procesar" y luego verá las referencias a CFBundleWhatever.En el caso de este editor, estaba intentando utilizar un archivo icon=72-@2x.png que no existía.

Mis dos centavos:

Descargue la última versión del Cargador de aplicaciones.Acabo de actualizar y ahora aparece un mensaje de error diferente.

Acabo de pasar por este problema (otra vez) pero esta vez descubrí que mi perfil de distribución tenía el estado "No válido".Si cree que todo lo demás está bien, vuelva a verificar el estado en el portal y renueve o vuelva a descargar todo lo que no esté en estado Activo.

Recibí un binario no válido después de cargar una aplicación, sin seguimiento por correo electrónico explicando por qué falló.Intenté hacer un par de cosas a la vez y no estoy seguro de cuál de las siguientes realmente lo solucionó:

Macbook Pro reiniciado
Moví el código fuente de mi proyecto de una unidad NTFS a una unidad HFS+ y lo volví a compilar.

Tuve un problema con esto y con el SDK 4.3 GM.Una de nuestras aplicaciones no superó la carga recibida.Resultó ser un problema de perfil de aprovisionamiento.Regeneré el perfil de la tienda de aplicaciones y funcionó bien.

Mi solución implicó crear una nueva ID de aplicación.No estoy seguro exactamente de por qué se solucionó, pero sospecho que es posible que los identificadores de paquete no coincidan: la creación del nuevo ID de aplicación me obligó a asegurarme de que mi aplicación y iTunes esperaban lo mismo.

Otra solución:

Para mí, simplemente configurar los certificados de 'Liberación' en 'firma de código' lo solucionó.Inicialmente estaban configurados en "No firmar con código".

Para mí, el problema se resolvió volviendo a guardar una imagen PNG con la opción no entrelazada.En versiones anteriores se permitían png entrelazados, pero sepa que estas imágenes pueden provocar un binario no válido.

Mi mensaje de manzana:Archivo de icono dañado: el archivo de icono iconGQ@2x.png parece estar dañado.Su icono no debe ser un archivo PNG entrelazado.

Puedes ver si el PNG está entrelazado usando el comando "archivo" en la terminal:Eva-Madrazos-Macbook-Pro-2: GQ 7 Integraciones ADS EVA $ FILE *.png default.png:Datos de imagen PNG, 320 x 480, RGB de 8 bits/color, no entrelazado

Buena suerte, Eva

Quiero señalar la posibilidad de enviar un correo electrónico a Apple y pedirles que revisen sus registros.Hice precisamente eso, después de haber probado muchas cosas primero.Fue necesario recordárselo después de casi cuatro semanas, pero finalmente respondieron y señalaron el lugar exacto del problema.

El problema en mi caso fue que había probado previamente otros íconos de aplicaciones y aún quedaba una referencia a la imagen anterior en 'CFBundleIcons'.Utilicé la función de arrastrar y soltar para configurar el ícono, pero no noté que el contenido anterior no se borró por completo antes de agregar la nueva referencia.

Para ver la referencia defectuosa, fue necesario expandir las flechas para ver todos y cada uno de los subelementos del archivo plist.Un consejo es hacer clic derecho en el archivo y seleccionar la opción para ver el contenido sin formato.De esa forma no necesitarás expandir nada.

Probé todas las demás soluciones propuestas, pero nada ayudó.

Terminé creando un nuevo proyecto Xcode y copie todo mi código y recursos en él.Eso funcionó y mi aplicación fue colocada en la cola de revisión.

También puedo recomendar Notas técnicas de Apple sobre la firma de código para depuración/verificación.

El uuid no está permitido.Lo arreglé eliminando todo [[UIDevice currentDevice] UniqueIdentifier];

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow