Distribuire l'app Beta agli utenti remoti

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

1. Utilizzare il programma Enterprise per sviluppatori; Costoso ed eccessivo

2. Usa TestFlight; Solo un misero numero di 25 tester "interni" consentiti prima che vengano messe in atto linee guida estreme per più persone (perché non metterlo solo sull'App Store a questo punto ...?)

3. Dai loro tutto il mio progetto Xcode e chiedi all'utente di costruirlo nel proprio ambiente Xcode; Impossibile chiedere a persone non esperte di 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 ... Grande seccatura per gli altri / Le persone potrebbero non voler farlo al di fuori della mia azienda

L'app che sto sviluppando verrà utilizzata dalle persone della comunità scientifica per controllare un dispositivo specifico realizzato dalla mia azienda. È possibile che non sia mai all'altezza degli standard Apple per le app sull'App Store, ma potrebbe essere utilizzato da più di 100 persone in un prossimo futuro. Immagino che la vera domanda che sto ponendo sia: come posso ottenere la mia app beta "par-par" a un folto gruppo di persone?

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

Aiuta a gestire la registrazione e la gestione degli utenti per ricevere notifiche e servizi offerti agli utenti finali. Sei ancora impaziente di gestire il 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 a pagamento di Apple.

• http://hockeyapp.net/features/

A lungo termine, vorrai portare l'app in uno dei negozi Apple poiché "abusare" della firma della distribuzione aziendale è sia costoso in termini di tempo e denaro da configurare che nel tempo, non è così difficile ottenere un'app attraverso la revisione. Sì, potresti essere ritardato di un mese o due o più, ma se persisti, è un'app rara che non può essere distribuita a meno che tu non stia infrangendo una delle regole di cui Apple si preoccupa molto come l'inclusione di framework che utilizzano API private o che eseguono 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, autofirmare e quindi installare la propria app. Potrebbe volare per gli utenti motivati ​​di un'app speciale. GitHub o altri strumenti di fonte ti aiuterebbero a distribuire gli aggiornamenti, ma supporteresti le persone e probabilmente faresti pagare per quello invece dell'app stessa con quel modello.

È possibile utilizzare TestFlight per beta tester esterni. Ciò ti consentirà di testare fino a 2.500 tester esterni. Non è necessario conoscere i loro UDID, solo i loro indirizzi e-mail.

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

In tal caso, è possibile distribuire l'app in un formato "mezzo cotto". Invece di distribuire il progetto Xcode comprese le fonti, che affermi di non volere, potresti distribuire la tua app come binari compilati, ma non ancora firmati.

Al fine di rendere più facile per i tuoi clienti, dovresti creare o ottenere un semplice strumento che l'utente può eseguire e che firma i codici binari con l'AppleID dell'utente. Non avrebbero bisogno di essere registrati Apple Developers.

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 eventuali identificatori casuali 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.

Fabric.io è davvero eccezionale.

Puoi inviare un invito via e-mail e riceverai l'UDID corrispondente via e-mail.

E il punto davvero positivo di Fabric sono le funzionalità di Crashlytics e Analytics .

La piattaforma Fabric è composta da quattro kit modulari che affrontano alcune delle sfide più comuni e diffuse che tutti gli sviluppatori di app devono affrontare: stabilità, distribuzione, entrate e identità. Combina i servizi di Crashlytics, MoPub, Answers, Twitter e altri per aiutarti a creare app più stabili, generare entrate attraverso il più grande scambio di annunci per dispositivi mobili del mondo e consentirti di accedere ai sistemi di accesso di Twitter e ai ricchi flussi di contenuti in tempo reale per una maggiore distribuzione e identità più semplice. E Fabric è stato realizzato pensando alla facilità d'uso. L'installazione richiede solo pochi minuti e la maggior parte delle funzionalità richiede solo poche righe di codice, quindi dedichi meno tempo alla gestione degli SDK e più tempo alla creazione della migliore esperienza per i tuoi utenti.

http://frabric.io

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

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

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

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