Inside Apple's routined Databases, Part 3: Cloud-V2.sqlite, When One Device's Evidence Lives on Another
Updated: Sep 8
This is Part 3 of a four-part series on routined's SQLite databases. Part 1 covered Cache.sqlite, the raw local buffer. Part 2 covered Local.sqlite, the durable per-device record. This post covers Cloud-V2.sqlite; the layer where that record stops belonging to just one device.
Why This Database Exists
Everything up to this point in the series has been about a single iPhone learning about itself. Cloud-V2.sqlite exists to solve a different problem: a person doesn't carry just one Apple device. They have an iPhone, maybe an iPad, maybe a Mac and Apple wants all of them to benefit from the same learned understanding of "significant locations" without each device independently spending a week collecting its own raw GPS history from scratch.
The file lives at the same address as its siblings:
/private/var/mobile/Library/Caches/com.apple.routined/Prior to iOS 13 it was named Cloud.sqlite; from iOS 13 onward it's Cloud-V2.sqlite. The rename tracked a real schema change, not just a cosmetic one. iOS 13 introduced the ZRTMAPITEMMO table for associating visits with actual named points of interest, and follow-on updates continued to reshape how location data was represented, including removing some of the raw reverse-geocoding BLOB data that earlier versions carried.
This database's entire reason for existing is synchronization: it's the copy of significant-location data that Apple is willing to transmit off the device, specifically because it can do so under end-to-end encryption, meaning Apple's own servers cannot read the contents.
How It's Used By the Device
Structurally, Cloud-V2.sqlite closely mirrors Local.sqlite. You'll find the same core cast of tables:
ZRTLEARNEDVISITMO: learned visits, with creation/entry/exit timestamps, coordinates, and confidence scoring
ZRTMAPITEMMO: named points of interest tied to a visit, rather than a bare coordinate
ZRTADDRESSMO: resolved address data, down to oddly specific fields like whether the location sits near inland water or ocean
The device uses this synced data to make the "personalized services" story true across an entire Apple ID rather than a single handset: predictive traffic routing that works the same on the iPad you occasionally drive with mounted in the car, Photos Memories that recognize a place regardless of which device took the photo, and proactive suggestions that feel consistent no matter which device you happen to be using at the moment.
Functionally, this is the fulfillment of the promise made in Apple's own Significant Locations description: your device and your iCloud-connected devices keep track of places you've recently been. Cloud-V2.sqlite is where that promise becomes literal rows in a database.
How It Syncs Across the Apple Ecosystem
This is the database where "sync" stops being a side detail and becomes the entire point, so it's worth being precise about the mechanism. Apple describes Significant Locations data as end-to-end encrypted between a user's iCloud-connected devices; meaning the data is encrypted such that Apple's infrastructure itself cannot read it, only devices that hold the right key material can. That's a meaningfully different tier of protection than an ordinary iCloud-synced field like a Contacts entry or a Calendar event, which Apple can decrypt server-side under normal circumstances.
It's also worth knowing this wasn't always airtight in practice. Researchers previously identified a period where significant-location data appeared to leak into ordinary account sync channels rather than staying properly end-to-end encrypted; behavior Apple subsequently addressed. Later iOS versions restored the intended behavior: the data genuinely appears to sync across a user's devices via iCloud, rather than merely being restored from a backup, which is itself a distinctive behavior worth understanding as an examiner. It means a factory-reset device, freshly signed into the same Apple ID and with Significant Locations enabled, can rebuild a meaningful chunk of this location history purely from the sync, not from a backup file at all.
For forensic purposes this creates a genuinely novel situation compared to Parts 1 and 2: the device you're holding may not be the device that generated the evidence inside it. A shared iCloud account across a household, or a suspect's secondary device, may carry synced significant-location records that were actually learned by an entirely different piece of hardware.
Forensic Value
Cloud-V2.sqlite carries the same core evidentiary strengths as Local.sqlite: durable, confidence-scored, resolved-address visit history plus several considerations unique to its role as the synced layer.
Why it's valuable:
Redundancy.
If a primary device is lost, destroyed, or its Local.sqlite has been pruned, a secondary Apple device signed into the same account may still hold synced significant-location records, giving investigators a second bite at the same evidentiary apple (so to speak).
Cross-device corroboration.
Comparing Cloud-V2.sqlite on two different devices tied to one account can help establish whether a location record genuinely originated on the device in hand, versus arriving there purely through sync. Relevant when attributing conduct to a specific device or user.
Points of interest and enriched address data
Similarly to Local.sqlite, which reduce manual work translating coordinates into meaningful places.
Why it complicates the picture:
Attribution gets harder, not easier.
A record's mere presence on a device doesn't establish that that device generated it, only that it's signed into an account that generated it somewhere. Multi-device, multi-user households are a genuine confound here.
Encryption access requirements are different from a normal iCloud pull.
Because this category is end-to-end encrypted rather than standard synced data, accessing it typically requires either a full file system extraction of a trusted device itself, or where cloud-based extraction is attempted, authenticating as one of the account's own trusted devices with that device's own passcode, not merely the iCloud credentials alone. Cloud data acquisition here does not behave like pulling ordinary iCloud contacts or calendar sync.
Timing and provenance need extra scrutiny.
Because this table can be populated purely by sync rather than by local learning, an examiner has to be more careful separating "when this device learned this" from "when this device received this."
What Questions Does It Answer
Cloud-V2.sqlite answers a related but distinct set of questions from Local.sqlite:
Does this significant-location record appear consistently across every device on the account, or only on one? What does that inconsistency suggest about where it actually originated?
Could a location record found on this device have actually been learned by a different device on the same Apple ID, i.e. a spouse's phone, a second device, a family iPad?
If a primary device is unavailable, does a secondary trusted device on the same account still preserve equivalent significant-location history?
Was Significant Locations / iCloud sync actually enabled for this account at the relevant time, such that cross-device sync is even a plausible explanation for the data present?
Do points of interest (named locations, not just coordinates) corroborate a specific claimed destination such as a workplace, a specific business, rather than just "a location in this area"?
That last category of questions, about attribution, provenance, and what a defense or prosecution can fairly claim a piece of routined data proves is really the throughline for the whole series. Which brings us to the final post: how all three of these databases, and the distinctions between them, actually get argued about once they leave the lab and enter a courtroom.
Next in the series: the wrap-up, chain of custody for FFS extractions, authentication and expert-testimony considerations, the attribution problem introduced by cross-device sync, and how courts have treated routined location evidence so far.
⚠️ Disclaimer: This information is provided as-is, for educational and lawful forensic use, with no warranty of accuracy or fitness for purpose. Always independently verify results against source data before relying on them for investigative or legal purposes. Not legal advice. Use at your own risk.
Comments