"Rilasciare il rilascio anticipato spesso" per le app per Android e iPhone

6

Volevo conoscere le esperienze che gli altri hanno di fare il modo Agile di "Rilasciare presto, rilasciare spesso" con iPhone e App Android. Non è un problema con le webapps dato che l'aggiornamento avviene sul server e l'utente non deve fare nulla di specifico per gli aggiornamenti

Potrebbe non essere un grosso problema con Android, in quanto il processo di approvazione è fluido rispetto all'app store di iPhone.

Qualcuno può condividere le esperienze / i suggerimenti / gli esempi che hanno per il rilascio precoce e spesso nei mercati Android e iPhone?

    
posta leenasn 31.10.2011 - 12:16
fonte

5 risposte

6

Ci sono due differenze tra il rilascio da solo o il rilascio tramite Apples App Store:

  1. Ci vogliono 1-3 settimane per essere approvati per gli aggiornamenti. Spesso una settimana, a volte due, a volte tre.
  2. Si corre il rischio che l'aggiornamento venga respinto per un motivo o per un altro, quindi è necessario ripetere di nuovo la versione. L'approvazione dei rifiuti è rapida (1-5 giorni)

Quindi tutto ciò rende impossibile realizzare rilasci controllati più velocemente di tre settimane. Sei costretto a pianificare i tuoi rilasci e le scadenze in modo molto più accurato.

    
risposta data 31.10.2011 - 12:47
fonte
4

Sii consapevole del fattore di fastidio delle versioni molto frequenti. Una cosa è aggiornare la tua app Web quotidianamente, o anche più spesso, in modo che gli utenti vedano automaticamente le piccole modifiche apportate dalla versione precedente. Ma se un utente deve intervenire, per quanto piccolo, per installare nuovi aggiornamenti, gli aggiornamenti frequenti diventano fastidiosi.

Ho riscontrato app che sembrano aver bisogno di aggiornamenti costanti sia su iOS che su Android e lascia l'impressione che il software sia di bassa qualità. Le modifiche da una versione alla successiva sono spesso così piccole che sono difficili da notare, quindi come utente presumo che tutti questi aggiornamenti siano principalmente correzioni di bug. E se le modifiche sono evidenti, rende l'app meno prevedibile, meno familiare.

Direi che se la tua app non è abbastanza solida da renderla disponibile per almeno alcune settimane, considera l'attesa di rilasciare finché non lo è. So che a volte i bug non vengono scoperti fino a dopo il rilascio e, naturalmente, è necessario correggerli al più presto, ma se ciò accade più di una volta dovresti considerare i modi per migliorare il tuo processo di test.

Un altro modo di guardarlo è che ogni volta che pubblichi una nuova versione della tua app, stai dicendo "Ehi, guarda!" Se lo fai troppo spesso gli utenti che potrebbero essere rimasti colpiti da tutte le nuove cose che hai aggiunto tra la versione 1.0 e 2.0 saranno invece annoiati dalle differenze minime tra 1.9.6 e 1.9.7.

Un approccio migliore consiste nel progettare la tua app in modo da poter aggiornare i contenuti tutte le volte che vuoi senza aggiornare l'app stessa. Se sai che potresti voler cambiare l'aspetto dell'app nei vari giorni festivi, ad esempio, crea la tua app in modo che possa scaricare temi da un server invece di aggiornare l'app prima e dopo le festività.

    
risposta data 02.11.2011 - 13:41
fonte
2

Mi piacerebbe ridimensionare questo "processo di approvazione di Apple è come fare affari".

Nessuna app che ho mai inviato ha richiesto più di sette giorni per essere approvata.

Nella mia esperienza, se sei attento e consapevole, non avrai problemi a ottenere l'approvazione. Mezzo milione di app sono state approvate, e la mia esperienza è che devi davvero provare a non essere approvato. E, naturalmente, lamentarsi di un blog a riguardo è una buona attenzione e lascia la gente spaventata e preoccupata, piuttosto che essere semplicemente professionale sui requisiti della piattaforma.

La mia politica con le app per iPhone è di pubblicare presto e spesso. L'unica eccezione è se c'è una grande funzionalità di modifica del gioco che l'app ha di cui non vuoi mostrare la mano. Se il piano di marketing richiede qualcosa di sgradevole al momento del rilascio, non si vuole averne prima messo fuori una versione precoce. Questo è probabilmente vero su tutte le piattaforme.

    
risposta data 31.10.2011 - 13:19
fonte
2

Release Early

Questo è un po 'un problema nel caso di app per Android / iOS se il tuo canale principale di distribuzione e promozione sarà Market / AppStore. Se rilasci troppo presto con alcuni problemi (specialmente quelli di forza-chiusura) avrai alcuni utenti infelici. Solo pochi utenti infelici riescono a ottenere i punteggi iniziali piuttosto bassi, il che danneggerebbe seriamente le possibilità che l'app mostrasse il massimo nei risultati di ricerca.

Release Often

Come già detto, non è un problema con Market. Con AppStore è migliorato un sacco, le app di fiducia ottengono i loro aggiornamenti approvati in poche ore.

    
risposta data 02.11.2011 - 12:16
fonte
0

Ho esperienza con Android. Android supporta il metodo "rilascio precoce e spesso". In genere, il tuo programma viene aggiornato entro pochi minuti dall'aggiunta di una versione più recente dell'apk.

Tuttavia, un problema che ho trovato è fragmantation . Che ci crediate o no, ci sono tonnellate e tonnellate di siti web che rasentano direttamente l'Android Market e quindi duplicano i suoi contenuti. Circa il 60% degli utenti della tua app può scaricarlo da fonti diverse da Android Market. Tutti questi altri mercati rasentano l'Android Market con intervalli di tempo diversi, oppure possono racchiuderlo solo una volta per ogni app, solo per aggiungerlo al proprio database e visualizzare i risultati di ricerca. Di conseguenza, in qualsiasi momento gli utenti possono scaricare una versione precedente selezionata casualmente della tua app in base al sito Web o al mercato dal quale ottengono.

A causa di questa duplicazione di contenuti in corso, non ho provato a configurare più account su più mercati e a rilasciarli simultaneamente. Le poche volte che ho provato, ho scoperto che non potevo aggiungere la mia app perché era già stata aggiunta ...

    
risposta data 02.11.2011 - 11:46
fonte