Mi aplicación acaba de ser rechazada por utilizar el marco de soporte de anuncios. ¿Qué biblioteca es responsable?

Esta fue simplemente una actualización que no cambió nada que ver con el motivo del rechazo. Aquí está la respuesta del centro de resolución:

Razones del contrato de licencia del programa PLA 3.3.12

Descubrimos que su aplicación utiliza el identificador de publicidad de iOS, pero no incluye la funcionalidad de anuncios. Esto no cumple con los términos del Acuerdo de licencia del programa para desarrolladores de iOS, como lo requieren las Pautas de revisión de la App Store.

Específicamente, la sección 3.3.12 del Acuerdo de licencia del programa para desarrolladores de iOS establece:

"Usted y sus Aplicaciones (y cualquier tercero con el que haya contratado el servicio de publicidad) pueden utilizar el Identificador de publicidad y cualquier información obtenida mediante el uso del Identificador de publicidad, solo con el fin de ofrecer publicidad. Si un usuario restablece el Identificador de publicidad, luego acepta no combinar, correlacionar, vincular o asociar de otro modo, ya sea directa o indirectamente, el Identificador de publicidad anterior y cualquier información derivada con el Identificador de publicidad restablecido ".

Verifique su código, incluidas las bibliotecas de terceros, para eliminar cualquier instancia de:

clase: ASIdentifierManager
selector: AdvertisingIdentifier
marco: AdSupport.framework

Si planea incorporar anuncios en una versión futura, elimine el identificador de publicidad de su aplicación hasta que haya incluido la funcionalidad de anuncios.

Para ayudar a localizar el identificador de publicidad, utilice la herramienta "nm". Para obtener información sobre la herramienta "nm", abra una ventana de terminal e ingrese "man nm".

Si no tiene acceso a la fuente de las bibliotecas, es posible que pueda buscar el binario compilado usando las herramientas de línea de comando "strings" o "otool". La herramienta "cadenas" enumera los métodos que llama la biblioteca, y "otool -ov" enumerará las estructuras de clase Objective-C y sus métodos definidos. Estas técnicas pueden ayudarlo a determinar dónde reside el código problemático.

Las bibliotecas de terceros que estoy usando son la última versión de parse.com sdk, latest version of flurry analytics, and version 2.2 of test flight. ¿Alguien sabe qué biblioteca es el problema? Gracias

En Terminal:

1. Vaya a la carpeta raíz de su proyecto
2. Tipo: grep -r advertisingIdentifier . (el punto al final es crítico)

Esto comprobará de forma recursiva todos los archivos y le dará el nombre de la biblioteca infractora.

(en mi caso fue Flurry)

Actualizar

Google lanzó el SDK de iOS de Google Analytics Services v3.03c que elimina la dependencia de AdSupport.framework de forma predeterminada.

Entrada completa del registro de cambios para la versión de lanzamiento 3.03c (19 de febrero de 2014): https://developers.google.com/analytics/devguides/collection/ios/changelog

Awnser viejo

Mi problema fue con Google Analytics y TestFlight.

Para TestFlight, simplemente actualizo la biblioteca a la versión 2.2.1 ( https://www.testflightapp.com/sdk/ios/release_notes/2.2.1/ ).

Pero para actualizar Google Analytics tuve que eliminar la bandera -ObjC. Pero como uso Cocoapods para administrar algunas de las terceras bibliotecas, no pude simplemente eliminarlo. Entonces hice lo siguiente:

1 - comenzó a actualizar libGoogleAnalytics.a a la versión 3.03a (5 de febrero de 2014)

2 - luego se eliminó también el AdSupport.framework

3 - se agregó "-force_load \" $ {PROJECT_DIR} /Source/Library/GoogleAnalyticsServicesiOS_3.03a "" en "Target -> Build Settings -> Other Linker Flags" (Tenga en cuenta que en mi proyecto, GoogleAnalytics está dentro de / Source / Biblioteca / carpeta, y tienes que configurar la tuya propia)

Pero como no pude eliminar la bandera -ObjC, busqué cómo usar la bandera -force_load con Cocoapods, luego encontré dos enlaces útiles:

1 - https://github.com/CocoaPods/CocoaPods/issues/712

2 - http://www.deanmao.com/2012/12/31/linker-error-using-cocoapods/

Para resumir, cambié el indicador -ObjC por "-force_load $ (TARGET_BUILD_DIR) /libPods.a" también en "Destino -> Configuración de compilación -> Otros indicadores del vinculador"

Pero nuevamente, cuando intenté publicar mi aplicación, recibí un error que me decía que el compilador no encontró libPods.a, así que fui a "Destino -> Configuración de compilación -> Otras banderas del vinculador -> Versión" y cambie esta cadena $ (TARGET_BUILD_DIR) a $ {BUILT_PRODUCTS_DIR}.

Así que mis otras banderas de vinculadores se volvieron como la imagen de abajo.

Espero ayudar a alguien.

Lo siento por mi ingles. =]

Para mí, tanto Flurry Analytics como TestFlight fueron el problema.

Para TestFlight, es tan fácil como actualizarlo. La versión 2.2.1 no causará ningún problema (verifiqué usando cadenas, como sugiere Apple)

Para Flurry, actualmente no existe una solución aparte de eliminar Flurry y, contrariamente a la sugerencia de Lou Weed, incluso si AdSupport.framework no está vinculado, su aplicación será rechazada.

Aquí está la respuesta de soporte técnico de Flurry:

"Gracias por comunicarse con Flurry. Recientemente nos enteramos de que Apple ha rechazado algunas aplicaciones que cree que utilizan el identificador para publicidad (IDFA) sin incluir la funcionalidad de anuncios. Tenga en cuenta que Flurry no recopila el IDFA a menos que una aplicación incluya AdSupport .framework para la funcionalidad publicitaria. Estamos buscando una aclaración con Apple y actualizaremos a nuestros clientes afectados a medida que obtengamos más información durante los próximos días ".

Flurry acaba de lanzar la versión 4.3.2 de su SDK, que aborda específicamente ese problema.

Resulta que Testflight v2.2.0 fue el conflicto. Desde entonces lo han arreglado de acuerdo con su registro de cambios:Consolidate both SDK versions into one which removes all access to ASIdentifierManager

Crashlytics fue el problema. Tuvimos algunas aplicaciones rechazadas por eso. Pero ya hablé con Crashlytics y hoy lanzaron una nueva actualización (versión 2.1.6) que soluciona este problema.

Varias bibliotecas tienen AdSupport.framework, pero no lo usan a menos que se llamen específicamente. Crashlytics estaba llamando al marco porque tenía que verificar si la aplicación tenía soporte para anuncios. Y ese cambio se implementó en la versión 2.1.5

Entonces, si está usando crashlytics, esa es la razón más probable. Para solucionarlo, simplemente vuelva a archivar su aplicación para que crashlytics pueda usar la nueva versión con esta solución.

Respuesta del equipo de Crashlytics: "Acabamos de publicar una actualización para esto. ¿Puedes compilar y ejecutar tu aplicación de nuevo con la aplicación para Mac abierta para que pueda actualizar tu SDK? ¡Estarás listo para continuar después de eso! Vuelve a enviar :) "

PD: Esto está empezando a suceder porque Apple parece haber cambiado su política para el uso de ADSupport.

Anteriormente había escrito lo siguiente en los comentarios, dirigiendo a las personas a los comandos terminales "strings" o "otool". Sin embargo, realmente me gusta la respuesta sugerida de usar grep. Entonces puedes probarlo primero. Mi sugerencia es anteponer "git" a ese comando, porque es mucho más rápido:

git grep advertisingIdentifier

Si eso no funciona, intente (como se publicó anteriormente):

grep -r advertisingIdentifier . 

Lo que sigue es lo que había escrito anteriormente en un comentario anterior, como un procedimiento para los comandos de terminal:

Puede buscar los archivos de su proyecto en Xcode o puede intentar eliminar el marco de AdSupport para ver qué falla en el tiempo de compilación / ejecución.

Para usar el terminal, haga clic en Spotlight (buscar) y escriba Terminal. Espere a que aparezca como una aplicación en los resultados de búsqueda.

Una vez en la Terminal, escriba "cd" seguido de un espacio, luego arrastre y suelte su carpeta de compilación de Xcode desde el Finder a la Terminal. Esto debería escribir automáticamente el nombre de la carpeta. Presiona Enter y te cambiará los directorios (cd) a esa carpeta.

Desde allí, escriba stringsluego un espacio, luego el nombre de archivo de su biblioteca o otool, un espacio y el nombre de archivo de la biblioteca. Debería poder presionar TAB para completar automáticamente los nombres de archivo.

¡Mi aplicación también fue rechazada con el mismo error! Encontré una aparición de AdvertisingIdentifier en el último SDK de Facebook (3.12). Tal vez pueda verificar la existencia de una ocurrencia en su biblioteca con el método siguiente:

Abrí el FacebookSDK.framework como una biblioteca en la terminal y escribí el siguiente comando

otool -v -s __TEXT __objc_methname FacebookSDK | grep AdvertisingIdentifier

Pero no sé qué hacer. ¿Mi aplicación fue rechazada debido a esta referencia? En caso afirmativo, ¿qué debo hacer si quiero utilizar las funciones de Facebook en mi aplicación?

Esto es un poco más complicado de lo que parece en la superficie. Después de algunos experimentos, descubrí que AdSupport Framework está vinculado incluso si solo accede directamente a las clases a las que se hace referencia en AdSupport Framework. Irónicamente [AsIdentifierManager class],, que se utiliza en muchas bibliotecas de terceros para comprobar si AdSupport Framework se ha vinculado o no, en realidad hará que AdSupport Framework esté vinculado. Ofuscar la clase mediante el uso NSClassFromString(@"AsIdentfierManager")no hará que el marco de AdSupport se vincule automáticamente. Por supuesto, la mayor parte del tiempo este código estará en bibliotecas de terceros, por lo que no tendrá mucho control sobre él, sin embargo, esto es lo que está sucediendo.

Construí un proyecto de ejemplo en GitHub que ilustra este comportamiento usando el marco de Segment.io. https://github.com/distefam/AdSupportDemo

Flurry Analytics también utiliza esta API.
Salida terminal:

Binary file ./Lib/Flurry/libFlurry_4.3.0.a matches

Flurry dice que no se llama al selector si el marco de AdSupport no está vinculado.
Así que eliminé el marco e intenté enviarlo de nuevo.