development apps apple app iphone ios app-store code-signing itunesconnect

apps - Binario no válido para aplicaciones de iPhone



itunes connect (30)

Intento subir una aplicación al iPhone App Store, pero recibo 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 han sido eliminados, ya que esta página se ha convertido en un repositorio 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 App Store, consulte Pasos para cargar una aplicación de iPhone en AppStore .

Acabo de pasar por esta molestia (nuevamente) pero esta vez descubrí que mi perfil de distribución tenía un estado de "Inválido". Si cree que todo lo demás es correcto, vuelva a verificar el estado en el portal y renueve / vuelva a descargar todo lo que no esté en estado Activo.

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

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

No sé exactamente qué lo solucionó, pero antes del intento exitoso, cerré Xcode y Firefox y los reinicié. Creo que una de esas aplicaciones tenía un mal juju.

Después de probar todas las otras correcciones enumeradas aquí, registramos una TSI con Apple. Habiendo seguido todos los pasos en la Nota técnica TN2250, nuestro problema fue causado porque faltaba un recurso sellado o no era válido. En nuestro caso fue ._.DS_Store .

El " ." se llama un archivo doble de Apple y es el resultado de copiar la carpeta del proyecto Xcode, * descomprimido *, hacia y desde un sistema de archivos que no admite correctamente las "horquillas de recursos" de HFS + (utilizadas para las firmas de código). Estos extra " ." los resultados de los archivos y la falla de verificación de la firma del código de causa.

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

dot_clean /the/path/to/xcode/project

Nota: solo puede arrastrar la carpeta del proyecto al terminal para completar automáticamente la ruta

No hay 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 compile. Puede ignorar esto, la aplicación validará y enviará con éxito.

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 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 aparente que los CFBundleIconFiles son porque usan un nombre diferente. En la vista de información del proyecto, haga clic en Ctl y seleccione "Mostrar claves / valores sin procesar" y verá las referencias a CFBundleWhatever. En el caso de este editor, intentaba usar un archivo [email protected] inexistente.

Intenté varias cosas después de leer varias publicaciones, incluidas las de arriba. ¡Lo que finalmente funcionó para mí estaba comenzando completamente! Eliminé cada certificado y perfil de aprovisionamiento asociado con mi aplicación.

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

Después de instalar los tres certificados (noté que la distribución tenía ambas claves privadas y públicas esta vez) y los dos perfiles de aprovisionamiento (¡mi perfil de distribución no se marcó porque no tenía un certificado válido!), Todo funcionó.

Una vez que tomé la decisión de revocar todo y volver a empezar, solo tardé unos 5 minutos en crear las nuevas cosas y volver a instalarlas.

Mi solución consistió en crear una nueva ID de aplicación. No estoy seguro de por qué lo solucionó, pero sospecho que puede haber sido un identificador de paquete no coincidente: la creación del nuevo ID de aplicación me obligó a asegurarme de que mi aplicación y iTunes esperaban lo mismo.

Mis dos centavos:

Descargue la última versión de Application Loader. Acabo de actualizar y ahora recibo un mensaje de error diferente.

Mismo problema, diferente solución.

En mi caso, estaba comprimiendo el archivo usando zip -r myapp.zip myapp.app Resulta que el comando zip atornilló el paquete. Comprimirlo desde el buscador lo hizo funcionar.

Otra solución:

Para mí, simplemente se solucionó el ajuste de los certificados ''Release'' en ''code signing''. Inicialmente se configuraron como ''No codificar señal''.

Otro punto de datos: por un tiempo, mi aplicación fue procesada. Ahora agregué compatibilidad con las compras integradas en la aplicación, y de repente falla con un problema de "firma binaria no válida / inválida". Tras una cuidadosa búsqueda, descubrí que el valor del identificador de la 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 he reemplazado el perfil de aprovisionamiento de uno comodín a uno específico de la aplicación (requerido para compras en la aplicación). La ID de aplicación incorrecta calificó en el perfil anterior. No coincidía con la ID de la aplicación en info.plist, pero aparentemente iTunes lo perdonó.

Entonces, para recapitular:

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

causa "binario inválido".

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

Mi mensaje de Apple: archivo de icono corrupto: el ícono del archivo í[email protected] 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: anuncios de integración GQ 7 Eva $ archivo * .png Default.png: datos de imagen PNG, 320 x 480, 8 bits / color RGB, sin entrelazado

Buena suerte, Eva

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 múltiples equipos de desarrollo (por ejemplo, sus propias aplicaciones y sus empresas).

Si construye la compilación con un conjunto de credenciales y lo vuelve a firmar con una diferente (por ejemplo, para la distribución de adhoc / appstore), debe asegurarse de que la compilación se haya creado y firmado originalmente con las credenciales pertenecientes al mismo equipo de desarrollo de iOS que el Las credenciales de distribución con las que vuelve a firmar pertenecen .

Por lo tanto, no compile con las credenciales de "Indy Dev Inc" y luego intente implementarlas con las credenciales de "Company Inc". Asegúrese de configurar el desarrollador "Company Inc" y las credenciales de distribución y usarlas.

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

Por lo que vale, quiero agregar qué fue lo que solucionó este problema para mí. Tuve un ? (interrogación) en el título de mi aplicación que causaba el error.

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

Terminé creando un nuevo proyecto Xcode y copiando todo mi código y recursos en él. Eso hizo el truco, 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 la depuración / verificación.

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

El problema en mi caso era que había probado anteriormente otros íconos de la aplicación, y todavía quedaba una referencia a la imagen anterior en ''CFBundleIcons''. Utilicé la función de arrastrar y soltar para configurar el ícono, pero no me di cuenta de que el contenido anterior no se borró por completo antes de agregar la nueva referencia.

Para ver la referencia defectuosa, era necesario expandir las flechas para ver todos y cada uno de los sub elementos en el archivo plist. Una sugerencia 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.

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

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

Recibí un código binario no válido, si la aplicación no usa notificaciones push remotas, pero dejé el código para registrar push y los delegados de devolución de llamada para registrar / recibir notificaciones remotas sin comentarios, 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. Afortunadamente, hay un correo electrónico que explica el error.

Resolvió esto limpiando el archivo myProject.xcodeproj (clic derecho, abrir el paquete), el paquete contenía archivos del co-desarrollador, luego de eliminarlos se solucionó el problema

Según mi experiencia, Xcode a veces se confunde sobre qué certificado de firma usar. Adquirí el hábito de cerrar y reiniciar Xcode después de cualquier cambio en la configuración de firma de código (y hacer una compilación limpia) para evitar este problema.

Solo quería mencionar que yo también tuve el problema con el zip desde la línea de comando. El problema radica en la forma en que maneja los enlaces simbólicos por defecto. Utilizando:

zip -y -r myapp.zip myapp.app

Resolvió ese problema.

También tuve el mismo problema, cuando construí noté que el aprovisionamiento no se había agregado en la compilación.

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

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

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 una hora más o menos de buscar y buscar en Google, encontré la fuente el error. Dentro de Xcode, copié la configuración de la versión y creé una nueva configuración de distribución y luego cambié la identidad de la 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 de 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ítalo para que coincida con la primera sección, reconstruye, y deberías estar listo para continuar. El último 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 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 cambiadas para proteger a los inocentes

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

Buena suerte a todos :-D

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

Tuve un problema similar, pero en Monotouch. Descubrí que mi perfil de lanzamiento estaba configurado para usar cert de desarrollador. Debe tener un aspecto como este:

Yo tuve el mismo problema. Estaba listo para tirar la toalla sobre este problema, pero lo descubrí cuando fui a revisar mi código usando Murky. Siempre leo los diffs en 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 de Distribución, la entrada para "PROVISIONING_PROFILE [sdk = iphoneos *] "Estaba en blanco.

Salir y reiniciar Xcode no funcionó para mí. En cambio, entré en mi configuración de proyecto y de destino y cambié la firma de código para seleccionar directamente mi perfil de distribución en lugar de confiar en la función de selección automática. Al hacerlo, el archivo project.pbxproj se llenó con los valores correctos, aunque la función de selección automática supuestamente seleccionó exactamente el mismo perfil que seleccioné manualmente.

Necesito una cerveza...

uuid no está permitido. Lo arreglé por eliminar todo [[UIDevice currentDevice] uniqueIdentifier];