Background

Design is building out a Figma component library and token system for the app. The goal is to give the team (including incoming design contractors) a reliable, up-to-date set of components for building mockups quickly — and to lay the groundwork for better alignment between iOS and Android.
Before design can make meaningful decisions about which components to specify and how to prioritize that work, we need a clear picture of the current state of the iOS codebase from an engineering perspective. Without this, we risk investing in specifying components that don't reflect implementation reality, or missing areas that are fragile or non-standard.

Ask

Please produce a structured inventory (spreadsheet or equivalent doc) of the current system components and SwiftUI Custom components. For each component or UI element, we'd like to know:

• Location / name — what is the component and where does it live?
• Screenshot — what does this component look like?
• Standard vs. bespoke — does it use a standard platform component (e.g. UIKit/SwiftUI) or is it a custom implementation?
• Language (OPTIONAL) — is it implemented in Swift or C?
• Stability — in your judgment, is it stable and well-maintained, or is it brittle / a candidate for rewriting?
• Notes — anything else worth flagging (e.g. known tech debt, dependencies, partially migrated, etc.)

You don't need to be exhaustive on the first pass, coverage of the primary UI surfaces is most useful to start.

A note on workflow: This audit may be a good candidate for LLM tooling with codebase access via public GitHub. A possible approach is to have the LLM generate a first-pass draft of the spreadsheet, which an engineer then reviews and validates rather than building from scratch. This could reduce the time investment significantly, flagging what an LLM can't reliably assess (like real-world stability) for human judgment.

Dependencies

This audit directly informs which components design prioritizes specifying in the Figma library. Investing in components built on a brittle or non-standard foundation could mean rework, so we want engineering's read on the landscape before we go deep on any particular area.

Out of scope for this ticket

• Token mapping (separate effort)
• Any actual refactoring or migration work
• Android (separate audit if needed)
• [medium] * Legacy custom components (old, written in old language, preferably don't propagate, but it is used in multiple old places)
• [low] * Legacy code highly specific to that context, used once, cannot reuse without refactoring

iOS categories

[high] * System components
[high] * MODERN custom components (please reuse, swiftui)