¿Por qué los dispositivos de desarrollo le dan más recursos que un dispositivo típico?

He creado una aplicación que funciona en mi iPod Touch de cuarta generación y en el iPod touch de quinta generación de mi empresa.

Estábamos a punto de lanzar, cuando encontramos un bloqueo que ocurre después de que cualquier dispositivo que no sea desarrollador ejecuta la aplicación *.

La idea surgió de que un dispositivo registrado como un "dispositivo desarrollador" le da a su aplicación más recursos para usar. Esto no me parece correcto, ya que no puedo pensar en ninguna razón que exista; creo que es más probable que sea un problema con la creación o el perfil de la provisión.

Sin embargo, eso provocó una discusión. ¿Por qué existen dispositivos como los kits de desarrollo de la consola de juegos, dispositivos que tienen más capacidades que la plataforma de destino, en primer lugar? Por supuesto, es bueno hacer una prueba de esfuerzo de un programa, pero ¿no tendría más sentido una representación más precisa de la plataforma objetivo?

TL; DR: ¿Por qué los kits de desarrollo tienen más recursos que las plataformas de destino?

* Con un dispositivo no desarrollador que sea> 3ra generación. Dispositivo iOS que descarga la aplicación desde nuestro servidor, no directamente desde una computadora con la aplicación y xcode instalados.

_{Tenga en cuenta que hay otra pregunta que se lee similar, pero en realidad es diferente, porque esa otra pregunta es sobre el simulador, y entiendo que existen grandes diferencias entre el uso de un simulador y un dispositivo real.}

El entorno de desarrollo (para cualquier cosa, ya sea una aplicación Java independiente, o un entorno móvil, o un dispositivo integrado) generalmente tiene la capacidad de realizar depuración remota, registro mejorado y otros tipos de introspección del entorno (uno normalmente no quiere para agregar todos los ganchos para un analizador lógico en un dispositivo integrado de producción).

Estas cosas adicionales requieren recursos adicionales. Abrir un depurador remoto en una máquina virtual u otro entorno remoto requiere algunos recursos en el otro extremo. En el ámbito severamente limitado de los dispositivos móviles, es posible que estos recursos adicionales lo pongan por encima del límite otorgado a una aplicación estándar. Por lo tanto, se otorgan más recursos al entorno de desarrollo para que no alcance el límite de recursos cuando comience a realizar registros o depuraciones adicionales.

Esto va más allá hasta el punto de que siempre necesita probar algo en un espejo del entorno de producción. Confiar en que funciona en las máquinas del desarrollador con todos sus ajustes y diferentes variables no es suficiente para verificar que funcione correctamente en la producción.

Le permite crear una prueba de concepto codiciosa de recursos que luego puede optimizar.

No tiene sentido bloquear una aplicación porque está a 5 bytes por encima del límite de memoria (que se puede resolver configurando el optimizador para ahorrar espacio en la versión, pero está ejecutando una versión de depuración),

aparecerá una advertencia en el registro cuando supere el límite del consumidor mientras que las pruebas serán buenas aquí.

Es en parte una cuestión de "confianza". Se supone que los desarrolladores saben lo que están haciendo y, por lo tanto, se les da acceso ilimitado al dispositivo y a todos sus recursos. Esto puede ser de gran ayuda para las pequeñas empresas y los equipos de desarrollo, donde los recursos no utilizados son recursos desperdiciados.

En un entorno corporativo más amplio, o especialmente el público en general, este tipo de acceso se convierte en una responsabilidad, debido a preocupaciones de seguridad y la necesidad de jugar bien con otras aplicaciones que también necesitan recursos.

Esto no es realmente una idea nueva. Tengo dos máquinas en el trabajo. En mi máquina de desarrollador tengo acceso administrativo, pero está aislado de Internet. Mi otra máquina, que uso para el correo electrónico, Office y acceso a Internet, ni siquiera me da la capacidad de instalar programas.

Es por eso que debe probar su aplicación en un dispositivo que no sea desarrollador antes de implementarla, para asegurarse de que se comporta bien. :)

Con iOS, un dispositivo habilitado para Desarrollo le permite ejecutar directamente compilaciones de depuración, que pueden contener un conjunto diferente de errores de compilación que una compilación de lanzamiento, así como ejecutar aplicaciones bajo una protuberancia de depuración, que puede cambiar sutilmente el tiempo de hilo y el uso de memoria, que también puede mostrar / ocultar varios subprocesos y errores de memoria filtrados.

Un dispositivo de desarrollo no sería de gran utilidad sin una capacidad de depuración, y un dispositivo de usuario con capacidad de depuración presentaría un (más) grave problema de seguridad de datos de aplicaciones y aplicaciones.