Distribuzione dell'app Beta agli utenti remoti

8

Sembra che non ci sia una soluzione semplice per fornire la mia app beta iOS alle persone al di fuori del contatto fisico. I modi in cui ho trovato di farlo SENZA usare l'App Store (che Apple dice esplicitamente non è per il beta testing) sono:

  1. Utilizzare il programma Enterprise Developer; Costoso ed eccessivo

  2. Usa TestFlight; Solo fino a un misero 25 tester "interni" consentiti prima che vengano introdotte linee guida estreme per più persone (perché non metterlo semplicemente su App Store a questo punto ...?)

  3. Fornisci loro il mio intero progetto Xcode e chiedi all'utente di crearlo nel proprio ambiente Xcode; Impossibile chiedere a persone che non conoscono la tecnologia + Non voglio dare il mio progetto a persone esterne alla mia azienda

  4. Sviluppo ad-hoc; Fai in modo che tutti mi diano i loro UDID ... Enorme problema per gli altri / Le persone potrebbero non volerlo fare fuori dalla mia compagnia

L'app che sto sviluppando verrà utilizzata dalle persone nella comunità scientifica per controllare un dispositivo specifico che la mia azienda sta realizzando. C'è la possibilità che non sia mai all'altezza degli standard Apple per le app su App Store, ma potrebbe essere utilizzato da più di 100 persone nel prossimo futuro. Immagino che la vera domanda che sto ponendo sia: Come faccio ad avere la mia app beta "sub-par" su un grande gruppo di persone?

    
posta Jel 23.12.2015 - 18:49
fonte

4 risposte

1

In passato dovevi scegliere tra l'app Hockey e TestFlight per gruppi beta di grandi dimensioni - ma ora che Apple ha acquistato TestFlight e devi passare attraverso la revisione per ottenere una beta, il framework di beta test dell'app Hockey è il più adatto alle tue esigenze elencate.

Aiuta a gestire la registrazione e la gestione degli utenti per ottenere notifiche notificate e rese disponibili agli utenti finali. Sei ancora alle prese con la gestione del tuo pool di test AppleID, ma ora che il limite di 100 dispositivi è stato allentato, puoi eseguire test beta piuttosto ampi utilizzando Hockey e i normali limiti di account per sviluppatori pagati da Apple.

A lungo termine, vorrai portare l'app in uno dei negozi Apple perché "abusare" della firma della distribuzione aziendale è costosa sia in termini di tempo che di denaro da configurare e nel tempo, non è difficile ottenere un'app attraverso la revisione . Sì, potresti rimanere in ritardo di un mese o due o più, ma se persisti, è un'app rara che non può essere distribuita a meno che non stia infrangendo una delle regole a cui Apple si preoccupa molto come includere framework che utilizzano API private o che funzionano codice che scaricano dopo che l'app è stata firmata e inviata per l'approvazione.

L'unica altra opzione è quella di spedire il codice sorgente a ciascun utente e fargli usare Xcode per creare, firmare autonomamente e poi installare la propria app. Questo potrebbe volare per gli utenti motivati di un'app di specialità. GitHub o altri strumenti di origine potrebbero aiutarti a distribuire gli aggiornamenti, ma tu sosterrai le persone e, eventualmente, li ricaricheresti anziché l'app stessa sotto quel modello.

    
risposta data 29.12.2015 - 18:05
fonte
2

Potresti usare TestFlight per beta tester esterni. Ciò ti consentirà di testare fino a 2.500 tester esterni. Non hai bisogno di conoscere i loro UDID, solo i loro indirizzi email.

Tuttavia, presumo che tu pensi che la tua app non sarà in grado di superare anche la recensione dell'app beta meno restrittiva.

In tal caso, puoi distribuire la tua app in un modulo "mezzo cotto". Invece di distribuire il progetto Xcode, inclusi i sorgenti, che dichiari di non volere, potresti distribuire la tua app come binari compilati, ma non ancora firmati,

.

Per rendere più semplice per i tuoi clienti, dovresti creare o creare un semplice strumento che l'utente possa eseguire per assegnare i binari ai codici con l'AppleID dell'utente. Non avrebbero bisogno di essere registrati sviluppatori Apple.

Lo strumento dovrebbe modificare il nome del bundle in Info.plist e utilizzare lo strumento "codesign" per firmare l'app:

Per rendere univoco il nome del bundle, basta aggiungere qualsiasi identificatore casuale al nome del bundle nel file plist.

Lo strumento codesign può essere utilizzato con un comando come questo:

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

dove "la mia identità" è l'identità (apple-id) dell'utente finale.

    
risposta data 26.12.2015 - 12:43
fonte
1

Fabric.io è davvero eccezionale.

Puoi inviare un invito via email e riceverai il corrispondente UDID via email.

E il vero punto di forza di Fabric sono le funzionalità Crashlytics e Analytics .

The Fabric platform is made of four modular kits that address some of the most common and pervasive challenges that all app developers face: stability, distribution, revenue and identity. It combines the services of Crashlytics, MoPub, Answers, Twitter and others to help you build more stable apps, generate revenue through the world’s largest mobile ad exchange and enable you to tap into Twitter’s sign-in systems and rich streams of real-time content for greater distribution and simpler identity. And Fabric was built with ease of use in mind. Installation takes just minutes, and most features only require a few lines of code – so you spend less time managing SDKs and more time building the best experience for your users.

link

    
risposta data 28.12.2015 - 15:58
fonte
0

Diawi è un'ottima piattaforma per ciò che stai cercando di fare.

In pratica carichi la tua app su questa piattaforma e ottieni un link breve che puoi inviare ai tuoi tester. Quando aprono il collegamento sul proprio dispositivo iOS, viene richiesto di installare l'app.

Come dettagliato sul loro sito web, il trucco è che devi aggiungere il dispositivo di ciascun utente al profilo di provisioning utilizzato per installare l'applicazione.

Questo è probabilmente facile come per gli utenti, senza distribuire tramite TestFlight.

    
risposta data 28.12.2015 - 15:34
fonte

Leggi altre domande sui tag