Since the release of iOS 3.1 in September 2009, Apple’s App Store has a Genius for Apps feature, which recommends apps based on the other apps you use and just how often and how long you use them. If you backup your iOS device, Apple also syncs the database with the info Genius for Apps needs, so you too can view this information – it’s just a matter of knowing where to look and how to read it. I’ve been asked about this a few times by a few people, so I figured this post was due.
Some notes and disclaimers up front: what I’m about to describe requires a little bit of technical knowledge. (Not a lot – after all, I can do it. But it does require some.) It’s also written for Macs, since I don’t own a Windows machine. It’s also only valid at this particular point in time, since Apple isn’t shy about changing things. Finally, I don’t use Genius for Apps. If Genius for Apps is activated, the data stored or the length it’s retained could be completely different. Or it could be identical.
First, you’ll need to find the location of the MobileSync backup you’re interested in. (On my Mac, they live under the ~/Library/Application Support/MobileSync/Backup directory.) You’ll see one directory for each of the devices you’ve synced with your computer, named after each device’s UDID.
In each of these backup directories, there’s a lot of files – my most recent backup contains over 2,000! The files are all cryptically named with universally unique identifiers – long hexidecimal strings. In order to find the file containing the Genius for Apps data, you’re going to have to search for it. Pop open the Terminal, go to the directory of the backup you’re interested in, and type ‘grep daysSince1970 *’. That’ll return one match – the file we’re interested in. This works because the file we’re after uses ‘daysSince1970′ as a column name, unlike every other file in that directory.
The file you’ve identified is a sqlite database, so you’re going to need a way to read it. I’m fond of both MesaSQLite and Base, although there are countless others.
When you open the sqlite file, you’ll see a few tables. The one we want is ‘Scalars’. The Scalars table contains key-day-value triples, where the key is a string combining the type of information being tracked with the application’s ‘bundle identifier’ – information that identifies the application and company. Usually (although not always) you can identify the application from the bundle identifier.
For example, there’s a key in my database that reads ‘appLaunchCount.com.magnetismstudios.citytransit’. This means the row contains information about ‘appLaunchCount’ for the excellent City Transit application by Magnetism Studios.
The day information is stored within the ‘daysSince1970′ column – the number of days since the start of the Unix epoch. There’s lots of sites online for converting this to a comprehensible date – for instance, here. In my row about City Transit, the daysSince1970 contains the value ‘15065’ – April 1st, 2011.
The value column is unitless, and you have to try and figure it out from the context given by the key. In my City Transit example, the ‘value’ is ‘1’. Since the key contains the string ‘appLaunchCount’, I’m going to take a wild leap and deduce that I launched City Transit exactly once on April 1st.
A few interesting key prefixes in this file relate to app usage:
- appActiveTime – likely the length of time the app’s been active. I’d been assuming this is in seconds, but that might be wrong – see appBackgroundActiveTime for details.
- appBackgroundActiveTime – the length of time the app’s been running, but in the background? I’ve got a data point here with a value of 153,816 – and since there’s only 86,400 seconds in the day, I’m a bit stumped as to what the units could be. Tenths of seconds? A little testing could make this clear.
- appLaunchCount – already covered, the number of times the app launched. But see ‘appActivationCount’.
- appActivationCount – I suspect this is the number of times the app came out of the background. The number of times the user started the app on a day would therefore be appLaunchCount + appActivationCount.
Some quick notes on the usage data:
- My sqlite database contains a month of data – older data seems to be dropped.
- The sqlite database is populated whether you’re using Genius for Apps or not. I suspect this is so Genius has historical data to work from the second it’s turned on. One assumes that while the data is recorded on the phone at all times, it’s not sent to Apple unless Genius is active.
- The sqlite database also contains application usage info for Apple’s internal applications, including the phone or IM apps.
- While privacy advocates are extremely touchy these days, nothing particularly personal seems to be stored – for instance, this database doesn’t contain the content of your IMs or the phone numbers you’ve called. I suppose it could be an issue if you’re using any sensitive applications – but the applications themselves are already backed up elsewhere on your computer.
- Since Genius can be activated directly from the phone, I’m guessing the data’s sent from the phone to Apple and only backed up to the computer.
- There’s a lot more information in this file beyond app usage, but (to me) it’s relatively boring stuff like number of writes to the Flash memory. I’ve described those keys at the bottom of this post.
I have no idea whether Apple’s storing the data it receives, or just dropping it on the floor. The usage data could have a number of uses to Apple beyond the Genius for Apps feature. For instance, it could be used to offer a (very basic) analytics product to developers (unique users, session counts, and time spent), to modify how applications are ranked in the App Store, or for iAds targeting.
Although the data could change or vanish at any moment, and therefore is risky to use, it could also be used by companies outside of Apple. Opt-in market research panels – the type operated by comScore or Nielsen – could use this to estimate iOS application usage by the general population. Desktop or web apps could use it to provide better recommendations, in an attempt to out-Genius Genius. (Of course, web apps would require a browser extension or Java applet to access the file system. Some are already doing this, with user permission – mostly just to grab what applications are installed, but at least one is grabbing the usage information as well.) Developers could build tools allowing users to track their app usage over time – a RescueTime for your phone.
SOMEWHAT BORING (TO ME, ANYWAY) APPENDIX: Here’s a rundown of the key prefixes in this table that don’t directly relate to app usage:
- appBackupFileCount – specific to individual applications, likely the number of files from that application backed up on that day. For instance, my appBackupFileCount for Facebook is ’30’ – so I’m guessing 30 of the over 2,000 files in my Backup directory are related to Facebook.
- appBackupFileSize – specific to individual applications, this seems to show the size, in bytes, of the files that the application backed up on that day.
- appRegularTileCount – I believe the number of times the app shows a map tile, since this only shows for apps containing maps.
- appReverseGeocodeRequestCount – again, specific to map-using applications. Reverse geocoding involves translating a latitude / longitude pair to a physical address.
- appTileRequestCount – again for map-using applications, what I presume is the number of times an app requests a map tile.
- com.apple.GameKit… – I don’t use Game Center much, so I doubt I have the complete data here. In a month’s worth of data, all I’ve got are a few ‘com.apple.GameKit.login.appInit’ and ‘com.apple.GameKit.invite.cancel’ keys.
- com.apple.MobileBackup.fileCount – what I presume is the number of files backed up that are relevant to a particular function. For instance, I’ve got a ‘com.apple.MobileBackup.fileCount.cookies’ key that’s always set to ‘4’.
- com.apple.MobileBackup.fileSize – what is likely the file size of the files backed up to support particular functions. For instance, my ‘com.apple.MobileBackup.fileSize.cookies’ key has a value of ‘26886’.
- com.apple.NANDInfo – a whole bunch of keys relating to the phone’s memory. ‘NumFreeVirtualBlocks’, ‘NumLogicalReads’, ‘NumLogicalWrites’, ‘NumPhysicalReads’, ‘NumPhysicalWrites’, etc.
- com.apple.accessibility – a few keys, indicating whether certain accessibility features (‘largefonts’, ‘whiteonblack’, etc.) are enabled.
- com.apple.maps – a few keys relating to usage of map features (‘SearchRequestCount’, ‘StreetViewTileCount’).
- com.apple.mobileslideshow – a couple of keys showing how many photos and videos are synced with the device.
- com.apple.springboard – keys tracking disk space (both used and free), reboots, the number of third party apps, and the amount of time connected to wifi.