Sources & editorial policy

Sources are evaluated in roughly this order, with the context and date of publication considered in every case:

1. 1. Official release records

   Apple’s public release listings, release notes, security release pages, support documentation, and dated announcements.

2. 2. Contemporaneous independent reporting

   Reputable publications that documented a release when it occurred, especially when an older official page is no longer available.

3. 3. Archived and community records

   Archived pages, long-running community timelines, and other secondary references used to corroborate or reconstruct incomplete historical entries.

Version Record writes an independent synthesis of release facts. It does not republish another outlet’s release-note article or present a publisher’s reporting as original work. Each material factual claim should point to the source that supports it, using an inline citation and a complete reference entry.

• Facts, dates, build identifiers, and independently described observations may be summarized with attribution.
• Quotations are used only when the exact wording matters, kept brief, clearly marked, and linked to the original publication.
• Screenshots, artwork, logos, and long excerpts are not copied merely to make a record feel complete.
• A link or citation credits the source; it does not transfer that publisher’s copyright or imply endorsement.

Inline reference numbers connect a claim to the source ledger at the end of an article. The ledger records the source title, publisher, canonical URL, publication or access date when known, and an archived copy when one is appropriate.

Community-sourced changes are labeled as reported, corroborated, or confirmed. “Undocumented” means the change was not found in the applicable official notes; it does not mean the change is secret or that every official document has been exhaustively checked.

A dated appearance is useful even before it has a researched article, but the two should not look equivalent. Every release record carries one of these coverage labels:

A linked source by itself does not make a release-notes article. The “Full article” label requires actual editorial prose; source ledgers without substantive prose remain labeled as source-linked records.

• Apple Developer Releases for dated beta, RC, and public release listings.
• Apple security releases for public operating-system availability dates and related release documentation.
• Platform-specific Apple Developer and Apple Support release notes linked from individual records when available.

A link identifies where a claim can be checked; it does not imply that Apple endorses this project.

The iOS and iPadOS chronology was comprehensively re-audited on July 29, 2026. The review checked developer seeds separately from public betas, preserved revised builds and device-limited releases, and marked cycles that never shipped publicly as superseded.

Evidence was reconciled across Apple Developer Releases, Apple support and security-release records, Apple-CDN-backed firmware tables, and contemporaneous reporting for withdrawal or device-scope details. Conflicting terminology remains documented in the affected record instead of being silently normalized.

• A date represents the calendar day on which the referenced release was reported as available. Exact rollout times are not stored.
• Because releases happen globally, a source in another time zone may show an adjacent calendar date. The clearest primary record is preferred, and a note can preserve meaningful ambiguity.
• Milestone labels follow the source where practical—such as Beta, Public Beta, Release Candidate, or Public Release.
• Revised builds, reissued candidates, and unusual releases may be noted separately instead of being collapsed into a normal beta.
• An omitted milestone means the record is not yet documented; it does not prove that the milestone never existed.

When credible sources disagree, the editor checks whether they are describing different programs, audiences, build revisions, time zones, or rollout stages. A primary, contemporaneous source usually controls. If the conflict cannot be resolved confidently, the entry may retain a note or remain incomplete.

Forecast calculations use the recorded dataset as it exists. A missing or misclassified historical milestone can affect an estimate, which is one reason forecast results include limitations and should not be treated as official schedules.

1. Submit a correction through the submission form with the platform, version, milestone, current value, proposed value, and supporting link.
2. The proposed change is compared with primary sources and, when needed, independent contemporaneous records.
3. A supported correction is made in the editorial dataset. Public pages refresh after the updated content is published.
4. If the evidence is inconclusive, the record may stay unchanged or receive a note until better evidence is available.

There is no guaranteed response or correction timetable, but specific reports with source links are much easier to verify.

Advertisers, sponsors, analytics providers, and hosting vendors do not receive editorial control over dates, labels, correction decisions, or forecasts. Paid placements, if introduced, will be visually distinguishable from reference content.

Version Record is independent and is not affiliated with, sponsored by, endorsed by, or operated by Apple Inc.