verificar puedo problemas para mejor mail fiables empresarial desarrolladores desarrollador correo confiable apps app abrir iphone iphone-developer-program

puedo - Soluciones alternativas para la distribución interna de aplicaciones empresariales de iPhone.



no puedo verificar app en iphone (10)

Un cliente nos ha pedido que desarrollemos una aplicación propia patentada para administrar sus sistemas back-end. Sin embargo, somos una pequeña empresa de desarrollo y estoy seguro de que su empresa no tiene más de 500 empleados.

¿Existen soluciones alternativas, pero similares, para distribuir esta aplicación a su empresa sin pasar por el programa empresarial de iPhone?

(Solo para aclarar: obviamente, nos gustaría pasar por el programa oficial de la empresa, pero viendo que la compañía no tiene más de 500 empleados, esto no es posible).

ACTUALIZACIÓN (27/09): Parece que Apple eliminó el límite de 500 empleados para la distribución empresarial. Consulte aquí . Por lo tanto, esta será nuestra ruta ahora (lo cual es útil porque la aplicación se está completando). Actualizaré esto a medida que pasemos por el proceso si alguien quiere que lo haga, para que otros puedan tener una idea de cómo es el proceso real.

¿Cómo asegura Apple que su empresa tiene más de 500 personas? Le daría una oportunidad a través del programa empresarial de todos modos ...

No haría jailbreak, no haría ad-hoc porque está limitado a 100, y no haría que todos pusieran sus teléfonos en modo desarrollador.

Para una futura capacidad de mantenimiento, el modo empresarial es el camino a seguir, así que vea si puede navegar a través del proceso sin mencionar que puede que no sea del todo 500 usuarios.

También, vi tu comentario sobre el desarrollo usando MonoTouch. Hablaría con Apple sobre esto antes de que hagas otra cosa, ya que, debido a los cambios recientes en su política, estoy bastante seguro de que esta aplicación será rechazada por la App Store y el programa Enterprise.

Edición: Revisé la página web de Mono. Parece que Apple todavía puede dejar entrar aplicaciones mono, y los creadores de Mono insisten en que es kosher, pero puede correr el riesgo de que su futura aplicación sea retirada de los teléfonos en cualquier momento.

Una mejor edición: directamente desde el sitio web mono: Enterprise MonoTouch

Es importante señalar que los nuevos términos del Acuerdo de desarrollador de iPhone son para la implementación de AppStore y no para el programa Enterprise que permite la implementación de la aplicación interna para los usuarios de la empresa (mediante el programa Enterprise Deployment).

Por lo tanto, puede ser bueno allí siempre que pueda ingresar al programa empresarial.

Estaba investigando esto ayer y hoy, y parece que Apple acaba de eliminar (dentro de la semana pasada) el requisito de más de 500 empleados para el desarrollo empresarial. Sin embargo, creo que necesitará desarrollar / implementar para un cliente en particular utilizando un kit de herramientas de desarrollo registrado por el cliente.

Entonces, si trabaja para el cliente A y el cliente B, tanto el cliente A como el B deberán registrarse con Apple como desarrolladores de negocios, momento en el cual puede desarrollar aplicaciones para ellos (como contratista) y usar sus herramientas para crear e implementar dentro de sus empresas. Creo que sería una buena idea que su empresa también se registre como desarrollador de negocios.

Apple aún requiere que tengas un número DUNS de Dun & Bradstreet para registrarte como Business Developer.

La distribución ad-hoc está limitada a 100 dispositivos por aplicación, eso es cierto, pero puede agregar el proyecto n veces al centro de desarrolladores de Apple, de modo que puede implementarlo en n * 100 dispositivos

Olie dijo:

Las únicas opciones reales que tiene son ... Hasta 100 dispositivos como distribución ad-hoc. Distribución empresarial (requiere> 500 empleados) Todo el mundo tiene que desplazar su dispositivo a algún centro de TI y construirse como un dispositivo "desarrollador". (¡Ay!) Jail-broken.

Pero para ser claros (corrígeme si me equivoco):

  1. Si utiliza el método de distribución "Ad-hoc", sus clientes verán la aplicación desaparecer después de exactamente 3 meses.
  2. solo se pueden usar hasta 100 dispositivos para la prueba (es decir, en el "modo de desarrollador") y, además, la aplicación desaparecerá después de 3 meses.

Entonces, Apple no nos da ninguna opción, ¿eres realmente grande (> 500 empleados)? ok, así que puedes hacer lo que quieras, etc. de lo contrario ... "byebye"

Además, olvídese de lo que dijo "Bryce" antes, una aplicación como la que describió sería rechazada con la motivación de "audiencia limitada".

iOS no es para aplicaciones empresariales ... si no quieres confiar en algunos hackers inteligentes (por ejemplo, jailbreak)

Otra obvia, aunque no necesariamente agradable, es enviar su aplicación a la tienda de aplicaciones como una aplicación, pero solo se puede acceder con una contraseña de cliente. Suponiendo que pueda superar el proceso de la tienda aapp, esto podría funcionar para usted.

Puede enviar la aplicación como una aplicación completamente gratuita en la AppStore, pero requiere que el usuario inicie sesión y se autentique para usarla. De esa manera, cualquiera puede descargarlo, pero tú controlas quién puede usarlo realmente. Apple hace toda la distribución por usted y no tiene que preocuparse por las implementaciones Ad-Hoc o los departamentos de TI.

Luego, construye un sistema de administración de configuración realmente simple en un servidor web (o plataforma como Google AppEngine) que administra la autenticación de las aplicaciones.

Cuando un usuario inicia la aplicación gratuita, se le solicita un nombre de usuario / contraseña / lo que sea. Esa información se envía al sistema de administración de configuración basada en web y se confirma. Si la aplicación recibe una confirmación aceptable del sistema de administración de la configuración, se desbloquea para su uso por parte de ese usuario.

La aplicación puede volver a autenticarse cada vez que se inicie (útil si quiere tener mucho control) o puede almacenar un archivo de clave localmente, lo que indica que se ha autenticado. Si ve el archivo de clave local cuando se inicia la aplicación, se considera autenticado y nunca vuelve a verificar.

Depende de usted si utiliza una cuenta de usuario por persona o una para toda la empresa.

Este estilo de distribución es muy útil si quiere tener control de quién puede usar la aplicación pero desea la facilidad de implementación que proporciona la AppStore.

Apple ha aceptado muchas aplicaciones en la AppStore que utilizan este método de autenticación contra un servidor remoto (Skype es un ejemplo perfecto).

Si realiza un seguimiento del UDID del dispositivo en el servidor de configuración, también puede precargarlo para que funcione un determinado conjunto de dispositivos.

Además, nada de lo que he descrito es específico para iPhone, por lo que puede usar el mismo sistema y conceptos de administración de la configuración en otras plataformas como Android (o incluso escritorios) si alguna vez transfiere la aplicación o crea otras aplicaciones que lo necesiten en el futuro.

Además, dado que la acción de autenticación de dispositivos no requiere un uso intensivo del procesador ni de los datos, es probable que nunca incurra en un costo si lo crea en Google AppEngine, ya que nunca superará las cuotas gratuitas y obtendrá la estabilidad y la escalabilidad de la arquitectura de back-end de Google.

Dado que esta implementación en particular es para administrar un sistema de back-end interno, la implementación a través de la AppStore puede parecer insegura porque hay información patentada incorporada en la aplicación, en particular la información que le permite conectarse y autenticarse con el back-end. sistemas

La solución a eso es no incluir esta información dentro de la aplicación y simplemente hacer que esa información sea parte de la respuesta que la aplicación recibe del servidor de administración de configuración. Básicamente, la aplicación contiene la lógica necesaria para realizar su función, pero sin la información de conexión no tiene capacidad para administrar ningún sistema back-end.

Si hace que la aplicación se autentique cada vez que se inicie, puede cambiar la información de conexión en el servidor de configuración y la aplicación se actualizará a la nueva información sin que sea necesaria ninguna nueva implementación. El usuario solo necesita reiniciar la aplicación. Esto le da a su cliente la flexibilidad de cambiar su configuración de red interna sin invalidar el código de su aplicación. También puede hacer que esta información se pueda configurar manualmente dentro de la aplicación, pero luego incurra en un costo de TI al configurar la aplicación en cada dispositivo y si ya va a configurar un sistema de administración de la configuración, también puede utilizarla.

Para asegurar aún más la solución anterior, es posible que desee que el sistema de administración de la configuración sea interno y esté detrás del firewall de la compañía para que, independientemente de quién obtenga la aplicación, no puedan conectarse al sistema de configuración a menos que estén dentro de la red de la compañía.

Puede omitir completamente el proceso de aprobación de App-Store o Enterprise Developer Program, si desarrolla su aplicación como solución HTML5 pura. Esta tecnología se llama webapps. Y pueden ser bastante avanzados en funcionalidad. Usted tiene automáticamente la capacidad de plataforma cruzada y opciones de implementación muy fáciles (ya que este clip web se puede distribuir a través de archivos de configuración .mobileconfig) Consulte http://www.apple.com/webapps/whatarewebapps.html

Sobre las únicas elecciones reales que tienes son ...

  • Hasta 100 dispositivos como distribución ad-hoc.
  • Distribución enterprize (requiere> 500 empleados)
  • Todo el mundo tiene que dirigir su dispositivo a un centro de TI y construirse como un dispositivo "desarrollador". (¡Ay!)
  • Jail-broken.

Jail-broken puede sonar aterrador, pero en realidad es bastante avanzado, hoy en día, y puede manejarse con bastante facilidad. Sin embargo, anula su garantía (a menos que esté dispuesto a restaurarse en la fábrica y no ser honesto al respecto)

Aún así, técnicamente, es una opción disponible y puede hacerse funcionar, si está dispuesto a planificarla.

Háganos saber qué decide, y los pros y los contras de ese método.