Vincular solo el marco embedded con otro marco dynamic falla al comstackr y ejecutar en el dispositivo

tl dr

Al vincular su marco embedded con otro marco y no vincular otro marco con su aplicación, la requinetworking code signature missing cuando se comstack y ejecuta en el dispositivo.

descripción:

Preparar:

Mi configuration es bastante simple (Swift 2.3 y Xcode Xcode 8.0; versión Build 8S162m):

  • Usando Carthage (0.17.2) he creado Other.framework con xcodebuild 8.0 y TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 carthage build --platform iOS
  • MyApp ha embedded My.framework .
  • La aplicación y los proyectos marco están bajo un solo espacio de trabajo Xcode.
  • Hade vinculado Other.framework a My.framework SOLO (es decir, MyApp no está vinculado a Other.framework en absoluto). El punto aquí es que MyApp no necesita usar Other.framework API.

Problema:

Todo parece funcionar bien, hasta que compile y ejecute la aplicación en el dispositivo . La aplicación se inició y el process se cancela con el siguiente error de Xcode:

 dyld: Library not loaded: @rpath/Other.framework/Other Referenced from: /private/var/containers/Bundle/Application/DCF0331F-FF23-43CF-AE79-B3857D5A6EE3/MyApp.app/Frameworks/My.framework/My Reason: no suitable image found. Did find: /private/var/containers/Bundle/Application/DCF0331F-FF23-43CF-AE79-B3857D5A6EE3/MyApp.app/Frameworks/My.framework/Frameworks/Other.framework/Other: requinetworking code signature missing for '/private/var/containers/Bundle/Application/DCF0331F-FF23-43CF-AE79-B3857D5A6EE3/MyApp.app/Frameworks/My.framework/Frameworks/Other.framework/Other' 

He verificado la firma de Other.framework y me pareció bien. Además,

Solución (solución)

Vincula MyApp con Other.framework . Horrible … Esto se siente roto.

Al vincular el mismo binary Other.framework a MyApp y resolver el problema de esta manera, señala, Other.framework está construido correctamente y puede volver a firmarse correctamente. Posiblemente, nada que ver con Carthage.

NOTA: Existe un problema similar iOS 8+ framework con marco embedded nested , sin embargo, el mío tiene un poco de otro motivo.

El problema no tiene nada que ver con los frameworks nesteds. Se trata completamente de la validation de códigos distintivos. dyld informa que Other.framework no tiene una signatura de código. Necesitas firmar el marco. Xcode lo debe hacer por usted, así que tengo curiosidad de saber cómo se está construyendo Other.framework.

Probablemente puedas solucionar esto tú solo con firmarlo.

 codesign --force --deep --preserve-metadata=identifier,entitlements,resource-rules,requirements,flags,team-identifier --sign - /path/to/Other.framework 

o simplemente renunciar a su aplicación:

 codesign --force --deep --preserve-metadata=identifier,entitlements,resource-rules,requirements,flags,team-identifier --sign - /path/to/My.app 

Solucioné mi problema exacto siguiendo esta guía
No necesita vincular su 'Otros.framework' a su MyApp. Simplemente agregue la secuencia de commands de ejecución para firmar cualquier marco de integración que requiera la falta de la firma de código

Hablando de este problema en la página de Carthage github , queda claro que la solución mencionada en la pregunta es, en realidad, un comportamiento esperado :

Carthage no admite frameworks nesteds.

Los frameworks de anidamiento no le permiten reutilizar esos frameworks. Por ejemplo, si A.framework y B.framework dependen de Other.framework , ninguno de ellos puede anidar Other.framework ; de lo contrario, podría terminar con 2 versiones diferentes, y la correcta podría no elegirse en time de ejecución.

La forma correcta de hacerlo es enumerarla como una dependencia, pero vincularla al objective de la aplicación.

Discusión completa: vincular solo el marco embedded con otro marco dynamic falla al comstackr y ejecutar en el dispositivo: "falta la firma de código requerida"

Esto no estaba claro en el file README, por lo que planteé otro problema al solicitar la actualización de la documentation:

Actualización a README: vincular frameworks dynamics a frameworks embeddeds también requiere vincularlos con el objective de aplicación # 1427

Esto se resuelve y cierra en el ámbito de la RP:

Actualización # 1427 de README: vincula dependencies desde frameworks integrados al objective de la aplicación