History suggests a range—not a promise

For an active operating-system release, the model asks: after this same kind of milestone in comparable completed cycles, how many days passed before the public release?

The result includes a central estimate, a date window, the number of comparable cycles, and a confidence label. Once an actual public release is recorded, the historical fact replaces the forecast.

1. Identify the current stage. The model anchors the active version on its latest recorded milestone, normalized to a comparable beta number or release candidate stage.
2. Find eligible completed cycles. Comparisons must be from the same platform, have a public-release date, and contain the same normalized milestone stage.
3. Prefer the same release position. A version such as a .4 release is first compared with prior .4 releases. When fewer than three exist, the model falls back to the same broad major, minor, or patch class.
4. Keep the sample relevant. At most the 12 most recent eligible completed cycles are used.
5. Measure time remaining. For each comparison, the model calculates the calendar days from the matching milestone to that version’s public release.
6. Summarize the distribution. The median observed duration produces the central estimated date. The 25th and 75th percentiles produce the displayed date window.

A mean can be pulled toward one unusually long or short beta cycle. The median better describes the middle historical outcome for small, uneven samples. The percentile window shows where the middle half of observed comparison cycles fell.

That middle-50% range is descriptive. It is not a statistically calibrated probability interval, and “inside the range” should not be read as a 50% promise about the next release.

When at least three comparable cycles contain a later dated milestone, the same cohort also estimates what may come next. For each historical cycle, the model finds the first distinct milestone after the matched current stage and measures the elapsed calendar days.

The next-milestone date window uses the median and 25th–75th percentile of that eligible subset. The label shown—such as Beta 4, RC, or Public release—is the most frequent next label in the subset, with ties resolved consistently. Its agreement percentage and actual sample size are shown separately because some cycles in the broader public-release cohort may not have a usable next milestone.

No date estimate is shown with fewer than three eligible historical observations. For estimates that qualify:

Confidence describes the quantity, relevance, and spread of the historical sample. It does not measure Apple’s commitment to a date.

A date window stops being presented as upcoming when the latest recorded milestone is more than 60 days old or when the historical upper-bound date has already passed. This avoids showing an obviously stale countdown as if the underlying cycle were current.

The estimate can resume after a newer milestone is added to the dataset. Until then, the paused state is a signal to verify the record—not evidence that a release has been cancelled.

Backtests simulate what the model could have forecast using only releases that were already completed at that point. Later releases are not allowed into an earlier simulation, which avoids look-ahead bias.

When at least three simulations are available, performance is summarized with:

• Median absolute error: the typical number of days between the median forecast and the actual release.
• Historical range coverage: the share of simulated releases whose actual date fell inside the forecast’s interquartile window.

Backtest results describe past performance under this method. They do not guarantee future accuracy.

• Apple controls its release schedule and can change it without notice.
• Small cohorts make percentiles and confidence labels less stable.
• Major events, holidays, coordinated platform launches, urgent fixes, and hardware schedules are not modeled directly.
• A matching beta number does not guarantee matching scope or quality across years.
• Missing, revised, or misclassified historical milestones can change the comparison set.
• Calendar-day estimates do not predict an exact release time or account for regional rollout differences.

Use the forecast for orientation, not as the sole basis for production deployments, security decisions, travel, purchasing, or contractual commitments. Test against the current Apple documentation and leave room for the schedule to move.

Suspect a source or milestone is wrong? Review the editorial policy and submit a correction.