ios - house - apple developer enterprise program

Compruebe si la aplicación es ad-hoc | dev | app-store build en tiempo de ejecución

Question

Me gustaría comprobar esto para obtener información de compilación en una pantalla de depuración. ¿Hay una manera de comprobar esto en tiempo de ejecución?

Me doy cuenta de que podría establecer indicadores de compilación para las compilaciones o similares, pero si hay un método existente que podría aprovechar, me gustaría aprovechar eso.

Answer 1

El tiempo de ejecución es el momento equivocado para hacer esto.

Tu aplicación puede ser rechazada de la tienda si intentas hacerlo. O puede ser aprobado, y luego haces un lanzamiento de corrección de errores urgente y ese puede ser rechazado.

Como @rmaddy sugirió en un comentario, debes hacerlo en tiempo de compilación.

Edite la configuración de su proyecto para definir esta constante: CONFIGURATION_$(CONFIGURATION) , luego haga esto en su código:

#if defined (CONFIGURATION_Debug) || defined (CONFIGURATION_Adhoc)
  NSLog( @"Warning message");
#endif

Fuente / más detalles: http://ios-dev.gravitini.com/2009/02/identifying-current-xcode-configuration.html

Puede envolver una función de tiempo de ejecución a su alrededor si lo desea. Quizás:

void debugLog(NSString *str)
{
    #if defined (CONFIGURATION_Debug)
      NSLog(@"%@", str);
    #endif
}

Answer 2

Esto es probablemente lo que estás buscando. Abhi tiene una buena y completa explicación y esta esencia tiene el código real:

https://github.com/blindsightcorp/BSMobileProvision

Answer 3

Si bien estoy de acuerdo con Abhi Beckert en que el tiempo de ejecución no es el momento adecuado para hacerlo (¡use directivas de preprocesador y configuración de compilación!), Quería aclarar algunos de los detalles y especulaciones en la respuesta / comentarios anteriores y aclarar algunas cosas podría hacer Tengan paciencia, esta será una respuesta más larga ...

Hay un montón de piezas de datos que podrían ir bajo el paraguas genérico de "Información de compilación". Una lista no exhaustiva de tales cosas incluiría: Configuración de compilación, Identidad de firma de código, Hora de compilación, Fecha de compilación, Número de versión de comercialización, Nombre de revisión de SCM, Nombre de sucursal de SCM, Identidad del equipo del perfil de aprovisionamiento, Caducidad del perfil de aprovisionamiento, Número de compilación de CI .. .La lista sigue y sigue.

Suponiendo que, por el momento, su pregunta se centrara específicamente en obtener información sobre el tipo de certificado de iOS y el perfil de aprovisionamiento utilizados para la compilación, entonces tendré que ir con un ''No'' muy firme como respuesta a la pregunta: ¿Existe algún problema? ¿Cómo verificar [la información de construcción usando un método de API existente] en tiempo de ejecución? Dejando de lado brevemente: colectivamente, estos dos puntos de datos se denominan " Identidad de firma de código " en la Configuración de compilación de Xcode 4.6.x o "CODE_SIGN_IDENTITY" para los entusiastas de la configuración de compilación de la línea de comandos.

A partir del momento en que se hizo esta pregunta, no hay una API de iOS pública singular a la que pueda llamar para obtener información sobre el tipo de firma de código para la aplicación actualmente en ejecución. Las razones probables detrás de esto son numerosas, pero aquí hay algunos ejemplos:

1. Los desarrolladores pueden construir sus propios esquemas de construcción y crear configuraciones. Esto significa que podemos tener un esquema y una configuración de compilación, o un esquema y docenas de configuraciones de compilación, o incluso miles de cada una. Naturalmente, a cada esquema se le puede asignar una configuración de construcción diferente, y a esas configuraciones se les puede asignar una identidad de firma de código diferente. Como puede imaginar, un desarrollador o equipo no necesita mucha personalización para que esto se vuelva rápidamente caótico.
2. Las identidades de firma de código solo requieren que un Perfil de aprovisionamiento no vencido emitido para el identificador de la aplicación actual, contenga una copia de la clave pública del certificado utilizado para firmar el binario. Para aquellos que trabajan en un equipo, es posible que tenga un único Perfil de aprovisionamiento que contenga todos los certificados de los desarrolladores en el equipo, o puede hacer perfiles de aprovisionamiento individuales para cada desarrollador en el equipo que contiene solo sus certificados. Este es otro punto de variación en cómo los desarrolladores pueden elegir construir su aplicación.
3. Los desarrolladores pueden compartir un solo certificado (tsk tsk) o emitir sus propios certificados ... sí, lo has adivinado, incluso más variaciones.

Esta hipotética API única debería entonces tener acceso en tiempo de ejecución a todos sus datos de configuración de compilación, certificados y perfiles de aprovisionamiento para poder desentrañar la configuración "efectiva" aplicada en el momento de la compilación y reducir todos esos datos a un cadena finita ... simplemente para una vista de diagnóstico del desarrollador ... no es una hazaña imposible por cualquier tramo de la imaginación, pero una operación potencialmente tan computacionalmente intensa para un beneficio insignificante del desarrollador definitivamente se ubicaría en un lugar bajo en casi la lista de prioridades de cualquiera. Se eliminaría aún más en la lista de prioridades, dado que otras opciones (como las marcas de tiempo de compilación) son más confiables, más económicas de configurar y más sencillas de mantener a largo plazo.

Ahora, en cuanto a la pregunta semi-al acecho de "¿Puedo hacerlo en tiempo de ejecución?" Yo diría enfáticamente "Sí, puedes".

Como usted sabe, las compilaciones de dispositivos son los únicos tipos de compilaciones que requieren firma de código. Parte del proceso crea un archivo en el paquete principal denominado ''embedded.mobileprovision''. Este es un archivo que pertenece a la caja de arena de su aplicación y, por lo tanto, es algo que absolutamente tiene la capacidad de abrir mediante programación:

[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]

Los archivos .mobileprovision están codificados en PCKS # 7 y contienen datos binarios y de texto. La información que busca es la de la lista basada en texto incrustada en los datos de PCKS # 7. Primero, usando OS X echemos un vistazo a estos datos de texto de una de las compilaciones de su dispositivo:

1. Haga clic con el botón derecho en el paquete .app de su compilación para el dispositivo y seleccione ''Mostrar contenido del paquete''
2. Copie el archivo embedded.mobileprovision en un lugar fácilmente accesible.
3. Abra ese archivo con su editor de texto preferido.

Inmediatamente se da cuenta de que hay una gran cantidad de datos binarios, pero puede distinguir partes de los datos de texto. Desplazándose hacia la derecha, verá un xml con un estilo plist, solo que no es tan fácil de leer en esta vista. Podemos usar una herramienta de línea de comandos OS X para ver estos datos de una manera más organizada:

1. Abra Terminal y ''cd'' en la carpeta que contiene su copia de embedded.mobileprovision.
2. Ejecute: seguridad cms -D -i embedded.mobileprovision

Esto mostrará el archivo xml plist a la ventana de la terminal para su lectura en un formato de tabulación agradable. Si repite este proceso para una compilación Ad-Hoc, una compilación de Dev y una compilación de App Store, comenzará a notar las claves en este texto que son indicativas de los tipos respectivos de compilaciones. Para compilaciones firmadas con un certificado ''iPhone Developer: ...'' (o ''Dev'' compila como se indica en la publicación original), busque:

<key>get-task-allow</key>
<true/>

La clave ''get-task-allow'' es lo que se usa para indicar a iOS si la aplicación permitirá que un depurador se conecte a ella. En el caso de un binario firmado por ''Desarrollador de iPhone'', esto tiene sentido. Normalmente, debería ser capaz de depurar en el dispositivo al enviar el código de Xcode a su dispositivo para realizar pruebas.

La diferencia entre ''Ad-Hoc'' y ''App Store'' requiere algunas verificaciones adicionales. Esta misma clave ''get-task-allow'' se establecerá en false para estos dos tipos de distribuciones:

<key>get-task-allow</key>
<false/>

Sin embargo, las compilaciones ''Ad-Hoc'' tienen un conjunto definido de ''Dispositivos de aprovisionamiento'' que no están presentes en las compilaciones ''App Store'':

<key>ProvisionedDevices</key>
<array>
    <string>abcdef01234567890abcdef01234567890abacde</string>
    <string>1abcdef01234567890abcdef01234567890abacd</string>
    <string>2abcdef01234567890abcdef01234567890abacd</string>
</array>

Entonces, ¿qué significa esto en términos prácticos para la pregunta de verificación en tiempo de ejecución? Sí, puede hacerlo abriendo el archivo embedded.mobileprovision fuera del paquete principal y analizando los datos para tomar una decisión informada, pero eso es algo de lo que sería completamente responsable de implementarse. Deberá agregar lógica para manejar los casos en los que falte ese archivo (por ejemplo, compilaciones del simulador) y analizar los datos de PCKS # 7 o extraer de manera confiable el contenido ASCII del archivo en el que su código puede ejecutar una serie de búsquedas de cadenas. . Como es evidente, esto requerirá un esfuerzo no trivial para una solución un tanto frágil que de otra manera podría acomodarse fácilmente mediante configuraciones de compilación y macros de preprocesadores como Abhi Beckert esbozó en la respuesta anterior.

¿Qué pasa con el riesgo de rechazo de la App Store? ¿Es esto ''ilegal'' o ''subversivo''?

Suponiendo que utiliza todas las API públicas al leer y analizar el contenido del archivo embedded.mobileprovision, esto está perfectamente permitido por los términos actuales de la App Store. Cualquier cosa en la caja de arena de su aplicación es un juego justo que incluye la integración .mobileprovision si está presente. Todavía me advierto con mucho cuidado de no ir por este camino, haciéndome eco de los comentarios de Abhi Beckert. Es un esfuerzo considerable para menos del 1% de los casos de uso y ¡hay soluciones mucho más fáciles que existen! Además, las vistas de diagnóstico del desarrollador no deberían estar en las versiones de lanzamiento de la App Store, sin embargo, la decisión de incluir un código extraño está totalmente en sus manos.

Espero que esto aclare cualquier pregunta persistente, pero si no es así, por favor agregue un comentario y podemos ver lo que podemos hacer.