The plot thickens on the future of analytics on the iPhone. To recap the story so far, section 3.3.9 of the iPhone OS 4.0 developer agreement prohibits the developer from including third-party software to collect and send device data to a third party for processing or analysis. This prevents the use of libraries from companies such as Flurry which allow developers to understand how their applications are being used.

This week Steve commented directly on Flurry whilst answering questions at the D8 conference (see D8: Steve Jobs on iAds Restrictions for video). The key comments as best as I can capture them are as follows:

One day we read in the paper that a company called Flurry Analytics has detected that we have some new iPhone and other tablet devices that we are using on our campus. We thought “What the Hell?” and the way that they detected this is that they are getting developers to put their software in their Apps and their software is sending out information about the device and about its geolocation and other things back to Flurry.

He then goes on to make the key point about user privacy:

No customer is ever asked about this, it is violating every rule in our privacy policy with our developers and we went through the roof about this. So we said no, we are not going to allow this.

He then indicates in what situations sending data to a third party will be allowed:

We are only going to allow these analytics that don’t give device information and therefore solely for the purposes of advertising.

Finally in response to a follow up question about the legitimate uses of analytics by a developer:

There is no excuse for them not asking the customer whether it is appropriate to send that personal private data to an analytics firm.

He does hold out the hope that they will work with companies like Flurry in the future but not until they (Apple or possibly Steve) have calmed down.

Why use Analytics?

For the developer it is extremely interesting to know what percentage of your users are on which device or version of the OS. For some real world examples take a look at lecture 20 from the Stanford University iPhone Application Development (Winter 2010) course where James Anthony from inedible software talks about using analytics.

Every iPhone developer eventually starts asking themselves some variation on the following questions:

• Should I continue to support a version of iPhone OS (e.g. 3.1)?
• Is it worth using features introduced in the latest version of the OS?
• How many users are running my Universal app on the iPad?
• How many users use feature X in my app?

In each case analytics can give you hard data to answer these questions without guesswork. Of course if your applications communicates with a central server (perhaps to save high scores for example) you also have the possibility to send some device data for your own analysis. What Apple is expressly prohibiting is that you use a third-party to collect or store this data and in either case you should be getting the users permission.

In addition to device information Flurry also allows you to define events in your application so that you can measure how often a user accesses a certain feature and how they navigate through your app. This is great data if you are looking to improve your app.

So what should we do now?

I have not looked at other analytics packages but my guess is that they all have the same problem as flurry. If you are a developer with applications that already use these third-party tools you are currently facing some confusion. If you strictly interpret the developer agreement and Steve’s comments you should remove Flurry from your app as it is clearly sending device data to a third party. The alternative is to wait and see if Apple starts testing for Flurry and rejecting apps that include it - a potentially risky strategy.

I would expect companies like Flurry to modify their library to only send information that Apple deems as acceptable but so far we have yet to hear from Flurry on what they will do. Flurry currently collects the following technical information about the device which would seem now to be prohibited:

• Device Model (e.g. iPhone 3GS, iPod Touch 3G, Apple iPad)
• Carriers
• Firmware Versions (e.g. iPhone 3.1.3, 3.2)

I think if they were to switch off this device data and just leave the event data it might be acceptable to Apple but it does remove some data that most developers find useful.

What is clear though is that if you include analytics you should get the users permission when the application first launches and include a setting to allow the user to enable/disable the feature. Doing otherwise is beginning to look like risking rejection.