Your cross‑platform design system may be lying about parity

Description and use

Verification of a cross‑platform design system’s documentation revealed false claims about component availability, prompting manifest updates and improved accuracy.

Problem

Documentation claimed component implementations existed on multiple platforms, but many were missing or incorrectly named, leading to false parity claims.

Outcome

The verification process uncovered missing implementations (e.g., direction‑provider), incorrect API names (e.g., sonner), and fabricated examples (e.g., KinetixChart). Updating the manifest reduced reported component counts but improved documentation accuracy.

Workflow

• 1. Extract platform support strings from component manifest JSON.
• 2. For each component and platform, check for a source file matching the platform’s language (Swift, Kotlin, Dart, TypeScript).
• 3. If missing, flag the component as lacking implementation.
• 4. For components with source files, perform a symbol‑level check against the actual package to ensure API names exist.
• 5. Update the manifest to include correct source names or remove unsupported platforms.
• 6. Re‑run checks to confirm all claims are accurate.

Evidence

Every component page listed its supported platforms.

Source

On its first run it reported that direction-provider had no implementation on any of them.

Source

The rule became: When the checker is wrong, fix the data — not the checker.

Source