Distribución de la aplicación Beta a usuarios remotos


8

Parece que no hay una solución simple para proporcionar mi aplicación beta de iOS a personas fuera del contacto físico. Las formas en que he encontrado para hacer esto SIN usar la App Store (que Apple dice explícitamente que no es para pruebas Beta) son:

  1. Use el programa Enterprise Developer; Caro y excesivo

  2. Use TestFlight; Solo se permiten hasta 25 probadores "internos" miserables antes de que se establezcan Directrices extremas para más personas (¿Por qué no ponerlo en la App Store en este momento ...?)

  3. Dales todo mi proyecto Xcode y haz que el usuario lo construya en su propio entorno Xcode; Imposible preguntar a personas no expertas en tecnología + No quiero entregar mi proyecto a personas ajenas a mi empresa

  4. Desarrollo ad-hoc; Haz que todos me den sus UDID ... Grandes molestias para los demás / Es posible que las personas no quieran hacerlo fuera de mi empresa

La aplicación que estoy desarrollando será utilizada por personas de la comunidad científica para controlar un dispositivo específico que mi empresa está haciendo. Existe la posibilidad de que nunca cumpla con los estándares de Apple para aplicaciones en la App Store, pero podría ser utilizado por más de 100 personas en un futuro cercano. Supongo que la verdadera pregunta que estoy haciendo es: ¿cómo hago para que mi aplicación beta "por debajo del par" llegue a un gran grupo de personas?

Respuestas:


2

En el pasado, tenía que elegir entre la aplicación Hockey y TestFlight para grandes grupos beta, pero ahora que Apple ha comprado TestFlight y debe revisarlo para obtener una versión beta, el marco de prueba beta de la aplicación Hockey es el más adecuado para sus necesidades. en la lista

Ayuda a gestionar la inscripción de usuarios y la gestión de recibir notificaciones de las compilaciones y entregarlas a los usuarios finales. Todavía está en apuros para administrar su grupo de AppleID de prueba, pero ahora que se ha aflojado el límite de 100 dispositivos, puede hacer pruebas beta bastante amplias utilizando Hockey y los límites normales de la cuenta de desarrollador de pago de Apple.

A largo plazo, querrá obtener la aplicación en una de las tiendas de Apple, ya que "abusar" de la firma de distribución de la empresa es costosa en tiempo y dinero para configurarla y, con el tiempo, no es tan difícil obtener una aplicación a través de la revisión. Sí, es posible que se demore un mes o dos o más, pero si persiste, es una aplicación rara que no se puede implementar a menos que esté rompiendo una de las reglas que a Apple le importa mucho, como incluir marcos que usan API privada o que se ejecutan el código que descargan después de que la aplicación se haya firmado y enviado para su aprobación.

Su única otra opción es enviar el código fuente a cada usuario y hacer que usen Xcode para compilar, firmar y luego instalar su propia aplicación. Eso podría volar para usuarios motivados de una aplicación especializada. GitHub u otras herramientas de origen lo ayudarían a enviar actualizaciones, pero estaría apoyando a las personas y posiblemente cobraría por eso en lugar de la aplicación en ese modelo.


¿Entonces no hay forma de distribuir mi aplicación sin obtener previamente los UDID de cada persona a la que quiero dársela? Ugh, me sorprende que no puedo simplemente enviar el archivo .ipa a nadie y hacer que lo suelten en sus propios iTunes
Jel

@jel - no. Puede usar AppleID a través de TestFlight o un servicio que recolecta el UDID por usted. Esto es por diseño: iOS no quiere cargar aplicaciones de forma lateral. Desde el 29 de junio de 2007, ese ha sido el estándar y no veo que cambie pronto. Especialmente desde que iOS 9 y Xcode permiten a cualquiera firmar sus propias aplicaciones.
bmike

2

Puede usar TestFlight para probadores beta externos. Esto le permitirá realizar pruebas con hasta 2.500 probadores externos. No necesita conocer sus UDID, solo sus direcciones de correo electrónico.

Sin embargo, supongo que cree que su aplicación no podrá pasar ni siquiera la revisión beta de la aplicación menos restrictiva.

En ese caso, puede distribuir su aplicación en forma "a medias". En lugar de entregar el proyecto Xcode, incluidas las fuentes, que usted declara que no desea, puede distribuir su aplicación como binarios compilados, pero aún no firmados.

Para facilitar a sus clientes, tendría que crear o crear una herramienta simple que el usuario pueda ejecutar que codifique los binarios con el ID de Apple del usuario. No tendrían que estar registrados como Desarrolladores de Apple.

La herramienta necesitaría alterar el nombre del paquete en Info.plist y usar la herramienta "codeign" para firmar la aplicación:

Para que el nombre del paquete sea único, simplemente agregue cualquier identificador aleatorio al nombre del paquete en el archivo plist.

La herramienta de código se puede usar con un comando como este:

codesign --force --sign "my identity"  <path for .app file>

donde "mi identidad" es la identidad (id de manzana) del usuario final.


Es posible que desee mencionar que Apple les pidió recientemente a los creadores de F.lux que dejen de hacer exactamente esa práctica.
GhostLyrics

2
Sí, es cierto, pero la diferencia, según lo veo, entre esto y F.lux es principalmente que el grupo F.lux fue Apple Developers registrado. Estaban violando un acuerdo que tenían con Apple, y para asegurarse de que sus posibles otras aplicaciones o programas Mac no estuvieran prohibidos, optaron por dejar de recomendar la descarga de la aplicación iOS. Además, la aplicación F.lux tenía una gran cantidad de usuarios potenciales. Esto suena como un equipo de investigación especializado que podría ser utilizado por unos cientos de usuarios como máximo. En ese caso, Apple probablemente no muestre interés en él.
jksoegaard

1
Bueno, los primeros dos párrafos estaban allí para asegurarte de que conoces las reglas menos estrictas con respecto a la revisión de la aplicación beta, en comparación con el proceso ordinario de revisión de la aplicación. Sobre la herramienta, no veo por qué piensas que es terriblemente complicada. Se trata de ejecutar las herramientas de línea de comandos existentes que suministra Apple. Es decir, pegar una GUI fácil de usar sobre las herramientas existentes. No puedo ver cómo eso es inútil.
jksoegaard

He agregado detalles sobre cómo ejecutar el comando del código, etc. También puede consultar la documentación de Apple: developer.apple.com/library/mac/documentation/Security/…
jksoegaard

1

Fabric.io es realmente genial.

Puede enviar una invitación por correo electrónico y recibirá el UDID correspondiente por correo electrónico.

Y el punto realmente bueno de Fabric son las características de Crashlytics y Analytics .

La plataforma Fabric está compuesta por cuatro kits modulares que abordan algunos de los desafíos más comunes y omnipresentes que enfrentan todos los desarrolladores de aplicaciones: estabilidad, distribución, ingresos e identidad. Combina los servicios de Crashlytics, MoPub, Answers, Twitter y otros para ayudarlo a crear aplicaciones más estables, generar ingresos a través del intercambio de anuncios móviles más grande del mundo y permitirle aprovechar los sistemas de inicio de sesión de Twitter y las ricas secuencias de contenido en tiempo real. para una mayor distribución y una identidad más simple. Y Fabric fue construido con la facilidad de uso en mente. La instalación lleva solo unos minutos, y la mayoría de las funciones solo requieren unas pocas líneas de código, por lo que pasa menos tiempo administrando SDK y más tiempo creando la mejor experiencia para sus usuarios.

http://frabric.io


0

Diawi es una gran plataforma para lo que estás buscando hacer.

Básicamente, carga su aplicación en esta plataforma y obtiene un breve enlace que puede enviar a sus evaluadores. Cuando abren el enlace en su dispositivo iOS, se les solicita que instalen la aplicación.

Como se detalla en su sitio web, el problema es que debe agregar el dispositivo de cada usuario al perfil de aprovisionamiento utilizado para instalar la aplicación.

Esto es probablemente lo más fácil para los usuarios, sin distribuir a través de TestFlight.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.