> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Apple setup

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](https://support.apple.com/en-us/100100) 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:

| Script       | Notes                                                                                                            |
| ------------ | ---------------------------------------------------------------------------------------------------------------- |
| **Versions** | Every OS release listed on Apple's security-releases page — name, the devices it supports, and its release date. |

4. 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.

| Table            | Source                                             | Key Columns                                     |
| ---------------- | -------------------------------------------------- | ----------------------------------------------- |
| `apple_versions` | `https://support.apple.com/en-us/100100` (scraped) | update\_name, supported\_devices, release\_date |

***

## 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.