Turning phone update policies into dates: precision, minimums and sources

Feroz Sheikh — Tue, 29 Sep 2026 05:43:33 +0000

"When does this phone stop getting security updates?" sounds like a single date. Once you try to store the answer for hundreds of models, it turns out to be at least four different kinds of fact. I run DevLifeCheck, which tracks this for phones, tablets, Chromebooks and routers. These are the modelling decisions that mattered most, using phones as the example.

Manufacturers publish four different shapes of data

A model-specific end date. Some manufacturers publish a table or spec line per model. Xiaomi's product software support page lists an end date for each Xiaomi, Redmi and POCO model, HMD lists one for its Nokia and HMD phones, and Samsung UK product pages carry a "Security Update Period (Valid until)" line. For the Galaxy A56 5G (SM-A566B) it says 31 March 2032.
A duration policy. Google says Pixel 8 and later get 7 years of OS and security updates "starting from when the device first became available on the Google Store in the US". Samsung announced seven generations of OS upgrades and seven years of security updates for the Galaxy S24 series. There's no date here. You calculate one from the policy and a start event.
A regulatory minimum. Under the UK's product security (PSTI) rules, brands such as OPPO, OnePlus, realme and vivo publish the end of a minimum security-update period for UK models. That is a floor, not a promised last patch.
Only a cadence. Samsung's security site lists models on monthly or quarterly update schedules, and vivo and HONOR publish similar lists. Being on the list tells you the phone is being patched now, not when that will stop. Apple publishes no end dates at all.

If you store all four in one end_date column, your data will be confidently wrong.

Store the meaning and the precision, not just the date

Each support claim gets a small bundle of fields. Simplified:

type SupportClaim = {
  date: string | null;            // ISO 8601, e.g. "2030-10-01"
  precision: "DAY" | "MONTH" | "YEAR" | "RANGE" | "UNKNOWN";
  meaning: "OFFICIAL_END" | "MINIMUM_COMMITMENT" | "ESTIMATE" | "UNKNOWN";
  evidence: "A" | "B" | "C" | "D" | "U"; // A = exact first-party date, B = first-party policy calculation
  region: string;                 // the market or model code the claim covers
  sourceUrl: string;              // first-party page it came from
  checkedAt: string;              // when that page was last checked
};

Precision matters most for policy-derived dates. Pixel 8 went on sale in the US in October 2023, so seven years lands in October 2030. The stored value is 2030-10-01 with MONTH precision, and the UI must never render it as "1 October 2030". A trimmed response from the public API shows the same idea:

{
  "slug": "google-pixel-8",
  "released": "2023-10-12",
  "securityEnd": "2030-10-01",
  "securityEndPrecision": "MONTH",
  "evidenceLevel": "B",
  "evidenceLabel": "Policy-derived",
  "supportCalculation": "Published policy applied to 2023-10-12; displayed at source-supported precision."
}

A published model date beats a calculation

The Galaxy A56 5G launched in March 2025 with up to six years of security updates, so the policy points to roughly March 2031. Samsung UK's page for the exact SM-A566B says 31 March 2032. When a first-party source gives a date for a specific model and market, it wins over a calculation, and the record keeps the region it applies to. The same phone sold elsewhere may have a different date.

Compute status when you read, not when you write

"Supported", "ending soon" and "ended" depend on today's date, so storing them means they go stale. DevLifeCheck derives status at request time from the date, its meaning and a 12-month "ending soon" window. Two rules matter most. When a minimum period has passed, the status becomes unknown, not ended, because many phones keep getting patches after their regulatory minimum and "ended" would be a false claim. And a date whose meaning is ESTIMATE never produces "supported" or "ended" on its own. The status stays unknown and the date is shown next to its label, so a reader can see how it was derived.

Unknown should stay unknown

Of the 712 phones DevLifeCheck currently tracks from 17 brands, 371 have a security end date. The rest have evidence (a cadence list, a UK minimum, an OS-upgrade count) but no final date, and they're shown that way. It's tempting to fill gaps with "the usual" value for a brand. Don't. A blank field with a source link is more useful than a plausible guess, because people use this data to decide whether to buy a used phone.

Try the data

The developer page documents a read-only API (/api/v1/devices, with a separate evidence endpoint per device) and a CSV export of the published catalog. Every row carries the precision, the date meaning and the source URL. Attribution is required.

If you've modelled end-of-life data for other hardware, I'd like to hear how you handled minimums versus final dates.

Disclosure: I build and maintain DevLifeCheck.