How We Track Apple Releases

One Source, Not Aggregated

Every release on this site comes from Apple's official developer releases feed. Not from other sites, not from social posts, not from a spreadsheet someone maintains by hand. That single-source rule is deliberate: build numbers are long strings of letters and digits that look interchangeable and are not, and the errors that circulate in this niche almost always originate in retyping.

The feed is the same one Apple publishes for developers, so when Apple posts a build it appears there within minutes of the announcement. Nothing here is embargoed, scraped from a private source, or obtained early.

The Pipeline, Step by Step

A scheduled job polls the feed every 15 minutes. It parses each entry into an operating system, a version, a channel (developer beta, release candidate or shipping release) and a build number, then compares that against what the site currently shows. If nothing has changed, it updates only the "last checked" stamp and stops.

When something has changed, it rewrites the current-release data, regenerates the release timeline, rebuilds the site and publishes. The whole path from Apple posting a build to it being live here is automatic — there is no editor in the loop, which is why the turnaround is minutes rather than hours.

The build then also goes into a permanent archive. That file is append-only: once a build is recorded, its entry is never rewritten. Apple's feed only carries a rolling window, so without this the older builds would simply vanish. 63 builds are recorded so far, and every one of them keeps its original date.

What We Calculate, and What We Refuse To

From the archive we derive the interval between builds and a cycle's average cadence. Both are arithmetic on recorded dates, not estimates. Where a build is missing from our records — because it shipped before the archive existed — the interval around it is shown as "not recorded" rather than measured across the gap, and it is excluded from any average. A plausible number that is wrong does more damage than a blank.

We do not derive feature lists. A build page states the build number, the date, the gap and the install process, because those are verifiable. If Apple publishes release notes for a build we quote them; if not, there is no "what's new" section on that page. Guessing what changed, or repeating someone else's guess, is how misinformation enters this topic.

Release dates for future builds are never presented as fact. Where the site indicates an expected date it is derived from the cycle's own cadence and labelled as expected, which is a projection and is sometimes wrong.

Device Compatibility

Compatibility lists are maintained by hand against Apple's published requirements — this part is not automated, because Apple does not publish it in a machine-readable form. Each device page records the chip, memory, storage tiers and release year, since those are what determine how a beta actually behaves rather than merely whether it installs.

Apple Intelligence availability is tracked separately from compatibility, because they are different questions with different answers. A device can be fully supported and still receive no Apple Intelligence features at all. The compatibility checker is generated from the same records as the device pages, so the two cannot drift apart.

Where This Can Fail

The honest failure modes are worth stating. If Apple's feed is delayed, we are delayed with it. If Apple changes the format of an entry, the parser can miss it until the pattern is updated. If the scheduled job stops running, the site keeps showing the last good data with a stale timestamp — which is why the footer carries the date the data was last refreshed rather than today's date.

That footer stamp is the thing to check if you suspect the site is behind. It reflects when the pipeline last successfully ran, not when the page was served. If it is more than a day old while Apple has clearly shipped something, tell us at hello@betaprofile.dev.