The Cache, the Local, and the Cloud: An Introduction to routined
This is the introduction to a five-part series on routined, the quiet daemon behind a surprising amount of what your iPhone seems to "just know." The posts that follow go deep on three specific databases — Cache.sqlite, Local.sqlite, and Cloud-V2.sqlite — and close with a look at how this data actually plays out in court. This post is the scene-setter: what routined is, where it came from, and why three small SQLite files are worth an entire series.
Meet routined
Somewhere on every modern iPhone, a background process called routined is running, quietly doing something most users have never heard of and never explicitly agreed to in any meaningful sense: it's learning your routine. Not in the sense of a to-do list or a calendar. In the sense of noticing, moment to moment, where the device physically is, how fast it's moving, which Wi-Fi networks are nearby, and, over days and weeks, which of those locations keep recurring often enough to matter. That accumulated pattern is what lets your phone tell you it'll take twenty minutes to get home before you've asked, surface a Siri Suggestion for the coffee app the second you park near your usual spot, or quietly hand a requesting app your approximate location without spinning up the GPS radio and burning battery to get it. routined is the engine. This series is about where it keeps its notes.
For forensic examiners, the routined databases can provide valuable insight into a device's historical movement patterns. However, these databases are also among the most frequently misunderstood artifacts found during an iOS examination.
Unlike application GPS logs or location history generated by navigation software, the databases maintained by routined are not intended to be a chronological record of where a user has been. Instead, they represent Apple's continuously evolving statistical model of device movement. Understanding this distinction is critical.
Where It Comes From
routined traces back to Apple's CoreDuet framework, a system originally built to power on-device "digital assistant"-adjacent intelligence; the connective tissue between location, app usage, and predicted intent that eventually surfaced as Siri Suggestions, proactive widgets, and Screen Time-adjacent behavior tracking. If you've ever poked around knowledgec.db in an iOS forensic image and wondered why app usage, notification activity, and device state all seem to live in the same place, that's the same lineage. CoreDuet's broader mission was always "understand behavior across the device," not just location.
routined is the piece of that lineage focused specifically on place. And because place is one of the most sensitive, most legally consequential categories of personal data a device can hold, it's earned its own small constellation of SQLite files, tucked away in /private/var/mobile/Library/Caches/com.apple.routined/. Invisible in Settings, absent from ordinary backups, and largely undocumented by Apple itself.
Why Three Databases, Not One
The honest answer is that no single file could do this job cheaply. Learning "you go to this address every weekday morning" requires:
Collecting a lot of raw, noisy data -- a GPS fix every so often, all day, every day
Filtering that raw data down into something meaningful -- deciding which clusters of points actually represent a deliberate, repeated visit rather than noise
Making that meaningful conclusion useful across every device you own, not just the one that happened to collect the raw data
Those are three different jobs with three different lifespans and three different privacy postures, and Apple built three different databases to match:
Cache.sqlite
the raw collection layer. Noisy, enormous, local-only, and gone within about a week.
Local.sqlite
the filtering layer. Durable, per-device, holding the distilled "significant locations" your phone has actually concluded matter.
Cloud-V2.sqlite
the sharing layer. The end-to-end encrypted, iCloud-synced mirror of that durable data, so your iPad and Mac benefit from the same learned routine without independently re-collecting a week of GPS history.
Understanding why each one exists and, critically, understanding the boundary between them turns out to matter enormously the moment this data shows up somewhere it wasn't designed to be seen: a forensic report, an expert's testimony, a courtroom exhibit.
Why This Matters Beyond Curiosity
It would be enough if this were just an interesting piece of iOS internals. But routined data has become genuinely significant in real investigations. Precise, timestamped, often minute-by-minute location history is exactly the kind of evidence that can confirm an alibi, contradict one, or place a device (and by extension, plausibly, a person) somewhere specific enough to matter in a criminal case. It's also exactly the kind of evidence that's easy to misread, over-extract, or misrepresent if you don't understand what each layer actually is and isn't telling you.
That's the gap this series tries to close. Each post follows the same structure: why the database exists, how the device uses it, how (or whether) it syncs across the Apple ecosystem, its forensic value, and the specific questions it can answer. By the end, the differences between "this device was here" (Cache.sqlite), "this device concluded this place matters" (Local.sqlite), and "this account learned this place matters, somewhere" (Cloud-V2.sqlite) are second nature. One of the fundamental principles of digital forensics is understanding how evidence is created before drawing conclusions from it. This principle becomes especially important when examining artifacts generated through machine learning and behavioral analysis rather than direct user interaction.
Apple's routined service exemplifies this challenge.
Unlike navigation applications that intentionally record user destinations, routined exists to help the operating system understand how a device moves through the world. It collects observations from Core Location, wireless networks, motion sensors, Bluetooth, and other system services before transforming those observations into increasingly sophisticated behavioral models.
Rather than recording every GPS position, routined attempts to answer questions such as:
Where does this device spend most of its time?
Which locations appear to be home or work?
Which routes are frequently traveled?
Which locations are likely destinations?
Which visits appear intentional?
How confident is the system that these conclusions are correct?
The resulting databases are exceptionally valuable during forensic investigations, but they must be interpreted correctly.
A coordinate stored within Cache.sqlite is fundamentally different from a navigation destination stored within Apple Maps. Likewise, a learned location contained within Local.sqlite represents a statistical conclusion reached after repeated observations rather than direct evidence that a user intentionally visited a location on a particular day.
Understanding these distinctions allows investigators to present accurate conclusions while avoiding the common pitfall of overstating location evidence.
Apple's Location Intelligence Pipeline
The simplest way to understand routined is to think of it as Apple's location intelligence engine rather than its GPS logger. Location information enters the system through several independent sources:
GPS
Wi-Fi positioning
Cellular positioning
Bluetooth observations
Motion sensors
Barometer
Core Motion
Maps
User interactions
These observations are then evaluated by Apple's algorithms before being incorporated into increasingly persistent models of user behavior.
Conceptually, the process resembles the following:
Location Observation (GPS / Wi-Fi / Cellular)
▼
Core Location Fix
▼
Cache.sqlite
▼
Observation Analysis
▼
Visit Detection
▼
Learned Behavior
▼
Local.sqlite
▼
Cloud Synchronization
▼
Cloud-V2.sqliteEach stage increases Apple's confidence that an observed location represents meaningful user behavior. This distinction is central to the forensic interpretation of these databases.
Observation Versus Behavior
Perhaps the most important concept presented in this post is the distinction between an observation and a behavioral conclusion.
An observation simply indicates that the device obtained a location estimate.
A behavioral conclusion represents Apple's determination that repeated observations likely correspond to meaningful user activity.
This difference may appear subtle, yet it dramatically changes the evidentiary weight of the resulting artifacts.
For example, imagine an iPhone repeatedly travels past a coffee shop during a morning commute. Initially, the device may simply record location observations. After days or weeks of repeated observations, Apple's algorithms may determine that this location represents a place of recurring significance.
Nothing about this process establishes that the user intentionally entered the coffee shop. Instead, Apple has concluded that the location forms part of the device's routine movement. This distinction forms the foundation for interpreting every artifact discussed throughout this post.
The Three Databases
Although they share many Core Data entities, each database serves a distinct purpose within the learning pipeline.
Database | Primary Function | Persistence | Forensic Interpretation |
Cache.sqlite | Active observations and machine learning | Volatile | Device observations and intermediate analysis |
Local.sqlite | Learned device intelligence | Persistent | Established behavioral patterns |
Cloud-V2.sqlite | Cloud-synchronized intelligence | Persistent | Learned behavior shared across the Apple ecosystem |
Understanding these roles is essential because identical coordinates appearing in each database may represent entirely different stages of Apple's learning process.
A Proposed Forensic Interpretation Model
One of the goals of this research is to establish a standardized framework for interpreting Apple's location intelligence artifacts.
Rather than asking:
"Was the suspect at this location?"
Investigators should instead ask:
"What does this artifact demonstrate about the device's relationship to this location?"
This subtle shift better reflects the nature of the underlying data. The following framework is proposed throughout this post.
Observation
While looking through the data, I kept seeing the recurring theme in the naming conventions of things and I wanted to point them out, as well as my best idea of what they stand for. Core Data table names are typically just Z + the entity's class name, so ZRTLEARNEDPLACEMO decodes cleanly as Z + RT + LearnedPlace + MO which indicates that it is a managed object from the routine daemon in the Core Data SQLite store titled 'Learned Places'.
Identifier | Where is it found | What does it mean |
Z | 1 Character | The standard prefix Core Data's SQLite store generator slaps on every table and column name (you see it on Z_PK, Z_ENT, ZDATE, etc. too). It's not domain-specific; it's just how Core Data mangles names when it maps your object model onto SQL. |
RT | 2-3 Characters | Short for Routine (as in routined, the routine daemon), the subsystem responsible for learning your significant/frequent locations, trips, and visits. |
SM | 2-3 Characters | Safety Monitoring on the Check In side - Apple's Safety Monitoring feature, iOS 17+. |
MO | Last 2 Characters | Managed Object, i.e. the class suffix Apple uses for its NSManagedObject subclasses (RTLearnedPlaceMO, SMInitiatorLocationMO, etc.). |
Evidence that the device obtained a location estimate.
ZRTCLLOCATIONMO
Interpretation:
The device was likely within the reported accuracy radius of the recorded coordinates.
Inference
Evidence that Apple's algorithms interpreted one or more observations as a meaningful event.
ZRTVISITMO
Interpretation:
Apple inferred that the device may have stopped at this location.
Learned Behavior
Evidence that repeated observations produced a statistically significant pattern.
ZRTLEARNEDVISITMO / ZRTLEARNEDLOCATIONOFINTERESTMO
Interpretation:
Apple identified this location as behaviorally significant based upon repeated observations.
Ecosystem Knowledge
Evidence synchronized between trusted Apple devices.
Cloud-V2.sqlite
Interpretation:
This learned location exists within the Apple ecosystem associated with the account. Attribution to the extracted device should be independently corroborated.
Why This Matters
Digital forensic examiners are increasingly required to explain not only what an artifact contains, but how it was created and what conclusions can legitimately be drawn from it. Without that understanding, location evidence can easily be overstated.
A coordinate does not necessarily indicate an intentional visit. A learned location does not necessarily establish presence on a specific date. Cloud synchronization does not necessarily identify the originating device. Recognizing these limitations strengthens, rather than weakens, forensic testimony by ensuring that conclusions remain firmly supported by the evidence.
What's Ahead
Part 1 - Cache.sqlite: The Raw Feed.
The rolling, noisy GPS buffer that starts it all, and why its short lifespan makes speed of acquisition everything.
Part 2 - Local.sqlite: Where Places Become Permanent.
How the algorithm decides a place is "significant," and why that record outlives the raw data that produced it.
Part 3 - Cloud-V2.sqlite: When One Device's Evidence Lives on Another.
The sync layer, end-to-end encryption, and the attribution problem it creates.
Part 4 - From Disk to Docket: Courtroom Considerations.
Chain of custody, authentication, and the reliability questions that decide whether any of this actually holds up.
Three small files, a background process most people will never notice, and a surprising amount riding on the difference between them. Let's get into it.
⚠️ 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