Skip to main content
Apple is the one integration that needs no credentials at all. There is no Apple API involved: ConfigView reads Apple’s public security releases page and records which OS versions have shipped, what they run on, and when they were released. You will end up with 0 secrets in ConfigView when setup is complete. Enable the app and it works.
What this is for. On its own the table is just Apple’s release calendar. It becomes useful joined against your device inventory — Kandji, Intune, Jamf — to answer “which of our Macs are behind the current release, and by how long”. ConfigView does not do that join for you automatically; it is a saved query you or your ConfigView contact can write once the device data is in place.

​
Step 1: Enable the Apple script in ConfigView

  1. Go to: https://{companyname}.configview.com/admin/cron/
  2. You should see Apple in the list of available apps
  3. Enable the one script:
  1. Click Save
There is nothing to schedule aggressively. Apple publishes releases a few times a month, so a daily run is more than enough.

​
Step 2: Verify

  1. Go to: https://{companyname}.configview.com/admin/cron/
  2. Run the Apple health check
The check confirms two things, and the second one is the point:
  • Apple’s page is reachable
  • The page still parses into rows
If a check fails:
  • “No <table> on the page” or “parsed to 0 rows” — Apple changed the layout of the security-releases page. The collector is not broken in a way that errors; it would quietly write zero rows and report success, which is exactly why the health check asserts row count rather than just a 200 response. Tell your ConfigView contact — the page selector needs updating.
  • A non-200 status — usually transient. Apple occasionally rate-limits or reshuffles the URL. If it persists, the page may have moved.

​
Data Tables

Once the script runs, the table is created in your database. It includes a run_at column for historical tracking.

​
Things worth knowing

This is a scrape, not an API. Apple publishes no supported API for its security-release list. That has two consequences: the data is only as structured as Apple’s HTML, and a layout change breaks it silently. The health check is the guard against the second one — run it after any period where the table stops growing. supported_devices is free text. Apple writes it for humans (“iPhone XS and later, iPad Pro 13-inch…”), so it is useful to read and awkward to join on. Do not expect to parse it into a clean device list. No history before your first run. The page shows Apple’s current list; ConfigView records what it sees each run. run_at gives you a record of when ConfigView observed a release, not a backfill of Apple’s full history.