Il costo di un’ App per iPhone & iPad

This is the italian translation of the article Dear business people, an iOS app actually takes a lot of work!, written by Kent Nguyen. Thanks Kent for giving us permission to publish this translated article.

 

Il grande quesito: quanto costa un’app per iPhone?

Questa è una domanda estremamente comune che viene sempre chiesta da un sacco di persone che lavorano nel mondo degli affari oppure da clienti non molto esperti di tecnologia. Senza dubbio, ogni volta che ho fornito una stima iniziale prima ancora di formalizzare e analizzare in dettaglio le specifiche, ho potuto vedere sui loro volti l’espressione di shock a causa della inaspettatamente alta quotazione.

Inoltre nessuna delle mie quotazioni si è lontanamente avvicinata ai valori discussi in, nel quale vengono discussi i costi di sviluppo dell’app Twitterific. Nonostante il fatto che la domanda originale fosse stata posta nel 2008 e la migliore risposta (da uno degli sviluppatori di Twitterific) fosse arrivata nel 2010, è ancora molto precisa all’inizio del 2012 ed è facile prevedere che lo sarà almeno fino alla fine dell’anno.

Cosí, con il crescere del numero di imprese che desiderano avere un’app per iOS, penso che sia una buona idea spiegare perché i costi siano effettivamente alti cercando di dividere i vari passi e spiegare le variabili coinvolte. Spero che questo articolo sia di beneficio per i non sviluppatori e gli uomini d’affari che devono prendere delle decisioni o semplicemente vogliono comprendere il processo. Le idee in questo articolo ovviamente non sono ristrette al solo mondo iOS ma possono essere estese ad altre piattaforme (Android, Windows Mobile, forse Blackberry).

Checklist: prepararsi ad un’app per iPhone

Il procedimento non è affatto semplice e cerco innanzitutto di informare il cliente a fare tutte le considerazioni guidandolo attraverso questi passi:

PRIMO: Una delle maggiori scoperte che ottengo parlando con i clienti è quanto siano inconsapevoli delle grande infrastruttura necessaria per un’app per iPhone. Dato che essi assumono che un’app sia semplicemente un’app, si aspettano che gli venga fornito il prezzo di fare qualunque cosa con l’app senza tener conto di problematiche quali: avere un server di supporto col quale l’iPhone comunichi, dove immagazzinare i dati dell’utente. La prima volta che incontrai un tale cliente ero furioso ma in seguito ho realizzato il fatto che il concetto di client-server non deve essere dato per scontato tra i non programmatori. Avevo sbagliato, i manager di solito non hanno il senso-tecnico comune che noi programmatori ci attendiamo.

Perciò, cari lettori non tecnici: è necessario che disponiate di un server nel quale memorizzare i dati per qualunque tipo di app che come minimo debba fare qualche autenticazione (login) o qualunque tipo di personalizzazione che volete cambiare in seugito o comunque qualunque operazione che richieda il recepimento di informazioni dall’utente (sto cercando di usare il linguaggio il più semplice possibile).

SECONDO: Dato che avete bisogno di un server, bisogna fare in modo che l’iPhone possa comunicare con tale server, inviando e ricevendo dati. Non esiste una maniera standard, non esiste nessun componente plug-and-play per fare questo, ogni cosa va customizzata. Questo è analogo a creare il vostro linguaggio personalizzato: non volete che gli altri comprendano ciò che state dicendo ma le due estremità, telefono e server, devono capirsi.

Questo processo consiste nella creazione di API (Application Programming Interface) per la vostra app. Queste API devono esistere prima che si proceda con lo sviluppo dell’app. Perché? perché prima di cominciare a comunicare occorre definire il linguaggio! Questo ci porta al prossimo passo, come creare queste API.

TERZO: Non prendere questo passo alla leggera, le API hanno un’importanza pari al 50% dell’intera soluzione. Fare un’API è come mettere in piedi un sito web. Prima devi definire i dati, quindi la logica di business, quali sono i parametri di ingresso a tale logica, come interagiscono fra loro i vari moduli quando accade un evento. Per semplificare, il risultato finale è un sito web completo dove però le pagine non mostrano risultati grafici ma solamente del testo che verrà compreso dalla nostra app: ad esempio una pagina di autenticazione conterrà, in caso di successo, la semplice parola YES.

L’iPhone quindi farà una serie di richieste a questi punti terminali predefiniti (pagina di login) usando il formato di ingresso predefinito dall’API (nome utente + password) e quindi interpreterà il risultato fornito da queste pagine in risposta alla sua richiesta (YES/NO). L’app senza questo non potrà mai registrarsi e fare il login magicamente da sola.

Ci sono *un sacco* di variabili che devono essere prese in considerazione in questa fase, come preparare un server, selezionare il linguaggio di programmazione con cui scrivere le API, dove immagazzinare i dati per minimizzare i tempi di comunicazione, ecc.

QUARTO: Queste API o sono già pronte e ben documentate dal vostro team interno per essere fornite allo sviluppatore iPhone oppure preparatevi a pagare di più che solo per la pura app. In funzione delle conoscenze dello sviluppatore che avrete contattato per farvi l’app, egli/ella potrebbe avere o meno le capacità per fare ciò di cui avete bisogno. Se lo sviluppatore è in grado di fare questo lavoro, allora vi consiglio fortemente di affidargli anche questa parte del progetto dato che egli sa esattamente quali API servono per far funzionare l’app al meglio.

Nel caso abbiate già le API dovrete dare allo sviluppatore la possibilità di parlare apertamente e liberamente con il vostro team di back-end e non limitarvi a dargli la documentazione; questo perché il più delle volte egli richiederà che venga fatto del lavoro in più (più API) per supportare l’applicazione mobile in maniera appropriata.

Adesso, la parte iPhone

Caspita, tutto questo per essere appena pronti a sviluppare l’app e non siamo ancora partiti! In generale, qualunque cosa riguardo iOS è molto restrittiva. Dovete quasi sempre aver definito circa il 100% dello scopo e del design prima che lo sviluppatore possa partire con la programmazione; diversamente dallo sviluppo di siti web, lo sviluppo di un’app per iOS sotto contratto ha pochissimi margini di cambiamento:

Disegnare l’interfaccia: La scelta se si devono utilizzare i componenti grafici standard o personalizzati deve essere presa già dall’inizio, dato che l’architettura dell’intera app dipende da come si vuole l’interfaccia e da come la utilizzeranno gli utenti.Un esempio è la Tab Bar in basso: se si vogliono i bottoncini colorati invece di quelli monocromatici standard, la modifica al codice è sostanziale!

Il codice è fortemente integrato: Con i siti web voi potete aggiungere semplicemente una pagina in più, quindi create un link a quella pagina ove richiesto. Non potete fare questo con un’app per iOS, dato che ogni cosa va decisa all’inizio e ogni cambiamento può risultare in cambiamenti significativi in altre parti dell’app. Il modo in cui il codice iOS è strutturato è come quello di una breadboard (le basette sperimentali per circuiti elettrici), dove ogni cosa è collegata con fili: voi potete sempre cambiare delle cose qui e là ma se tocchi il filo sbagliato allora l’intero circuito smetterà di funzionare. Anche se viene usato del codice estremamente ben strutturato la flessibilità non aumenterà molto. L’aggiunta di un bottone email addizionale nella schermata “About” potrebbe richiedere un ridotto numero di linee di codice addizionali, ma l’aggiunto di un bottone “Facebook Like” sulla stessa pagina è una cosa completamente differente e non ci può attendere che venga fatto in poche ore.

Convertire un’app per iPhone in un’app iPhone/iPad universale: Questa è la peggiore ‘funzionalità aggiuntiva’ presente nei contratti di sviluppo di app per iPhone. Questo perché un’app per iPad non è una banale funzionalità aggiuntiva. Le app per iPad sono di solito molto più complesse delle app per iPhone e il più delle volte sono richiesti un’interfaccia e un meccanismo di interazione completamente differenti. Non solo quello, dato che anche le API potrebbero essere diverse: l’app Denso, che ho sviluppato (e quindi conosco), ha alcune funzionalità esclusive dell’app per iPad che richiedono dati addizionali dal server. Inoltre l’iPhone e l’iPad richiedono esperienze utente differenti.

Dunque siete pronti a partire?

Spero che dopo aver letto questo abbiate un’idea più chiara di quel che è necessario alla vostra ditta per sviluppare un’app per il mondo mobile. A meno che non facciate un’app completamente offline (come una Calcolatrice!) che non raccoglie dati dagli utenti, non potrete pretendere che questa vi venga sviluppata a un prezzo basso. Dopo aver considerato le variabili elencate sopra, se non potrete giustificare lo sviluppo a contratto allora l’altra opzione è assumere a tempo determinato dei progettisti a tempo pieno che lavorino a tempo pieno per l’intera durata del progetto.

D’altro canto, se decidete di andare avanti e affidare in outsourcing il lavoro, c’e’ un’altra cosa da aggiungere: le lungaggini burocratiche. Se lavorate in una grande azienda o in un ambiente molto regolamentato, il vostro lavoro sarà essenzialmente di aiutare lo sviluppatore ad evitare le lungaggini burocratiche che potrebbe incontrare lungo la strada e talvolta avrete necessità di aggirare un pochino le regole. Ho parlato con molti clienti e ho potuto notare il loro scetticismo quando ho cercato di saperne di più sulle loro API, dato che essi o non desideravano esporsi maggiormente per non violare le loro regole di segretezza, e non potevo biasimarli, oppure non possono portare certi dati al di fuori del perimetro aziendale, oppure semplicemente (e questa è la cosa peggiore) le regole di branding aziendale richiedono che ogni singola pagina dell’app presenti il logo dell’azienda (!!!). Alla fine ho preferito non lavorare con questi clienti dato che non potevo immaginare quando a lungo avrei penato per ottenere anche un minimo supporto sulle API di cui avrei avuto bisogno.

P.S. Avrete bisogno di tempo, un sacco, per cui siate pazienti.