One thing that I love about Obj-C and Cocoa is how seamlessly Apple is introducing funcionalities to take advantage of multicore devices.
One of the most common things that a dev does by hourly basis is enumerate a collection.
In Obj-C we can takle this with different approaches:
1 – old plain C for/while loops
2 – fast enumeration protocol (the
3 – Create an NSEnumerator object from the collection
4 – Use enumeration methods declared in the object interface

The 4th approach is present in almost each kind of collections and one of its methods is the

- (void)enumerateObjectsWithOptions:(NSEnumerationOptions)opts usingBlock:(void (^)(id obj, BOOL *stop))block

The opts parameter is a bit mask where we can pass this really interesting option:


As the name states this makes the enumeration process a concurrent task and it’s a pleasure to see in instruments the 2 cores working all togheter. There is one caveat as stated by Apple engineers “the code of the block must be safe against concurrent invocation”.

One other stuff that I really love is the way we can help thread safety using blocks.
Recently for a social-instagram-like app I needed to use extensively the AFNetworking library.
To take trace of the networking operation created by each view controller I created a sort of register of the living connection.
The problem in this scenario is the async nature of the process related to the networking tasks. After adding an operation to the register, is impossible to know when it will be  finished (and consequently removed from the register) and this could happen while adding another one the register. We need to put things in order.

To help us we can use a thread locking mechanism,  I’ve found really uselfull the dispatch_barrier mechanism that has less overhead compared to an exclusive lock.

First we need to create our concurrent queue.
In the reading method we create a synch block that waits for the reading to end, if more cores are avalaible more reading request can occur, in the writing method we use a barrier to be sure that no other code has access until the writing finishes. Since GCD queue are executed in first in – first out order we can guarantee that the block would be executed in the same order we have requested.
As you can see from the picture (taken from the book Effective Obj-C 2.0) while the writing block is executing no reading (or writing) can happen.

Read-Write process

Read-Write process

In code is pretty much something like that.

First we create a our concurrent queue

syncQueue = dispatch_queue_create("it.shootshare.registeroperation", DISPATCH_QUEUE_CONCURRENT);

Then we override our properties:

- (NSString*) name {
  NSString * __block aName = nil;
  dispatch_sync(syncQueue, ^{
     aName = _name;
  return aName;

- (void) setName:(NSString*)aName {
   dispatch_barrier_async(syncQueue, ^{
     _name = aName;

I don’t want to start explaining what is “the internet of things” because it’s a really huge topic, but I’m here to share my first experience into connect an iOS device to a micro controller called Pinoccio and what that means.

What is Pinoccio? am I missing an “H”?

Is really hard to describe it, I’m really proud about being a funder of this project on indiegogo.

Pinoccio at a first first look seems to be like a pumped Arduino with a WiFi shield and mesh radio communication. If you are wondering.. yes is compatible with the Arduino IDE and you can compile your own custom firmware, but do we really need that? Building a firmware with the Arduino IDE that include a network library, shield communication can be really frustrating, if you are not familiar with micro-controllers, is really a long hard road. For instance the memory is a big problem into creating a sort of web-server that can run into a micro-controller.
One of my first desire when I ‘ve got my first iPod Touch was to connect my device on everything and when I started to build my own applications using the iphone sdk, I always tried to figure out how to do that, but I’ve found huge obstacles that I wasn’t still prepared to tackle.
In the earlier realeses of iOS version wasn’t possible to connect the iphone to a sort of prototype board, well not exactly but I have should enroll to the made for iphone/ipod program and the process wasn’t really easy. The accessory framework had very few documentation available to the public. Now we can use the Bluetooth LE to connect with an accessory but it seems to be locked for 1:1 connection (but I’m not totally sure about it, for instance the multipeer connectivity can connect up to 8 devices).
Then I started to use Arduino a little, but the problem was still the connection between the 2 devices, the only option was using the ethernet shield, build something like a webserver and access Arduino pins with a sort of web services. Not so easy and also with a lot of limits about memory, bottlenecks etc in my mind I couldn’t find a way to do something that could be ready for production.

Later Redspark started to sell a cable (in compliance with the made for iphone program). With this cable is possible using the serial communication to make an Arduino talk with an ios device, but under current Apple policy this cable may not be used with apps sold on the App Store.

Then I’ve found ElectricImp, I was really interested into that project but when I heard that I would always need to stay bounded to their cloud platform I gave up, but the Imp is a really cool device if you accept that limitation (or feature).
On Febraury 2013 during an Indiegogo campaign I heard about it was love at first sight.

Pinoccio image

Pinoccio with all its features

Why Pinoccio changes everything?

  • It is a really small and cool prototyping board.
  • They are making an FCC certified version for production of a size of a nail.
  • You can build you own firmware in the old Arduino way.
  • You can use a scripting language to communicate with it from a web terminal (and via REST).
  • You can log it and launch those script commands using REST webservices.
  • You are not bound to use their platform.
  • You can create your own mesh of pinocc.ios and only one of them need to comminicate WiFi.
  • You can create your own custom script (maybe because you need to communicate in a specific way with a sensor or peripheral)
  • It’s all wireless Web interface Web interface

It’s pretty clear that you can do almost everything you want.

The idea here is to send all your request to their (or yours) platform and read or write properties with simple calls on the the platform, and this is a reallu smart idea, because most probably the platform manages the traffic on the board, maybe also caching some responses, avoiding bottle necks or massive requests.

To make a simple example about how this board connected to you iOS device can be powerful, I’ve made an easy app that asks the on-board temperature of the two scouts.
We have a lead scout (Optimus Prime) with the Wi-Fi backpack on it and the other scout (Bumble Bee) that communicates through the lead scout.
The lead scout is installed in my home and the other outside – of course the on board temperature is not the real environment temperature because is due to the load of the CPU and the environment temperature itself-.

Pinoccio temperature app

A video can be found here.

This is a simple example but let me try to figure out something bigger.

Let’s imagine that each scout has a Bluetooth LE backpack and a simple OLED display installed in a shoes shop. Each shoes has its own scout (like a price tag) with the display that shows the like/reviews numbers.
Each scout sends an iBeacon signal to identify a specific product close to them. When a user get close to the product using the shop application connects to that scout/ibeacon and get the product details, there is also the possibility to “like” it, once the use press like on the phone the like number on the display is incremented almost in real-time.
The other interesting example could be to measure the energy consumption of our house integrating a hall effect sensor on each scout and display data in a cool web page or into your mobile phone.

Arduino in my opinion created a revolution opening the market to all those boards, these is just the beginning because the revolution of the DIY is cultural and educational.
I hope to have more time to play around using and this is the first time that I feel I have something “ready for production” and not just a new cool R&D gadget.

Di recente ho dovuto “smanettare” per un bel po’ di tempo sulle UITableView  con contenuto statico.

Cosa sono le UITableView statiche?

Dal punto di visto dell’utilità sono eccezionali perché in pochissimo tempo, tramite l’editor degli storyboard consentono di creare una lista di celle fissa, statica, nel senso che non può cambiare a runtime (anche se non è completamente esatto perché certi comportamenti possono essere sovrascritti). Ciò comporta il non dover implementare i metodi di data source (UITableViewDataSource).

Lo svantaggio è che non sono celle riutilizzabili, quindi un uso massiccio impatta in maniera negativa sulle performance. Devono essere, pertanto, usate quando il numero di elementi in una UITableView è basso.

Si pensi, ad esempio, di dover comporre una lista di attributi che descrivono l’articolo di un negozio, come:

  • data inserimento articolo
  • pezzi a magazzino
  • costo articolo
  • etc…

Per un requisito del genere una table view statica è un ottimo candidato per creare un’interfaccia di questo tipo. Essa apporta maggiori vantaggi rispetto ad una classica view con label e campi di testo.

Perché ? :

  1. le UITableView sono un elemento estremamente “mantenibile”: se volessi aggiungere una voce mi basterebbe aggiungere un’altra row
  2. le UITableView ereditano dalle  UIScrollView posso anche non preoccuparmi delle diverse dimensioni di schermo
  3. non c’è bisogno di impazzire dietro ad autolayout
  4. non è necessario implementare i metodi di datasource
  5. se l’ interfaccia presenta dei campi da occultare in alcuni casi posso semplicemente dire alla tableview che a quell’index path per quel specifico caso l’altezza è 0 (solo per UITableViewController)

Mi occuperò, dunque, proprio dell’altezza delle UITableViewCell. Uno degli ostacoli forse più difficili da superare nell’utilizzo di queste è riuscire a creare delle celle di altezza variabile che si adattino al contenuto. Per capirci, è sufficiente pensare a quelle di what’s app o dell’applicazione messaggi.

L’altezza delle UITableViewCell viene infatti calcolata prima che queste vengano create e renderizzate a schermo perché le altezze sono necessarie per calcolare la contentSize della UIScrollView; una soluzione spesso adottata è quella di creare un modello di altezze, ovvero si precalcolano le altezze prima di visualizzare le celle per poi passare questo dato nel metodo – tableView:heightForRowAtIndexPath: . Un’operazione che poteva diventare ancora più complessa nel qual caso le celle fossero state di diverso tipo. Ciò comportava la creazione delle celle nella fase di precalcolo in maniera da realizzare tutti i calcoli necessari e fornire un’altezza corretta.

Si era di fronte al classico “collo di bottiglia”. Su table view, in presenza di un grande numero di righe, si poteva  giungere ad una situazione molto fastidiosa: un blocco momentaneo con un ritardo sul caricamento dell’interfaccia.

iOS7 ha introdotto un nuovo metodo – tableView:estimatedHeightForRowAtIndexPath: che rimanda al momento della visualizzazione il richiamo del metodo – tableView:heightForRowAtIndexPath:.

Sostanzialmente richiede una stima che consenta alla UITableView di potersi dare una contentSize di settare le altezze delle scrollbar etc.

Anche in questo caso ci troviamo di fronte ad uno strumento che dovrebbe essere usato solo in certe occasioni. Infatti, il calcolo dell’altezza rimandato durante il caricamento della cella può creare un lag durante lo scrolling percettibile.

La stima da fornire può essere un numero fisso, magari basato su una media ipotetica dei diversi valori che l’altezza può assumere, oppure può essere un calcolo approssimato molto più veloce di quello più preciso.

Un suggerimento che vale la pena menzionare è il caching dei valori già calcolati delle altezze. Se le celle non subiscono modifiche dopo la loro visualizzazione è inutile ricalcolarne l’altezza ogni volta, basta restituire quella in cache.


Visto che l’argomento iBeacon sembra particolarmente interessante ho deciso di fare un video di 13 min con due piccole demo.

Spero possiate trovarlo interessante e perdonate le papere, ma andavo a braccio!!!!

Un altro articolo interessante sullo stesso argomento: iBeacon, behind the scene


IOS7 è uscito, lo sappiamo e molti di noi lo hanno già installato. Il nuovo sistema operativo rappresenta un cambiamento radicale rispetto al 6, un cambiamento necessario per svecchiare un prodotto che rischiava di essere visto come “datato”, specie se confrontato con quelli proposti da concorrenti che, con il trascorrere degli anni, hanno saputo produrre sistemi operativi molto accattivanti.

Non parlerò delle funzioni di iOS7, delle quali è stato detto già abbastanza. Voglio guardare “il dietro le quinte” e ripercorrere le trasformazioni che iOS7 ha subito negli ultimi mesi, dalla developer preview 1 fino al rilascio ufficiale odierno. Un’altra maniera per capire il modus operandi di Apple, fra tentativi, certezze e modifiche dell’ultima ora.

Per noi sviluppatori iOS7 rappresenta “un problema” anzi, due problemi. Il primo è il missmatch creativo che si è creato tra sistema operativo e applicazioni “vecchie” che per lo più utilizzavano lo scheumorfismo.

Il secondo sono le API e il nuovo modo di “vedere” le applicazioni.

La questione ha due risvolti, entrambi da considerare.

Senza dubbio per innovare, è necessario guardare avanti e, nel caso, prendere decisioni unilaterali, di forza, in maniera che tutti vi si adeguino senza negoziare. Lasciando troppa libertà si corre il rischio che ognuno continui sulla sua vecchia strada, implementando API vecchie. Una nota personale: è da tempo che mi riprometto di imparare bene il linguaggio “Ruby”, ma ad ogni rilascio di sistema operativo mi vedo costretto a ricominciare a studiare tutto daccapo.

Apple è decisamente coerente con quello che dice e fa; alcuni elementi dell’interfaccia grafica standard sono stati macellati da diversi sviluppatori (me compreso) per accontentare le richieste di clienti a cui non piaceva il pop up bluetto perché non in linea con i colori aziendali. Da Cupertino, infatti, non si smetteva di sconsigliare modifiche a tali componenti, avvertendo che release future avrebbero potuto generare cambiamenti, con il rischio di dare vita a comportamenti inaspettati con l’applicazione di questi hack… Insomma tutti ne erano consapevoli tanto ieri come oggi.


Tuttavia, se la filosofia che sta dietro a determinate scelte è comprensibile, le vie che propone per renderla operativa sono talvolta meno limpide.

Parliamo del minimalismo dell’interfaccia grafica di iOS7. È chiaro che questa scelta non è fine a sé stessa come su altri sistemi (una pura questione estetica, di gusto), ma propedeutica al contenuto e al contesto presentato, animazioni incluse.

Meno chiaro, invece, la maniera attraverso la quale trasformare il concetto in qualcosa di reale, attraverso la programmazione. Infatti, benché iOS7 preveda che tutte le app compilate debbano utilizzare come area lo schermo intero, ad oggi sembra non esistere un modo semplice per cambiare questa azione e renderla simile ad iOS6. Una scelta che ha fatto letteralmente impazzire un certo numero di sviluppatori. Capita che le “vecchie” applicazioni ricompilate vengano visualizzate con un layout diverso e con i contenuti che “scivolano” sotto la status bar. Un problema non da poco per chi come me sta lavorando per implementare animazioni di transizione diverse da quelle standard tra una sezione e un’altra senza usare gli strumenti forniti da Apple.

Non c’è dunque da stupirsi se il forum ufficiale della Mela morsicata è animato da discussioni visitate da migliaia di persone. In pratica, con questa scelta, si obbliga lo sviluppatore da una parte a “ridisegnare” gran parte del layout e dall’altra a tenere sempre presente la bicompatibilità con il vecchio sistema.

Gli stessi ingegneri Apple si sono dimostrati non esattamente all’altezza: le loro risposte ancora latitano e quando arrivano, non sono del tutto esaustive, soffermandosi su un solo modo di programmare , talvolta utilizzato da una percentuale minima dei programmatori. Intanto anch’io mi sono cimentato, proponendo una soluzione che riduca l’impatto sulle ore di lavoro e mantenga la retrocompatibilità con il 6. La speranza è che funzioni.


Il confronto con i programmatori ha portato Apple ha fare alcuni importanti correttivi. Dai primi giorni di settembre è possibile scaricare anche le versioni vecchie per quelle app che hanno interrotto la compatibilità con i precedenti sistemi operativi.

Nel nostro caso stiamo sviluppando un update per un nostro prodotto, iEtiquette che sarà compatibile solo con iOS7. Mentre per chi non avesse o potesse aggiornare sarà comunque possibile scaricare la versione precedente. Questa è una scelta di importanza enorme perché favorisce sia sviluppatori che utenti.

Il cambiamento, come dicevo all’inizio di questo post è radicale. Sicuramente qualcuno si lamenterà. Negli ultimi giorni ho letto di diverse polemiche riguardo ad aggiornamenti  di applicazioni a pagamento che – con il pretesto del passaggio al sistema 7 – dovranno essere pagate di nuovo dagli utenti che le avevano a suo tempo scaricate. Un caso eclatante – notizia di oggi – riguarda il task manager CLEAR che nella nuova versione iOS7 compatibile richiede ben 3 euro.

L’effort per rendere una app compatibile con iOS7 è molto elevato e per applicazioni complicate (CLEAR non è tra queste) è abbastanza normale che gli sviluppatori richiedano un pagamento. Il problema è che non è possibile fissare un prezzo di update, o gratis o tutto. D’altra parte ritengo che sia normale che un’applicazione supporti gratuitamente un solo sistema operativo. È una situazione che nel mondo desktop viviamo tutti i giorni (è probabile che qualcuno se ne approfitti, avvelenando il mercato).


Altre sorprese passate in sordina sono la possibilità di scaricare app in 3G fino a 100MB (prima il limite era di 50MB) e che un’applicazione per iPhone su iPad userà le risorse per retina display e verrà visualizzata a quasi tutto schermo, con un miglioramento sull’usabilità davvero notevole.


Le cifre necessarie per sviluppare un’applicazione mobile dipendono da molteplici fattori.
Una forchetta che va dai 2.000 ai 15.000 euro è indicativa di quanto possa costare uno dei prodotti più innovativi di questi ultimi anni.

 In media decisamente meno di quanto si spende per far stampare un catalogo promozionale. Con il vantaggio di una distribuzione più ampia e capillare. In Italia le piccole agenzie che gestiscono tutte le fasi della commessa possono permettersi costi più contenuti.


Ok, ma quanto mi costa?” Questa è senza dubbio la prima domanda – o la seconda, nel caso non voglia apparire troppo venale – che il potenziale cliente pone dopo che gli sono state mostrate tutte le mirabolanti potenzialità di questi nuovi software.

Se volessimo stilare una classifica delle principali risposte, in cima troveremmo un evergreen come “Beh, dipende…”, seguito a ruota da “Le facciamo avere un preventivo dettagliato al più presto”. Una terza, potrebbe essere: “Guardi, meno o tanto quanto le è costato stampare e distribuire l’ultimo catalogo promozionale dei suoi prodotti, con la differenza che con una App avrebbe mille funzioni in più e una distribuzione capillare e potenzialmente gigantesca (se si pensano agli store online di Apple e Google).

Confronti a parte, questa ritrosia nel “dare dei numeri” non deve tuttavia essere confusa con il desiderio – un po’ furbesco – di prendere tempo, in attesa di fare due calcoli con calma nel segreto del proprio ufficio. Si tratta piuttosto di una reale difficoltà nel dare una stima di costo a un prodotto innovativo, tutto sommato non ancora così codificato nelle sue operazioni di realizzazione e non facilmente standardizzabile.

La lavorazione nel suo insieme risulta una faccenda spesso complessa, in molti casi lunga, somma di tanti passaggi e dell’intervento di diverse figure professionali. Tutti elementi che impediscono una precisa pianificazione delle operazioni. Insomma, pur essendo arrivati a oltre 1 milione di APP disponibili sul solo store di Apple, non è stato ancora trovato un sistema standard e replicabile, magari sul modello della catena di montaggio fordista…

La app come un complesso insieme di parti

Quindi prima di arrivare a un prezziario di massima che risponda alla questione del nostro cliente, propongo di passare attraverso una breve analisi delle componenti/operazioni che costituiscono una App. È possibile individuare almeno 8 passaggi:

1. ideazione e individuazione requisiti

2. analisi di fattibilità

3. creatività

4. mock-up

5. sviluppo software

6. test

7. pubblicazione

8. marketing

Non citiamo, sebbene sia una componente rilevante in termini di tempo, il lavoro di account con il cliente, necessario per raccogliere tutti i feedback e le eventuali modifiche durante le fasi di lavorazione.

1. ideazione e individuazione requisiti. In questa fase l’obiettivo è trovare un’idea valida che si adatti alle esigenze del cliente. O – se è un progetto personale – pensare a qualcosa che ancora non c’è sul mercato. O magari immaginare un accorgimento che possa migliorare ciò che già c’è. Ma non solo. È importante che si trovi un’idea a cui il cliente o nessun altro aveva pensato. Dunque non solo “soddisfare un’esigenza” ma “creare un bisogno per poi soddisfarlo”. Come le 5 “W” del giornalismo, anche l’ideazione di una applicazione ha le sue domande di orientamento:

• chi è lo user dell’app?

• cosa farà l’app?

• cosa non farà?

• quale scopo vuole avere (comunicazione, utilità, gestione etc.)

È una fase importantissima perché consente di definire le specifiche dei diversi componenti dell’applicazione che poi andranno prototipati nella fase successiva.

2. Analisi. È la fase di ripensamento, “decantazione” e razionalizzazione successiva alla fase di turbolenta di brainstorming e ideazione. È il momento in cui la “fantascienza” smette di essere tale in attesa di essere tradotta in realtà. Si passano in rassegna tutti i requisiti funzionali, i diversi Use Case e l’architettura dell’app, sia dal punto di vista del design che da quello software.

3. Creatività.  È ciò che vediamo. E si sa che le app puntano tutto sull’interfaccia. Tuttavia lo fanno in un modo “non convenzionale”. Ovvero non limitandosi a una gradevolezza estetica, ma aggiungendo a questa (è doveroso) anche una facilità di utilizzo. In gergo potremmo dire “usabilità”. Puoi aver creato un prodotto sfavillante o uno in grado di risolvere mille problemi ma se poi l’utente fatica a utilizzarlo (perché macchinoso, poco intuitivo) allora è sicuro che finirà presto nel dimenticatoio. Per il suddetto motivo è fondamentale creare un wireframe, un mock-up dell’applicazione. Includendo anche le eventuali animazioni di passaggio che saranno di supporto al software.

4. Test dei Mock-up. In questa fase è già possibile esplorare il prototipo su carta e rendersi conto di alcuni problemi legati all’usabilità, come ad esempio la navigazione. È un passaggio imprescindibile durante lo studio di un’ applicazione mobile.

5. Sviluppo Grafica. Quando i passagi precedenti sono chiari e si è deciso quale strada far prendere al progetto, è possibile procedere con il disegno specifico della user interface dell’app.

6. Sviluppo Software.  L’ app prende forma da un semplice layout su carta inizia ad animarsi fino ad assumere diverse forme prima di passare a quella definitiva. È il momento più tecnico: misure, formule, numeri e codici.

7. Fase di testing dell’applicazione. È fondamentale far testare l’applicazione a un ristretto numero di utenti per capirne il funzionamento e l’usabilità in vista della definitiva pubblicazione.

8. Pubblicazione.  È il punto di arrivo. Dopo tanto lavoro di back-office finalmente ci si confronta con il mondo, ci si espone al giudizio degli altri.

9. Marketing. Il mercato delle applicazioni è cresciuto in maniera esponenziale in questi ultimi anni grazie alla diffusione dei device e all’arrivo di concorrenti che hanno stimolato la fantasia di Apple e dei developer. Oggi è vastissimo e senza opportune strategie di marketing l’app finisce con naufragare nell’oceano di tutte le proposte che giornalmente vengono pubblicate.


Il cuore della app, la programmazione

Lasciamo da parte le proposte creative, l’ideazione e la fase analitica (difficilmente quantificabili) e concentriammo sulla parte di sviluppo software. Il prezzo finale della App è determinato da quello che vogliamo l’applicazione faccia. I casi sono essenzialmente due:

1. l’applicazione NON DOVRÀ connettersi ad un servizio specifico esterno

2. l’applicazione DOVRÀ connettersi ad un servizio specifico esterno.

In questo secondo caso la procedura si complica. Si dovrà, infatti, creare una piattaforma o un sistema per permettere uno scambio di informazioni tra la app installata sul proprio iPhone e il sito del cliente (per esempio, nel caso della prenotazione di una stanza in un hotel. Attraverso la app interrogo il sistema di gestione delle prenotazioni dell’hotel sulla possibilità di avere una stanza per il giorno X; il sistema di prenotazione mi risponde che c’è; a quel punto procedo alla prenotazione). Quindi, scegliere 1) piuttosto che 2) porta a una sostanziale variazione di costo.

Sulla base di quanto detto, possiamo azzardare una sommaria divisione delle applicazioni in 4 tipi:

1. applicazione semplice basata su navigazione di tipo top-down. Un esempio può essere un’applicazione come quella della Musica presente in ogni iOS device (rimuovendo però la parte di playback dell’audio).

2. applicazioni che si appoggiano ad un database interno. Tutte le informazioni sono residenti all’interno della app che, dunque, può fare a meno di comunicare con l’esterno. Ad esempio la Rubrica di Apple.

3. applicazioni dinamiche che si appoggiano a servizi online. Questo è uno dei casi più costosi perché spesso è necessario creare dei servizi appositi per l’applicazione in modo che questa possa comunicare con la piattaforma contenente i contenuti. Spesso i costi sono suddivisi in sviluppo applicazione e sviluppo servizi.

4. giochi. Che essi siano 2d o 3d rappresentano sempre un investimento non indifferente.

Diamo i numeri!

Alla base delle seguenti caratteristiche è possibile avere una stima plausibile del costo di una app.

Qualche tempo fa, il CEO di AppVee – la compagnia americana di reviews di applicazioni mobile – quantificava in 6.500 dollari all inclusive il costo medio di un’applicazione mobile. Secondo un articolo apparso nel 2010 su, sito di novità riguardanti il mondo Apple, i prezzi oscillavano fra i 3.000 e i 15.000 dollari. Stime che non sono variate rispetto all’oggi.

Nello specifico per un’ app “semplice” il costo si aggirerebbe tra i 3.000 e gli 8.000 dollari, mentre per applicazioni di brand specifici il costo sarebbe tra i 5.000 e i 15.000 dollari. Con qualche eccezione. Ad esempio l’applicazione di Barack Obama, pur non essendo particolarmente complessa è costata all’incirca 100.000 dollari (ma qui sono entrate logiche commerciali difficilmente applicabili alla realtà di tutti i giorni…).

Ricapitoliamo e parliamo di euro.

• Le applicazioni appartenenti al tipo n. 1, hanno un costo compreso tra i 1.000 e i 3.000 euro, ma obiettivamente sono casi più unici che rari. Tralasciando il fatto che questo genere di prodotti sarebbe “troppo semplice” per gli attuali standard del mercato, con app dalle funzionalità ben più complesse.

• Le applicazioni che si appoggiano ad un database interno possono costare tra i 2.000 e i 10.000 euro.

• Quelle che prelavano i dati dalla rete possono arrivare a sfiorare i 30.000 euro.

• I giochi sono un universo a parte. Volendo fare una stima possiamo dire che si parte da un minimo di 15.000 euro fino a grosse produzioni con budget di 200.000. La famosa Angry Birds si pensa sia costata tra i 100.000 e i 180.000.

Incide sul prezzo anche il soggetto che sviluppa il prodotto applicazione. Senza dubbio le piccole agenzie che gestiscono tutte le fasi della commessa possono permettersi costi mediamente più contenut

E gli sviluppatori? Notizie recenti dicono che gli sviluppatori cinesi applichino tariffe orarie di 30-40 dollari. Decisamente più alte quelle applicate negli Stati Uniti, circa 150 dollari l’ora. A buon mercato rimane solo l’India con una media di 18 dollari l’ora. Molte agenzie ricorrono all’esternalizzazione, delegando lo sviluppo del software a sviluppatori in Cina, Russia o India. Un vantaggio in termini economici, ma un rischio sulla qualità finale del prodotto, spesso scadente e bisognoso di un importante lavoro di limatura.


In chiusura vi invito a divertirvi con un tool sviluppato da fate il preventivo della App dei vostri sogni e scoprite quanto può costarvi (negli USA)…


Immagine ©Shutterstock