RSSSignori,
come alcuni di voi sapranno, lavoro in un team che sviluppa applicazioni per iPhone. La nostra prima app uscita sul mercato è stata FindIT, un gioco a là “trova le differenze” molto semplice, con un sacco di immagini: belle, colorate, eccetera eccetera.
Terminato il doveroso cappello introduttivo, passiamo al caso in questione: leggendo i vari commenti sull’Apple Store abbiamo capito che a una buona fetta di utenza non è chiaro come si interagisca con il gioco, nonostante ci sia nel menu una bella voce chiamata tutorial che, con un’immagine molto esplicativa, insegna a giocare.
Preso atto della situazione, e tenuto conto anche delle richieste di una versione lite, abbiamo deciso di pubblicare una demo del gioco che contiene 6 livelli esclusivi ed un video tutorial in sostituzione della semplice immagine presente nella versione full. Fatto questo abbiamo anche deciso di fare l’upgrade e inserire il video tutorial nella versione completa del gioco.
Sapendo allora quello che sarebbe successo, non avremmo mai fatto alcun upgrade…
Dopo alcuni giorni dalla richiesta di pubblicazione della versione lite, Apple ci ha scritto una mail nella quale segnala che l’applicazione non può essere pubblicata, in quanto non segue le loro linee guida di design. Sulle prime un siamo rimasti un po’ basiti: in fondo la versione lite è identica, salvo ovviamente per i livelli, alla versione full.
Il problema segnalato era nella schermata degli utenti, in particolare nell’interazione con un componente. In ogni caso abbiamo sistemato l’applicazione, sia demo che versione completa: entrambe sono state pubblicate; nel frattempo abbiamo dovuto fare un ulteriore submit, a causa di un problema di versioni.
In fase di aggiornamento, poi, è sorto un ulteriore problema nella versione full a pagamento: dal secondo livello in poi il programma non riconosce le differenze fra le immagini nei luoghi giusti, rendendo di fatto ingiocabile il titolo. Ce ne siamo resi conto praticamente subito, era sabato 17/01, e abbiamo deciso per un fix lampo in giornata. Rimandiamo allora l’applicazione ad Apple.
Giovedì 22/01: Apple ci ha scritto dicendo che hanno dei problemi nel revisionare FindIT, scusandosi per il ritardo nell’approvazione del fix: aspettiamo fiduciosi.
Sabato 24/01: all’una di notte arriva un’altra comunicazione di Apple. Quando Apple contatta significa una cosa sola: c’è un problema con l’applicazione. Il problema sollevato da Apple è che nella nostra applicazione è stato usato un componente che non può essere utilizzato su iPhone ed iPod Touch, ovvero CoverFlow, che serve per visualizzare delle immagini e scorrerle rapidamente:
Nella mail viene allegato uno screenshot che indica dov’è il problema.
C’è però un dettaglio: FindIT non usa il CoverFlow: abbiamo creato una schermata nella quale si possono scorrere i livelli e ne viene visualizzata la preview in stile fotografia. Confrontando le due immagini è abbastanza netta la differenza: usando l’applicazione poi lo è ancora di più: il cover flow è rapidissimo, perché utilizza delle librerie a basso livello, mentre la nostra implementazione deve scendere a compromessi con l’utilizzo dei componenti standard forniti da Apple.
A questo punto sorgono in me delle domande abbastanza spontanee: come è possibile che il controllo qualità Apple, qualità che Apple ostenta e della quale va orgogliosa, possa fare una gaffe simile? Oltretutto l’applicazione, fin dalla sua prima incarnazione ha sempre avuto le stesse feature: perchè i problemi, presunti e non reali alla luce dei fatti, sono saltati fuori solo ora? E ancora: possibile che Apple tenga in così poca considerazione i suoi sviluppatori al punto di non avvisarli di un bug funzionale dell’applicazione e pubblicarla lo stesso, ma non si faccia scrupoli a rifiutare un’applicazione per motivazioni che non hanno fondamento?
Al di là delle domande che posso pormi, quello che resta sono i commenti negativi sull’app store, le vendite calanti e un fix pronto da ben due settimane che non riesce in alcun modo a essere pubblicato. Attualmente stiamo cercando di prendere contatti diretti con Apple, abbiamo mandato loro una mail con tanto di codice come prova della nostra innocenza e abbiamo reinviato l’applicazione nella speranza che un revisore più capace prenda visione del nostro programma.
Sperare. Usavo sperare quando ero piccolo: speravo di poter fare videogames e di entrare nel mondo dell’informatica come programmatore. Quando ho intrapreso la mia carriera professionale di certo non mi aspettavo di dover riporre speranze per riuscire nel mondo del business, quanto meno ho sempre creduto che la percentuale di capacità dovesse superare di una certa misura, neanche troppa però, il fattore fortuna. Non è così.
A questo punto spero che la situazione si risolva. Ai posteri l’ardua sentenza?
Gentile Signore, non credo ci sia nulla di stupefacente in tutto ciò. Avete scelto di sviluppare per un sistema chiuso ed usare un metodo di distribuzione ancora più proprietario.
Forse è il caso di cominciare a sondare altri mercati più snelli ed aperti come quello dei Sistemi Operativi Open Source e piattaforme come Google Android (che sarà disponibile a breve anche nel nostro paese).
Ho sempre diffidato dai sistemi troppo chiusi perchè, al di là delle specifiche meritorie, propongono spesso colli di bottiglia di tipo tecnico, logistico oppure, come nel vostro caso, quasi esclusivamente burocratico.
A questo proposito ricordo la storia di un ragazzo chiuso in camera da giorni per effettuare il porting del proprio videogame da piattaforma Nintendo DS ad altre quali Android, iPhone e similari. Il ragazzo di bobsgame(dot)com si è infatti scontrato con un cavillo burocratico sollevato dalla monolitica Nintendo che non vuole rilasciargli i kit necessari alla pubblicazione ed ha deciso di protestare con un cambio di rotta radicale.
La frustrazione sembra la medesima…
a parte la massima simpatia per cherno e la speranza che le cose si risolvano in fretta (ahmè esempi simili con l’app store ce ne sono parecchi) non mi sembra il caso di paragonarlo a bobsgame… la serietà del nostro sembra un filino superiore.
( http://arsludica.org/forum/index.php?topic=2744.0 )
vabbè, mentre Azid aspetta Android, mi scarico la versione lite di FindIT da AppStore e valuto se prendere la full (che sono ghiotto del genere)…
Azid il fatto che siano fatti noti non significa che non vadano riportati. Il mio è puro dovere di cronaca, se così non fosse quelle poche cose che sono migliorate nello sviluppo per iPhone non sarebbero accadute: ad esempio dopo tanti articoli di cronaca/critica scritti da sviluppatori iPhone, è crollato l’NDA e finalmente fra developers si è iniziato a potersi scambiare informazioni utili.
Sviluppare per un sistema chiuso ha un vantaggio enorme: scrivilo una volta, funziona ovunque. Questa cosa è importantissima, abbatte un sacco di costi e di investimenti.
Androids è una figata e stiamo guardando con attenzione quelle che potranno essere le possibilità. L’articolo non è scritto per rabbia, ma è scritto perchè spiace vedere rovinata una possibilità come quella dello sviluppo iPhone a causa di un revisore che non presta la dovuta attenzione al suo lavoro.
Fra l’altro, annuncio a tutti: presi contatti con Apple, ci hanno ringraziato per la segnalazione e si sono scusati. FindIT full version è su e funziona. Così Ale potrà giocarci sdraiato sul letto a pancia in su prima di andare a dormire 😀
ecco, adesso devi postare un articolo di scuse… :asd:
lawl
Per quanto le sue politiche siano particolarmente noiose, Apple offre un servizio davvero economico per qualsiasi sviluppatore.
Resta da capire perchè per consultare l’appstore si debba essere costretti ad installare il programma…
[quote]
Così Ale potrà giocarci sdraiato sul letto a pancia in su prima di andare a dormire
[/quote]
Stasera vediamo 😀 Vediamo se giochero’ a findit o leggero’ “The call of Chtulhu”, preso in una collezione di 7 libri, al costo di due sterline 😀
La roba sull’appstore costa davvero niente.
L’importante è che tu abbia risolto. Cmq tutti i sistemi chiusi sono così, se sviluppi con l’XDK per XBLA i tempi di feedback di Microsoft si misurano in mesi.
Non capisco perché Apple non ha scelto una soluzione tipo XNA, con la peer review fatta dagli sviluppatori stessi (servono diverse decine di feedback per avere luce verde, qualche settimana al massimo), è molto più veloce e scrupolosa di quella fatta da Microsoft e permette di evitare che vadano online prodotti scadenti o pirata (come i Game & Watch dell’iPhone) o che si compino grossolani errori di valutazione come nel tuo caso.
Tra parentesi per le submission indipendenti o commerciali per XBLA è pieno di casi anche molto più gravi del tuo (l’ultimo famoso è stato quello dell’ultimo gioco di Minter), quindi ritieniti fortunato!
Invece come butta contro la competizione di chi “investe” per comperare feedback positivi su Appstore e\o rimanere più a lungo nella Top 100? Ricevo mail da parecchie aziende che offrono questo tipo di servizio, complice anche il basso costo per acquistare su Appstore.
Be’ in toscana si dice: chi visse sperando, morì…ehm…si insomma, hai capito.
Vabè, meglio un “in bocca al lupo”..
^__^
Be secondo me fanno dei semplici test, uno sul codice per verificare che non faccia cose strane.
Per i test sul codice probabilmente utilizzano loro programmi proprietari, ed essendoci solo le loro SDK non dovrebbe essere un grosso problema fari questi test “al volo”.
Per il funzionamento di certo non vi fanno un betatesting “a gratis”, probabilmente una scimmietta pagata pochi centesimi dalla Apple fa girare l’applicazione e ne controlla e controlla in un foglietto che corrisponda a tutte le loro linee guida.
Vista la quantità di applicazioni deve esserci molto lavoro.
Caro Cherno, non posso che condividere la tua frustrazione.
Una situazione quasi simile ma con tempi ridotti è accaduta con M$, il problema per loro era, “nel database non avete usato le maiuscole al punto giusto”…
eh?!!!
E’ anche lecito pensare che non tutte le corsie di approvazione siano uguali e che forse, spesso alcuni problemi vengono creati per giustificare una precedenza sull’uscita o magari solo un giorno meno affollato che dia più visibilità ad un cliente premium.
Nei sistemi di delivery ludica dove c’è competizione reale per essere un cliente premium basta che tu paghi una quota, trasparente, espressa nelle condizioni di servizio e che tutti conoscono.
Nei sistemi chiusi, tutti pagano la stessa licenza solo per esserci, ma il trattamento non è mai democratico.
Uranio, alla apple non credo guardino il codice per il semplice motivo che non lo richiedono 😀
Quindi loro fanno un semplice controllo qualità sulle loro linee guida, il resto non importa. Comprensibile e giusto, però se vanno a cannare le loro stesse linee guida un pò mi dispiaccio. Situazione rientrata comunque, quindi ok 😀
Penso che intendesse verificare il codice nel senso di conformità dell’applicativo, come analizzare i binari per verificare se usi exploit o ti appoggi a feature non documentate o che possano cambiare nelle successive release dei firmware.
Non del codice sorgente nel senso letterale del termine.
E’ una pratica comune presso qualsiasi azienda che certifica la correttezza delle applicazioni per i loro sistemi embedded. Poi su i sistemi *NIX è veramente semplice da fare.
Pensavo veramente che chiedessero il codice o che almeno facessero un reverse del codice in qualche modo (non conosco Obj-C)
Cmq si, qualche controllo sugli binari come detto da matteo ci deve essere
Intanto di Android ho letto questo
http://www.obsessable.com/news/2009/01/26/android-application-deleting-data-from-t-mobile-g1-phones/
Esattamente questi sono i problemi ai quali accennavo prima, sulle architetture aperte aperte