Fresh & Local è la prima applicazione mobile per iPhone dedicata al consumo di cibo fresco, locale e di stagione.

  • Calcola quanta strada hanno percorso i cibi che hai acquistato o stai per acquistare.
  • Esplora la fattoria e informati sui benefici di acquistare Fresh & Local.
  • Crea un evento, calcola i chilometri percorsi dagli ingredienti usati e sfida gli amici postando sui social network i tuoi risultati.
  • Colleziona i badge e scala le classifiche.
  • Consulta la tabella di stagionalità per avere la certezza che l’alimento che stai per comprare è davvero in stagione.
  • Scopri tutte le attività che intorno a te producono, vendono o servono prodotti freschi e di provenienza locale.

Scopritela in anteprima!

(a breve disponibile su AppStore).

Apple è ancora in grado di stupire o ha perso la sua capacità di inventare il futuro?

Apple back to the futureÈ la classica domanda che porta a discussioni tanto oziose quanto piacevoli. Quelle che ci fanno rimanere alzati fino a tardi in compagnia di un paio di amici, magari seduti all’aperto con una birra in mano o in un caffè. Ognuno avrà la propria idea, ognuno sosterrà la propria tesi, evidenziando a turno i momenti nei quali Apple ha fallito e nei quali ha avuto successo, dove si è limitata a svolgere  un buon lavoro e dove invece ha fatto emergere il genio creativo.

Ognuno troverà spiegazioni all’alternanza di successi, invenzioni rivoluzionarie e passaggi a vuoto. La presenza o l’assenza di Steve Jobs, la maturità o l’immaturità del mercato, l’impossibilità di stupire ogni volta etc. Addirittura qualcuno potrebbe arrivare a scorgere una ripetizione, una ciclicità, nella capacità di Apple di tirar fuori dal cilindro – ogni tot anni – un prodotto in grado di scompaginare ciò che già esiste, disegnando nuovi scenari. Ecco allora che si possono citare le pietre miliari: il Mac nel 1984, l’Ipod nel 2001, la presentazione dell’iphone nel 2007 e il lancio dell’AppStore l’anno successivo, nel 2008.

In attesa delle (imminenti) novità di iOS7 è, dunque, bello soffermarsi a osservare le cose in prospettiva, divertirsi a fare bilanci. Un po’ come fa Rene Ritchie in un articolo per iMore.com

(In un’altra serata, magari, si parlerà della filmografia di Brian De Palma, di quanto i primi romanzi di King fossero diversi e migliori degli ultimi, della triste parabola dell’hard rock o chi è più divertente  tra I Simpson e I Griffin).

iPad, applicazioni mobile e bambini in età prescolare: il legame è molto stretto. È sufficiente pensare che il 10% delle applicazioni per tablet pubblicate annualmente nel mondo sono dedicate ai bambini sotto i 6 anni.

IPAD_educational_cloud_in_touchQuesti ultimi nativi digitali – specialmente i più piccoli – sono coloro che forse meglio interpretano l’intuitività propria di questi dispositivi. Il tocco, il pinch, il far scorrere le dita e lo spostare oggetti sono movimenti naturali. Lo dico pensando a mia figlia, una bimba di quasi due anni, appassionata fruitrice di questi edugame per iPad (alcuni dei quali, ammetto, di grande pregio). Il legame fra loro e i tablet ha qualcosa di magicamente immediato. Un giorno, per esempio, l’ho osservata mentre tentava di “sfogliare” un portafoto tradizionale con le dita, cercando invano altre immagini. Ugualmente l’ho vista trattare lo schermo del nostro televisore come se fosse un touchscreen, ignorando quella cosa arcaica che si chiama telecomando.

Come per tutte le cose, anche le migliori, può esistere un risvolto negativo o almeno un punto su cui porre attenzione. Una valida interpretazione ci viene leggendo un articolo apparso su TabTime.com a firma di Glenn O’Farrell, CEO del Groupe Média TFO, società canadese specializzata nella produzione di contenuti per i più piccoli.

Secondo O’Farrell i bambini di oggi, abituati a questa avanguardia tecnologica e circondati da device evoluti, potrebbero andare incontro alla delusione e al disinteresse una volta di fronte a situazioni dove il livello tecnologico è – per le più svariate ragioni – minore.  Specialmente a scuola dove i tablet non sono ancora entrati nell’uso (almeno in modo massiccio e soprattutto alle nostre latitudini) e dove i metodi di insegnamento spesso non tengono presente questa rivoluzione.

Ciò non significa che il resto non interessi più ai bambini. La previsione dei videogiochi corruttori del mondo e fagocitatori di ogni altra forma di svago è stata smentita in questi anni. Dunque i libri di carta e i giochi tradizionali continuano e continueranno ad attirare l’attenzione (e ad occupare le scaffalature delle nostre case).

Semmai significa fare uno sforzo in più e accettare la sfida e cercare di integrare questo nuovo linguaggio quando cerchiamo di comunicare con loro.

Una cosa che dovrebbe interessare anche le aziende…

I clienti di iPhone sono più fedeli al loro dispositivo rispetto a coloro che possiedono un telefono con sistema operativo Android.

i love apple-200x200_cloud_in_touchQuesto quanto emerge dallo studio del Consumer Intelligence Research Partners. Considerando il periodo giugno 2012-giugno 2013, si nota come l’81% di coloro che utilizzavano un iPhone hanno continuato a farlo anche quando è stato il momento di acquistare un nuovo dispositivo. La percentuale di fedeltà degli utenti Android scende, invece, al 67%. Tuttavia è interessante notare come siano decisamente più numerosi coloro che abbandonano Android per iPhone piuttosto che il contrario (27% contro 14%). Se poi si guarda all’ex re del mercato BlackBerry si scopre che il 48% dei suoi vecchi clienti ha acquistato un iPhone e il 34% un telefono Android.

Sono dati interessanti, che tuttavia non sorprendono, soprattutto se si considera l’impegno che Apple ha sempre profuso per ottenere la reale e duratura “fedeltà” dei propri clienti. Una Customer Loyalty che – nonostante il passare del tempo – continua a restare alta e che va oltre la semplice “fidelizzazione”. Senza dubbio il legame tra Mela Morsicata e consumatori poggia su elementi tangibili e solidi come: a) la qualità dei prodotti venduti e b) la puntualità  nel venire incontro alle esigenze della clientela. Ma non solo. Esiste anche una sfera di “percepito non tangibile” sviluppatasi nel corso degli anni. L’abilità degli strateghi di Cupertino è stata – ed è tuttora – quella di immaginare oltre il semplice e singolo consumatore per dare origine, invece, a una comunità di persone legate da un senso di appartenenza molto forte. Insomma, la certezza di  far parte di una minoranza “non conforme al resto del mondo” che sceglie e usa prodotti “belli e giusti”. Chi usa Apple lo vuole far sapere, lo rivendica. Con la conseguente soddisfazione psicologica che deriva dall’essere convinti  di possedere qualcosa di esclusivo, non massificato (e non importa se intorno a noi milioni persone hanno un iPad o un iPhone…).

Ma osserviamo questi dati pensando al mondo delle applicazioni mobile. Questa maggiore fedeltà dei consumatori Apple comporta anche una maggiore frequentazione degli stessi dell’AppStore (rispetto a quanto i possessori di Android fanno con il Google Play)?

Io ritengo di sì. La più decisa customer loyalty degli Apple user è evidente anche osservando la maggiore frequentazione e la più profonda familiarità di utilizzo delle applicazioni mobile presenti sull’AppStore. Ciò è confortato anche da recenti dati che mostrano come il negozio Apple 1) sia 4 volte più redditizio rispetto a quello di Google Play e 2) sia di gran lunga preferito da chi investe in advertising nel settore mobile.

Un altro paio di riflessioni prima di chiudere.

Apple, iPhone ed il sistema operativo iOS sono legati in maniera indissolubile. Se sei fedele a uno lo sei anche agli altri. Diverso per il frammentassimo universo Android, fatto di aziende, marchi e dispositivi differenti. È possibile che – almeno in parte – questa parcellizzazione influisca negativamente sulla customer loyalty. Così com’è possibile che il consumatore Android si limiti a passare da un brand all’altro (da Samsung a Motorola, per esempio), acquistando dispositivi con il medesimo sistema operativo.

Infine, non bisogna dimenticarsi il fattore prezzo. È più facile che un consumatore che abbia sborsato una cifra consistente per un Samsung Galaxy S4 passi a un iPhone. Mentre è più difficile che lo faccia un consumatore che ha comprato uno dei tanti telefoni con sistema Android di fascia medio-bassa.

Tutto ciò, rimanendo in attesa del probabile iPhone low-cost, futuro 5C.

Cambiamento importante in casa Microsoft. Steve Ballmer per decenni numero due di Bill Gates e da 13 anni numero uno della compagnia americana ha annunciato che lascerà il suo incarico per ritirarsi dalla vita attiva. Un cambiamento di rilievo ma controllato, un lungo addio che diventerà effettivo solamente fra 12 mesi, tempo necessario per scegliere un nuovo CEO.

Quale giudizio dare dell’era Ballmer? L’immagine “luci ed ombre” pur non originalissima – lo ammetto – spiega bene ciò che è successo in Microsoft durante il suo “regno” dal 2000 a oggi. Anche se forse le “ombre” sono più grandi. Facciamo dunque un rapido bilancio.

Steve-Ballmer_Cloud_in_touchSe si considerano i prodotti usciti dalla Microsoft possiamo mettere fra le “luci” alcuni long e best seller di buona fattura come Windows XP, Windows 8, il pacchetto Microsoft Office e la console Xbox360. Questi hanno avuto e continuano ad avere una larga diffusione nel mondo, garantendo entrate continue.  Operazione interessante è stata anche l’acquisizione di Skype, nel 2011.

Tra le “ombre”, invece, si possono citare il troppo atteso e poco funzionale sistema operativo Vista – che nelle intenzioni doveva aprire un nuovo corso e che in realtà ha fatto ben poca strada – e la perdita di quote di mercato da parte di Internet Explorer a vantaggio di altri browser come Mozilla’s Firefox e Google Chrome.

Tuttavia ciò che più pesa sul periodo di governo di Ballmer è il ritardo sul mobile. Sebbene sia diverso da quanto accaduto in casa BlackBerry – dove si è tanto sottostimato come ignorato il cambiamento a livello globale – ciò che è successo a Redmond è ugualmente grave. Rispetto all’azienda canadese di telefonia, tuttavia, Microsoft aveva la forza e le risorse per cercare di rispondere a Apple. Forse già dal nuovo modo di fruire la musica, quando la Mela Morsicata aveva lanciato l’iPod e la compagnia di Bill Gates aveva sviluppato il suo media device portatile, Zune (poi tristemente abbandonato).

Microsoft si è inserita nel difficile settore dei tablet con il suo Surface. Lasciando da parte l’iPad (normal e mini), attualmente irraggiungibile per qualità e usabilità, quello di Microsoft è forse il miglior tablet in circolazione. Un prodotto con qualità e pregi che tuttavia non riesce a raccogliere ciò che merita. Lo stesso si può dire per i Windows Phone, prodotti validi ma che faticano tantissimo a inserirsi in maniera seria nella competizione esistente sia fra sistemi operativi (iOS e Android) sia fra aziende costruttrici di telefoni (Apple, Samsung e forse Motorola). Neanche dopo la partnership con la finlandese Nokia. Eppure i Lumia 920 e 820 sono decisamente più accattivanti di alcuni costosi modelli della casa coreana.

Dunque, quale è stata la mancanza più grave? Molto probabilmente l’assenza di una strategia chiara, almeno a partire dal 2008. L’incapacità di saper interpretare i segni del presente per prevenire le difficoltà del futuro. Primo fra tutti quel progressivo calo nelle vendite di PC che – specie negli ultimi due anni – è stato sempre più consistente. Gli ultimi dati mostrano come i tablet si stiano avvicinando ai primi per numero di esemplari venduti.

Come scrive Sarah Perez su TechCrunch.com:

To be successful in the new mobile-first era, a company needs to have a cohesive strategy across all the devices that users carry. Yet Microsoft is not known for the interoperability of its internal units — a problem the recent re-org aimed to address.

L’era post-PC è iniziata da ormai qualche anno. Microsoft – se vuol continuare a essere azienda leader – deve re-organizzarsi e ricominciare, magari con la stessa convinzione che l’ha portata a trasformare dei computer in personal computer. Ancora senza Bill Gates e con un nuovo CEO.

 

Per un maggior approfondimento si vedano:

Sarah Perez As The PC Era Ends, Microsoft’s Next CEO Faces An Uphill Battle On Mobile  su TechCrunch.com

Lance Ulanoff The Steve Ballmer Legacy: A Very Bumpy Ride su Mashable.com

Con l’avvicinarsi della data del 10 settembre – indicata da molti come quella del prossimo keynote speech – aumentano i rumors sulle possibili novità dei telefoni Apple e, in particolare, intorno al cosiddetto iPhone 5C.

Sono mesi che si ventila l’ipotesi di uno smartphone low-cost in grado di rilanciare le vendite (specialmente fra i più giovani) e di occupare un segmento di mercato ora dominato dai dispositivi made in Asia (Samsung in testa).

iphone5c_cloud_in_touchIl minor prezzo rispetto a quello della versione attualmente in commercio dovrebbe derivare dall’uso di materiali meno nobili. L’alluminio e il vetro della scocca propri dell’iPhone 5 sarebbero sostituiti dalla plastica. I sobri ed eleganti black or white tra cui il consumatore oggi può decidere, verrebbero rimpiazzati da una più ampia scelta cromatica.

Le voci parlano di una plastica decisamente più resistente a quelle che di norma viene usata per gli altri smartphone e sulla quale sono stati condotti numerosi e positivi test per saggiarne la resistenza ai graffi.

Insomma, dopo anni di estrema severità ed essenzialità nell’uso di materiali e colori, ecco il ritorno a un prodotto meno impegnativo e più giocoso. Benché la plastica si era già vista nel iPhone 3G e 3GS, la scelta dei colori sgargianti fa ritornare in mente gli iMac, primi computer desktop a non essere solo grigi….

Insomma, ipotizzando che l’iPhone low-cost sia qualcosa di reale e non la solita ben architettata leggenda metropolitana fiorita intorno al mondo di Cupertino, la sfida è di quelle toste.

Gli strateghi della Mela morsicata dovranno essere abili nel tenere insieme, in maniera armonica, vari elementi quali:

- il mantenimento di uno standard qualitativo alto anche nella versione low-cost (da Apple ci si aspetta sempre il meglio)

- il rispetto del “posizionamento alto” dell’altro iPhone, quello high-cost (chi l’ha acquistato, sborsando cifre importanti o sottoscrivendo abbonamenti in media più onerosi, vuole che il suo sacrificio economico sia ricompensato da un prodotto riconoscibile come “esclusivo”)

- il rispetto del consumatore low-cost, che pur sapendo di aver pagato un prezzo inferiore, non dovrà sentirsi possessore di un prodotto di serie B

- il cambio di look, che deve essere importante ma senza stravolgere ciò che iPhone è stato fino ad oggi.

Intanto, i rumors contagiano anche la versione high-cost 5S. Sembra che al nero e al bianco, ora gli utenti potranno scegliere anche una versione color oro/champagne…

Ciò che si può fare è avere un po’ di pazienza e aspettare poco più di 15 giorni per verificare quanto di vero si è detto e scritto fino ad ora.

 

Per qualche informazione in più si vedano anche:

- Apple : une coque en plastique résistante aux rayures pour l’iPhone 5C ? da Generation-nt.com

Leaked photos show Apple’s rumored gold iPhone 5S da TheVerge.com

Sembrano passati anni luce da quando BlackBerry dominava su tutti. Prima simbolo dell’efficientismo di professionisti, manager e colletti bianchi che non si staccavano mai da quel  telefono (quasi fosse una loro appendice) e poi via via re di altri segmenti di mercato, fino alla conquista – roba inaudita, sogno di tutti i direttori marketing – anche degli incontentabili teen-ager.

Metteva d’accordo tutti: era di moda, di tendenza e di utilità. Forma e sostanza insieme. Tastiera facile da usare, un server di posta dedicato che non falliva mai e che consegnava le email in tempo reale. L’ufficio e il business ti seguivano ovunque con BlackBerry. Ma anche gli amici e i loro messaggi.

E ora, invece, la caduta. È sempre strano assistere alla perdita di interesse verso prodotti che ci sembravano inattaccabili dalla concorrenza e dal tempo. Ma cos’è successo al gioiello dell’omonima compagnia canadese?

Cloud_in_touch_Blackberry_logoSicuramente una prima causa va ricercata nell’arrivo degli smartphone, o meglio di iPhone. Per un po’ ha retto la formula che voleva “iPhone buono per i momenti liberi mentre il BlackBerry per il lavoro”. Il telefono Apple si è rivelato un ottimo strumento anche per i professionisti che, finalmente, potevano continuare a inviare e ricevere i loro messaggi di posta elettronica con in più l’opportunità di sfruttare al meglio internet e di accedere a quell’universo di informazioni, di utilità e di svago racchiuso nelle centinaia di migliaia di applicazioni mobile. E di cui BlackBerry non ne aveva capito il potenziale.

A rileggerle ora, le parole – misto di derisione e disprezzo – dell’ex CEO Mike Lazaridis nei confronti del telefono di Cupertino, da lui considerato appena più di un giocattolo, beh… fanno abbastanza effetto.

Secondariamente, la compagnia è stata vittima dei suoi stessi trionfi. Si è di fronte a un classico atteggiamento di chi, raggiunta una posizione di predominio, smette di innovare e si rilassa, pensando che ormai il più è fatto. Un atteggiamento che è costato carissimo anche ad imperi e regni nel passato. Un atteggiamento molto umano, ma che non dà scampo. Ciò ha significato accorgersi troppo tardi che era necessario investire subito nella realizzazione di uno smartphone per non perdere tempo, per non venire superati da altre compagnie e brand. E non parliamo solo di sistemi operativi, ma anche di estetica, con le stesse linee rimaste immutate per anni. Quando alla BlackBerry hanno compreso che quello che facevano non era più sufficiente e che era urgente esplorare nuove vie… gli altri competitor erano ormai irraggiungibili. A questo si deve aggiungere che i risultati ottenuti dallo sviluppo progetti più al passo con i tempi (tablet e smartphone) non si sono rivelati all’altezza delle speranze (basti pensare al PlayBook e ai modelli Z10 Q10).

Terza grande ragione è quella economica. La rincorsa, quando l’avversario è già lontano, costa di più in termini di sforzi e sacrifici. Soprattutto se colmare il gap tecnologico deve avvenire in un momento in cui le vendite sono già diminuite in maniera preoccupante.

E ora? Quali strade si possono intraprendere per non disperdere tutto il know-how di un’azienda dal (recente) glorioso passato?

Nel breve periodo gli analisti del “Wall Street Journal” ne vedono quattro.

1) Creare una joint venture, magari interessata ad acquisire la tecnologia che sta dietro al nuovo sistema operativo BlackBerry 10. I rumors parlano di IBM fra i potenziali compratori (sebbene la multinazionale americana, famosa per le sue acquisizioni, non navighi in acque così tranquille).

2) La compagnia viene smembrata, con la vendita dei pezzi migliori a soggetti diversi. BlackBerry detiene tanti brevetti, alcuni dei quali molto interessanti (per esempio per compagnie come le cinesi ZTE o Huawei, che poco investono in R&D).

3) La vendita a un altro gruppo. Anche in questo caso, il futuro acquirente comprerebbe un marchio in crisi (sebbene con un suo, pur piccolo, gruppo di aficionados), ma anche un know-how di grande rispetto e una tecnologia funzionante. I nomi? Microsoft, Samsung o la cinese Lenovo. L’ostacolo, tuttavia, potrebbe essere posto dal governo canadese, ostile all’acquisto da parte di un gruppo straniero.

4) L’uscita dalla Borsa. Ma in questo modo sarebbe più difficile trovare un gruppo di private-equity propenso a correre il rischio di puntare sul suo rilancio.

Ciò che resta è un’azienda che ha avuto una buona idea, l’ha perseguita e sviluppata con grande forza e meticolosità, che ha goduto dei frutti del suo lavoro e che – rifiutando di vedere che il panorama stava cambiando – vive i suoi giorni del declino.

 

Per qualche idea in più di veda anche l’articolo di Eric Zeman BlackBerry’s Collapse: 5 Key Mistakes per InformationWeek.com

Sicurezza e inviolabilità. Da sempre due dei punti di forza di Apple e dei suoi sistemi operativi installati tanto sui computer desktop che su iPhone e iPad. Ora alcune applicazioni presenti sull’AppStore potrebbero nascondere intenzioni poco nobili, divenendo una minaccia per i nostri dispositivi. Si tratta delle cosiddette Jekyll Apps, ovvero applicazioni che sembrano del tutto normali in quanto hanno regolarmente passato le fasi di valutazione/approvazione necessarie per essere pubblicate sullo Store, ma la cui normalità è, tuttavia, solo di facciata. Come il protagonista del famoso romanzo di Robert Louis Stevenson, queste app passano dall’essere innocue dottor Jekyll pronte al download a malvagie e pericolose Mr. Hyde.

dr-jekyll_and_mr-hyde_applicazioni_malvagie

Siamo comunque di fronte a un fenomeno molto marginale che rende l’epidemia di malware nel negozio di Apple qualcosa di davvero improbabile. Inoltre, molte delle “armi” in mano alle Jekyll app non produrrebbero alcun effetto sul nuovo sistema iOS7. A Cupertino tengono ugualmente gli occhi ben aperti per evitare che ciò si trasformi in un problema reale.

Ce ne parla in modo approfondito Nick Arnott in un suo articolo per iMore.com

 

Jekyll apps: How they attack iOS security and what you need to know about them

Today researchers Tielei Wang, Kangjie Lu, Long Lu, Simon Chung, and Wenke Lee from Georgia Tech gave a talk at the 22nd USENIX Security Symposium and revealed the details of how they got a so-called “Jekyll app” through the App Store approval process and into a position where it could perform malicious tasks. Their methods highlight several challenges to the effectiveness of the Apple’s App Store review process as well as security in iOS. The researchers immediately pulled their app from the App Store after downloading it to their test devices, but demonstrated techniques that could be used by others to also sneak malware past Apple’s reviewers.

The details of Apple’s app review process are not publicly known, but aside from a few notable exceptions it has been largely successful in keeping malware away from iOS devices. The basic premise of a Jekyll app is to submit a seemingly harmless app to Apple for approval that, once published to the App Store, can be exploited to exhibit malicious behavior. The concept is fairly straightforward, but let’s dig in to the details.

The App Store review process

When a developer submits their app to Apple for review the app is already compiled, meaning that Apple does not have the ability to view the actual source code. It is believed that two primary components of Apple’s review process are a hands-on review of the app and static analysis of the application binary. The hands-on review consists of Apple actually putting the app on a device and using it to make sure that it meets the App Review Guidelines and does not violate any of Apple’s policies. The static analysis portion is likely an automated process which looks for any indications of linking to private frameworks of use of private APIs in the compiled code. Apple has a number of private frameworks and APIs that are necessary for the functionality of iOS and are used for system apps and functions, but for one reason or another are not permitted for use by developers. If an app links to a private framework or calls a private API, the static analysis will usually detect this and the app will be rejected from the App Store.

A Jekyll app begins like any normal app that you can find in the App Store. In this particular case, the researchers used an open source Hacker News app as their starting point. Under normal conditions, this app connects to a remote server, downloads news articles, and displays them to the user. This is exactly the functionality that Apple would see during the review process. Apple would see a functioning app that meets their guidelines, static analysis would reveal no use of private frameworks or APIs and the app would likely be approved for the App Store. Once a Jekyll app has been approved and released into the App Store, that’s when things take a devious turn.

Inside of the Jekyll app, the researchers planted vulnerabilities in their code, providing an intentional backdoor. After the app had made it on to the App Store and they were able to download it to their test devices, the researchers placed specially crafted data on their news server for the apps to download, which would exploit the vulnerabilities that they had planted in the app. By exploiting a buffer overflow vulnerability in the app, the researchers are able to alter the execution of the apps logic. One of the ways the researchers utilize this is by loading numerous “gadgets” that are spread throughout their code. Each gadget is just a small piece of code that does something. With the ability to alter the execution of the code, the researchers can chain together multiple gadgets which will cause the app to perform tasks that it could not perform originally. But in order to locate these gadgets and call the desired pieces of codes the researchers need to know be able to reliably call the memory location of these pieces of code. In order to do this they would need to be able to determine the layout of their apps memory on a given device.

iOS employs two notable security methods for hampering buffer overflow attacks: Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). ASLR works by randomizing the allocation of memory for processes and their various components. By randomizing where these components are loaded into memory, it makes it very difficult for an attacker to reliably predict the memory addresses that will be used for any various piece of code that they might want to call. DEP strengthens the protection against buffer overflow attacks by ensuring that pieces of memory that can be written to and pieces of memory that can be executed remain separate. This means that if an attacker is able to write to a piece of memory, for instance to insert a maliciuos piece of their own code, they should never be able to execute it. And if they were able to execute what was in a particular piece of memory, that piece of memory would be one that they are not permitted to write to.

The researchers noted a weakness in the iOS implementation of ASLR. iOS only enforces module level randomization. This means that each executable file, the app, a library, etc., is assigned a random location in memory in which to operate. However, within each of these modules, the memory layout will remain the same, making it predictable. As a result, if you can get the memory address of a single piece of code, you can then infer the memory layout for the entire module, allowing you to call to any other piece of code within that module. To acquire a memory address for this, the researchers plant information disclosure vulnerabilities into their app which leak memory information about modules in their app. This information is then sent back to the server which is able to determine the memory layout of the entire app, allowing it to determine the memory address of any pieces of code it is interested in running and arbitrarily execute them.

As for DEP, this is generally intended to prevent an attacker from exploiting a buffer overflow in an app that they have limited control over. A Jekyll app is a much different scenario in that the attacker is also the developer of the app being exploited. In this situation, they don’t need to control writing to memory andexecuting it. Any sort of payload or malicious code that an attacker would normally need to write to memory as part of their buffer overflow exploit, a Jekyll app developer can just include in the code of their original app. They can then use the buffer overflow to alter the execution of memory in order to load the gadgets that they want. DEP on other systems has been demonstrated to be susceptible to what is called return-oriented programming. The idea is that an attacker can bypass DEP by reusing code that already exists in memory. In a Jekyll app, the developer can plant whatever code that will later need, and effectively bypass DEP by reusing their own code that they’ve put in place.

At this point, the researchers have an app in which they have embedded a number of code gadgets which they can now call and chain together at will, and they are able to alter the flow of the app’s logic without any user knowledge. They could use this to perform behavior that would normally get an app rejected from the App Store, such as uploading a user’s address book to their server (after first convincing the user to grant access to their contacts). But iOS restricts apps to their own sandbox and Apple won’t allow apps that use private APIs so the impact of a Jekyll app is still fairly limited, right?

Private parts

As mentioned previously, Apple will generally reject any apps that link to private frameworks or call private APIs. Due to the lack of transparency we can only guess at how exactly Apple goes about detecting these, but the most likely answer is Apple uses static analysis tools to detect any private frameworks that have been linked to or any private methods that have explicitly been used in the code. But with a Jekyll app, we’ve seen that the researchers have the ability to dynamically alter code, so how does that affect private APIs?

There are two private APIs of particular interest here: dlopen() and dlsym(). dlopen() allows you to load and link a dynamic library by just its filename. It just so happens that private frameworks always reside in the same location on a device, so that’s easy enough to figure out. dlsym() allows you to look up the memory address of a specified method for a framework loaded by dlopen(), which is exactly what you would need to to call a private method in a Jekyll app. So if the researchers can manage to locate dlopen() and dlsym(), they can use those private methods to easily load any other private APIs on the device.

Fortunately for the researchers, these two APIs are commonly used in public frameworks. Public frameworks use these APIs through what are called trampoline functions. Through the use of a debugger, the researchers were able to identify the offsets of these trampoline functions relative to the beginning of some public frameworks. Using the information disclosure vulnerabilities discussed above that allow the researchers to leak information about the memory layout of any given module, the researchers can use these known offsets to point to the trampoline functions for dlopen() and dlsym() with their app. Pointing to those functions, the researchers can now dynamically load any private framework and call any private API in their app. And remember, none of this is happening when Apple is reviewing the app. This only gets triggered after the app has been approved.

The attack

Now that we see how the researchers can alter the flow of their app and call private APIs, let’s see what that amounts to in terms of malicious behavior in a Jekyll app.

The researchers noted a number of different attack possibilities (though it should not be taken as a complete list of possible attacks) for both iOS 5 and 6. In iOS 5 they are able to send SMS and email without any user interaction or notification. By using private APIs to send SMS and emails directly to the iOS processes responsible for actually sending these messages from the device, the Jekyll app was able to send these out without showing anything to the user. Fortunately, the way these operations work has since changed and these attacks do not work as of iOS 6.

In iOS 5 and 6, the researchers have been able to access private APIs for posting tweets, accessing the camera, dialing phone numbers, manipulating Bluetooth and stealing device information, all without user intervention. While posting unauthorized tweets may not be the end of the world, the others are cause for a little more concern. Access to your camera would mean an attacker could covertly take photos and send them back to their server. Dialing phone numbers without user knowledge could be used to make toll calls, or even to set up call forwarding to have all of a victim’s incoming phone calls forwarded on to another number. Clearly when an app can access private methods, things can get creepy and it’s apparent why Apple restricts access to these functions.

Addressing the problem

Unfortunately, Apple’s current review process isn’t set up to detect this type of behavior. Apple only reviews the app’s behavior as it is at the time of review. If its behavior is altered once it is live in the App Store, Apple is not at all equipped to detect these changes and monitor the real-time behavior of apps after they have gone live. Apple could require developers to submit their source code as well, but it would be infeasible for Apple to go through and inspect the source code of every application submitted to the App Store. Even if they could inspect every line of code either manually (not even close to possible) or with automated tools, bugs are often times not easy to visually spot in code, especially if you have a malicious developer determined to hide bugs intentionally. The researchers did say that Apple responded to their findings with appreciation, but the researchers do not know what, if anything, Apple plans to do about the issues. It’s also worth noting that these challenges are not unique to Apple.

There also isn’t much that users can do for themselves in this case. While you could proxy your device’s traffic to try and see what it’s doing, a developer intent on hiding what they’re up to could easily encrypt the app’s traffic. They could also use certificate pinning to ensure that nobody is able to perform a man-in-the-middle attack to decrypt the traffic. If a user had a jailbroken device, it’s possible that they could perform real-time debugging while the app is running to determine what it’s doing, but this is well beyond the capabilities of most users. A Jekyll app could also be set up to only attack certain users, so even if a person knowledgable enough to perform such debugging installed the app on their device, there would still be no guarantee that they could easily get it to exhibit the malicious behavior.

iOS 7 and what is there left to do?

One piece of information the researchers were able to share with iMore is that many of the attacks they placed in their Jekyll app did not work on iOS 7. While we don’t know specifically which ones still worked and which didn’t, it’s possible that Apple mitigated some of the threats in a similar fashion to how they broke the ability to send SMS and email without user interaction in iOS 6. While this doesn’t directly address underlying issues in iOS that allow for dynamic code execution, it’s not entirely clear if that’s something Apple could, or even should do.

Altering the behavior of an app based on responses from a server is nothing new, it’s just usually not employed with malicious intent. Many perfectly legitimate apps in the App Store make use of remote configuration files to determine how they should behave. As an example, a TV network might make an app that behaves differently during the slow Summer than it would in the Fall when everybody’s favorite shows are starting back up. It would be reasonable and perfectly legitimate for the app to periodically check with the server to find out if it should be in summer or fall mode so that it knows how to display what content.

There are also legitimate reasons for apps to obfuscate and discretely hide pieces of code in their app. A developer of a news app might embed authentication credentials in the app to allow it to authenticate with their server, but might obfuscate that information in the app to make it difficult for somebody to retrieve them through analyzing their app.

The bottom line

The team at Georgia Tech has provided some very interesting research. In evaluating Apple’s security mechanisms in iOS and practices in their App Store review process, they were able to uncover weaknesses that could be exploited to get malicious apps onto users’ devices. However, the same result can be accomplished through simpler means.

A malicious developer could obfuscate calls to private APIs by breaking them up across multiple variables that would later be combined together into a single string of text that could call the API. The developer could use a value in a simple configuration hosted on their server to tell the app whether or not to run that code. With the flag disabled during the review process, the malicious behavior would go undetected by Apple and once approved, the attacker could change the flag on the server and the app could begin its assault.

These types of attacks are definitely possible on iOS and have been for some time. So why don’t we see them exploited in the wild more often? There’s likely a multitude of reasons:

  • Even legitimate developers with great apps struggle to get noticed. - With over 900,000 apps in the App Store, it’s easy to have your apps go unnoticed by users. Legitimate developers who put their heart and soul into developer apps that believe will be truly delightful to use often struggle with getting any significant number of people to download their app. A Jekyll app could used to target particular individuals that you might be able to convince to install the app, but getting any significant portion of Apple’s user base to install or even notice your app is no small undertaking.
  • There’s much lower hanging fruit out there. - The Google Play store has struggled with keeping malware out since its debut as the Android Market in 2008. You also have unofficial app stores used by jailbreakers as well as pirates that don’t have the same review process as Apple, where it would be much easier to get a malicious app hosted. The bottom line is, there are many places other than the App Store to spread malware that could do far more damage while requiring much less effort. To keep your house safe from burglars it doesn’t need to be completely secure, it just has to be more secure than your neighbor’s house.
  • Apple can easily pull apps from the App Store at any time and revoke developer accounts. - As we’ve seen on numerous occasions, if an app manages to sneak through Apple’s gates that doesn’t conform to their guidelines, it quickly gets removed from the App Store once Apple realizes their mistake. Additionally, for larger offenses, Apple can and has terminated developer accounts. A developer could sign up for another developer account with different information, but they would have to pay another $99 each time.
  • Once malware makes it past the gate, it’s still playing in a sandbox. - Apple has employed multiple layers of security in iOS. There is no single point of failure in iOS that renders all other security mechanisms broken. One of the security measures that iOS employes is sandboxing. Sandboxing restricts all apps to their own area on the system. Even an app run amok is very constrained in how it can interact with others apps and their data. Some apps allow for other apps to interact with them through use of customer URL schemes, but this communication is very limited and many apps do not have them. With each app restricted to its own sandbox, its ability to carry out malicious tasks is quite limited.

This certainly isn’t an exhaustive list, but shows some of the reasons that, while its technically possible to distribute malicious iOS apps, we don’t see a more rampant problem with malware on iOS. This is not to say that Apple should shrug and do nothing of course. As mentioned earlier, Apple is ware of the research that has been done here and is likely looking at their options for mitigating the threat. In the meantime, users should try not to worry too much. It is extremely unlikely that this research will lead to an outbreak of malware for iOS.

(Immagine copyright Paramount)

Probabilmente la maggioranza di noi pensava che il sorpasso numerico – oltre che tecnologico – fosse già avvenuto da tempo. Invece, è da questo secondo trimestre (Q2) che gli “intelligenti” smartphone hanno sorpassato per unità vendute nel mondo gli “ottusi” dumbphone, così come sono chiamati i vecchi cellulari. Quelli che solo qualche anno fa ci vantavamo di possedere, per i quali sborsavamo cifre assurde e che ora rinneghiamo quasi di conoscere.

Oltre al sorpasso degli smartphone, i dati forniti dalla società di analisi Gartner confermano la maggiore diffusione del sistema operativo Android (79%) favorito anche dalla presenza di tanti modelli, di prezzi più contenuti rispetto agli iPhone e a marche spesso forti in mercati quali Asia, Est Europa e America Latina (in Cina si sono venduti, per esempio, 10 milioni di telefoni targati Lenovo nel Q2). Al secondo posto si conferma iOS-iPhone con il 18%, mentre gli altri sistemi operativi si spartiscono la restante – piccola – fetta di torta di mercato.

Le aree dove è maggiormente cresciuta la diffusione di smartphone tra la popolazione sono: Asia-Pacifico, Europa dell’Est e America Latina, con un aumento rispettivamente del 74,1%, 31,6% e 55,7% rispetto allo stesso periodo del 2012.

A questo punto cosa farà Apple? Lancerà davvero il suo iPhoneC low-cost?

Per maggiori dettagli si veda l’articolo di Natasha Lomas per TechCrunch.com

 

Smartphones Finally Overtook Dumbphone Sales Globally In Q2, Android Now At 79%, Says Gartner

Analyst Gartner has put out its latest smartphone market report, and the Q2 2013 numbers show the inevitable finally occurred: smartphone sales exceeded feature phone sales for the first time. Android has been strangling the life out of dumbphones for years, but it looks like the market tipping point is being reached.

In Q2, Gartner says  worldwide smartphones sales rose 46.5% from the year earlier quarter to hit 225 million units shipped, while sales of feature phones declined 21% year-on-year to 210 million units. Smartphone shipments grew most in Asia Pacific, Latin American and Eastern Europe, with growth rates of 74.1%, 55.7% and 31.6% respectively, but the analyst said sales grew in all regions. IDC‘s recent market figures put Android on approaching 80% worldwide marketshare for Q2. Google’s mobile OS is clearly expanding its share by picking up former feature phone users.

The rising tide of global smartphone ownership is raising all boats, but Samsung continues to dominate the smartphone landscape. Gartner said Samsung grew its share to approaching a third (31.7%), up 29.7% on Q2 2012. Apple also grew shipments of its iPhone but its marketshare declined — highlighting the case for Cupertino to make a low cost iPhone to capture growth at the budget end of the market. Apple took a 14.2% share in Q2, 2013, vs 18.8% in the year ago quarter. It still shipped 10.2% more iPhones vs Q2 2012 but is being outpaced by higher smartphone market growth rates.

After Samsung and Apple, it’s a tale of all Asian smartphone makers battling for third place: LG grabbed third place in Q2 (with a 5.1% share); followed by Lenovo (4.7%) whose Lephone has been a popular seller in China; and ZTE (4.3%).

table 1

Gartner said Apple saw a significant drop in the average selling price (ASP) of its devices in Q2, with its ASP declining to the lowest figure registered by Apple since the iPhone’s launch in 2007. This is down to strong sales of the iPhone 4 — again underlining the case (from a volume perspective) for Apple to launch a cheaper iPhone. However doing so would clearly accelerate that decrease in its ASP, even if market growth is now being powered by budget devices — providing the impetus for Apple to expand the iPhone to cheaper price-points still.

“While Apple’s [declining] ASP demonstrates the need for a new flagship model, it is risky for Apple to introduce a new lower-priced model too,” commented Gartner analyst Anshul Gupta in a statement. ”Although the possible new lower-priced device may be priced similarly to the iPhone 4 at $300 to $400, the potential for cannibalisation will be much greater than what is seen today with the iPhone 4. Despite being seen as the less expensive sibling of the flagship product, it would represent a new device with the hype of the marketing associated with it.”

Also noteworthy in Q2, Microsoft’s Windows Phone platform pushed past BlackBerry’s OS for the first time to take third place. When Windows Phone launched, back in 2010, Steve Ballmer and Nokia’s CEO Stephen Elop talked of their ambition to create a third ecosystem in the smartphone space. They’re still trying to stock the fires of an ecosystem but are at least in third place from a sales perspective.

Windows Phone took a 3.3% global market share in Q2 vs just 2.7% for the struggling BlackBerry OS. Gupta, noted: “While Microsoft has managed to increase share and volume in the quarter, Microsoft should continue to focus on growing interest from app developers to help grow its appeal among users.”

Taken together, Android and iOS took a 93.2% global marketshare in the quarter — underlining why developers opt to support these two platform first and foremost, and generally require incentives to expend effort elsewhere. Android’s global marketshare in Q2 was a staggering 79% according to Gartner, up from 64.2% in the year ago quarter — buoyed by feature phone switchers.

table 1

The drop off in feature phone sales is bad news for Nokia, which still leans heavily on its feature phone business (being as its smartphone business is tied to the Windows Phone underdog). Nokia shipped just 61 million feature phones in Q2, down from 83 million in the year ago quarter. But the Finnish mobile maker is at least seeing some decent growth in smartphones, thanks to having a broader portfolio of devices to offer at different price points. Nokia’s Windows Phone-powered Lumia sales grew 112.7% in Q2 2013, according to Gartner.

 

 

 

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 osxdaily.com, 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 howmuchtomakeanapp.com: fate il preventivo della App dei vostri sogni e scoprite quanto può costarvi (negli USA)…

 

Immagine ©Shutterstock