Aplicación binaria de iPhone no válida

Estoy intentando cargar una aplicación en la App Store de iPhone, 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: Se han eliminado los detalles de la pregunta original, 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 la App Store, consulte Pasos para cargar una aplicación de iPhone a la AppStore .

En mi experiencia, Xcode se confunde ocasionalmente sobre qué certificado de firma usar. Me acostumbré a salir y reiniciar Xcode después de cualquier cambio en la configuración de firma de código (y hacer una compilación limpia) para solucionar este problema.

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

zip -y -r myapp.zip myapp.app

Resuelto 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 una hora más o menos buscando en Google y buscando, encontré la fuente del error. Dentro de Xcode, había copiado la configuración de lanzamiento y creado 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 te encuentras con el mismo error, busca en tu directorio [ProjectName] .xcodeproj el archivo project.pbxproj y ábrelo en tu 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, reconstruya y estará listo para comenzar. 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;
};

guías cambiadas para proteger a los inocentes

Mismo problema, solución diferente.

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

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

Buena suerte a todos :-D

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

Esto, muy probablemente, tuvo que ver con el hecho de que reemplacé el perfil de aprovisionamiento de uno con comodines a uno específico de la aplicación (requerido para compras dentro de la aplicación). La ID de aplicación incorrecta calificó bajo el perfil anterior. No coincidía con el 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

provoca "binario no válido".

Vea este enlace para la solución:

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

La respuesta corta es que "Finalmente verifiqué mi info.plist y descubrí algo. Agregué CFBundleIconFiles según las nuevas pautas, pero había una entrada vacía en la lista de arreglos. Lo eliminé y volví a enviar, y finalmente fue ¡aceptado!"

También tuve el mismo problema, al compilar 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 la distribución, 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 mala juju.

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 estropeó la firma del código.

Probé varias cosas después de leer varias publicaciones, incluidas las anteriores. ¡Lo que finalmente funcionó para mí fue comenzar 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é el certificado intermedio nuevamente. Luego recreé tanto el perfil de desarrollo como el perfil de distribución.

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

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

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

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 (por ejemplo, sus propias aplicaciones y sus empresas).

Si crea la compilación con un conjunto de credenciales y vuelve a firmarla con una diferente (por ejemplo, para la distribución adhoc / appstore), debe asegurarse de que la compilación se compiló y firmó originalmente con credenciales que pertenecen 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 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 distribución y de desarrollo de "Company Inc", y utilícelas.

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 sobre este problema, pero lo descubrí cuando fui a verificar mi código usando Murky. Siempre hojeo 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 su lugar, 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 confiar en la función de selección automática. Hacer esto hizo 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 otras correcciones enumeradas aquí, registramos un TSI con Apple. Después de haber seguido todos los pasos de la Nota técnica TN2250, nuestro problema se debió a que faltaba un recurso sellado o no era válido. En nuestro caso lo fue ._.DS_Store.

El " .." se llama un archivo Apple Double, y es el resultado de copiar la carpeta Xcode Project, * descomprimida *, en un sistema de archivos que no admite correctamente las 'bifurcaciones de recursos' de HFS + (utilizado para firmas de código). Estos extra " ". Los archivos resultan y provocan una falla en la verificación de 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, haga una compilación limpia y luego vuelva a archivar y vuelva a intentar su envío.

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 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á correctamente.

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

Para mí, la solución fue crear una certificación de distribución en: Apple Developer Provisioning Portal .

Por lo que vale, quiero agregar qué fue lo que solucionó este problema para mí. 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 la notificación push remota, pero dejé el código para registrar push y los delegados de devolución de llamada para registrarse / recibir notificación remota sin comentar, incluso si el código no se usa.

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

Estaba teniendo un problema similar, pero no uso entity.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 se ve inmediatamente dónde están los CFBundleIconFiles porque usan un nombre diferente. En la vista de información del proyecto, haga clic Ctl 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 [email protected] inexistente.

Mis dos centavos:

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

Acabo de pasar por esta molestia (nuevamente) pero esta vez encontré que mi perfil de distribución tenía un estado de "No válido". Si cree que todo lo demás está bien, vuelva a verificar el estado en el portal y renueve / 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 de 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ó:

1. Macbook Pro reiniciado
2. 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 de 4.3 GM. Una de nuestras aplicaciones no superaría 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ó la creación de una nueva ID de aplicación. No estoy seguro exactamente de por qué eso lo solucionó, pero sospecho que pueden haber sido identificadores de paquete no coincidentes: la creación de la nueva ID de aplicación me obligó a asegurarme de que mi aplicación e iTunes esperaban lo mismo.

Otra solución:

Para mí, simplemente configurar los certificados de 'Liberación' en 'firma de código' lo solucionó. Inicialmente se establecieron en 'No firmar 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 los png entrelazados, pero sepa que estas imágenes pueden causar el binario no válido.

Mi mensaje de Apple: Archivo de icono dañado: el archivo de icono [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: GQ 7 integracion 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 recordarles después de casi cuatro semanas, pero finalmente respondieron y señalaron el lugar exacto del problema.

El problema en mi caso fue que ya había probado otros íconos de aplicaciones y aún quedaba una referencia a la imagen anterior en 'CFBundleIcons'. Usé la funcionalidad de arrastrar y soltar para configurar el ícono, pero no noté que el contenido anterior no se borró completamente 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 en el archivo plist. Un consejo es hacer clic derecho en el archivo y seleccionar la opción para ver el contenido sin procesar. De esa forma no necesitarás expandir nada.

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

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

También puedo recomendar notas técnicas de Apples sobre firma de código para depuración / verificación.

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