ABI Research has a new press release on how in-app purchases will outpace paid apps in 2012. It goes on to explain how in-app purchases on the Android market have been hampered by Google. In-app purchase were only introduced in July 2011 and only recently added 17 mostly European countries. Even paid apps aren’t available in all countries.

My personal belief is it’s best avoiding Google paid and in-app purchasing altogether. Design your app/service so that the app is always free. This way you will get maximum downloads and won’t get tied into the Android Market. For example, you might want to also distribute on the Amazon store or SlideME.

I believe the best revenue model is one where the user pays for a subscription to some server-side service. Most of the functionality needs to be on the server and the app is just a view on this data. The app should still be able work without the paid server service but the incentive should be for the user to subscribe to obtain the server side functionality or improved server side functionality. A great example of this is Evernote.

A subscription obviously brings recurring revenue. Asking the user to pay for a server side service also insulates you from from being perceived as an app with low (unsustainable) unit cost. You can charge tens of dollars (Euros or Pounds) rather than join the race to near-zero app cost.

Gartner have just released their worldwide smartphone stats for Q4 2012. Total smartphone sales in 2011 reached 472 million units and accounted for 31 percent of all mobile devices sales, up 58 percent from 2010. Of interest to developers is the table showing platform market share…

These figures are interesting because they are world figures, not just US numbers as shown by some companies and analysts. The order of magnitude of the various numbers backs up those given by Canalys last week.

Yesterday evening I was at Mobile Monday London’s Data Driven Mobile Apps - Open data event.

The panel was chaired by Matt Biddulph, founder of Dopplr and previously Head of Data Strategy for Location and Commerce Applications at Nokia. The panel consisted of Leigh Dodds, CTO of Kasabi, Jeni Tennison, Linked Data Expert, Technical Architect legislation.gov.uk, Ian Holt, Developer Programme Manager at the Ordnance Survey and Hannah Donovan, Design Director, The Echo Nest.

The event started by trying to define what’s a data driven app. The consensus was that it’s an app that uses dynamic (as opposed to static) api data that also ideally uses contextual information to filter data while also sometimes sending data back to improve the usefulness of the service. This feedback of information and sometimes user generated content is the ’secret sauce’ Matt spoke of that make some apps get better as more data becomes available.

A member of the audience commented that apps can also sometimes get worse with more data, for example Twitter and Facebook, where the signal to noise ratio can become problematic. The drive for real-time information has caused some services to become noisy. Often the noise can be useful as well and there’s scope for separate apps to present and filter this information in a slower way. Apps should concentrate on showing what the end user needs and not blindly show all api data.

There was brief disagreement (or was it misunderstanding of api vs what’s shown in UI) whether apis should be tailored to reflect specific usecases.

There was discussion on whether we actually have a smaller percentage of publicaly available information than in the past when such information was nearly always placed in (physical) libraries. The difference now is that information is available to everyone, everywhere whereas libraries previously only favoured the rich and literate.

There was talk of the legality of combining information. It’s a murky area where creative commons doesn’t strictly apply to data. There are also related problems with data provenance (identifying where it come’s from) and an attribution stacking problem where mashups of data sets result in too many parties needing to be attributed/mentioned.

An interesting question from the audience was whether information is tending towards free and how this affects revenues. There’s also the issue that tax payers have already paid once for data so maybe it should be free. Ian Holt from Ordnance Survey wisely answered it was out of his scope to answer on this (contentious) issue. It’s an interesting question that I’ll come back to at the end of this post as I have some experiences of this issue.

Two other issues mentioned briefly were data protection and permission-based apps. The requirements often vary by country. It was acknowledged that current oAuth based permission systems are too course and users need better clarity and reasoning why specific data is being shared.

There was a very brief apps vs web debate which was a bit pointless because only apps currently have the ability to use sensors (for context), have the required UI fidelity and can trigger notifications.

My personal experience of using public data hasn’t been positive. A while ago I wrote a free app for Java ME and Android that mashed up UK traffic information from the various traffic agencies. It used (and still uses) my server which was ok while I was getting low traffic. O2 became interested in the app and wanted to sell it on their app store. I planned to use the small income to get a separate server to support the potentially much increased traffic while also improving the app. At this point I had to investigate the legality of re-selling the information. It turned out, after a committee meeting at Traffic Scotland, that they wouldn’t allow people to make money from their data because it has already been paid for by tax payers.

Maybe I was too honest and pedantic. I know many developers of mashed up data just publish and noone cares or notices. It’s certainly a murky area. It’s less of a problem for adventures such as mine but for large companies whose legitimacy depends on the legality of their mashed up data, this could be a time bomb.

Altimeter has some new research on Mobile Strategies for Retail. It concludes that many retailers are not doing enough for their customers despite the fact that the majority of them now carry a smartphone and are are amenable to making a purchase via mobile.

The report goes on to explain how retailers can develop a mobile strategy.

I personally believe one of the problems is the perceived cost. Mobile is so popular at the moment that media and marketing agencies are becoming the predominant way of getting an app developed. Unfortunately, this puts up the cost and bureaucracy and it’s increasingly common for apps to end up costing six figure sums (dollars, Euros, pounds). It doesn’t need to be this way. Search out an independent mobile developer and you should be able to create your app for a low double digit cost.

There’s a growing number of hosted services that allow you to concentrate on your smartphone apps while leaving the server-side to someone else. The idea is that custom scalable, secure and managed services are difficult and costly to create so instead you piggy-back on a service that has already solved these problems. There’s a useful new blogpost and infographic (png) at kinvey that depicts backend providers, service providers and their inter-relationships with mobile SDKs, mobile APIs and handset OEMs.

If you have a hobby project or proof of concept then this type of service is great to get you going quickly. However, if you are offering a commercial app you should do your due diligence. Here are some things you should be thinking about…