Figma iOS Build Review

Problem

Figma designs and live iOS UIKit screens often diverge in safe area, nav height, dynamic text pressure, image clipping, shadows, and spacing. Comparing screenshots alone can miss real view hierarchy, accessibility identifiers, and navigation paths; hard-coding fake routes, services, or sample data to match Figma can pollute the repository.

Workflow

The skill splits work into two paths:

• Build from Figma: read the Figma node, decompose the screen into structure, controls, states, and assets, then implement using existing UIKit, SnapKit, Auto Layout, stores, and routing patterns.
• Review existing UI: inspect the current view controllers, styles, and flow IDs, identify deltas from Figma, and enter the visual review loop.

Key steps include reading the design source with Figma MCP, inspecting the live UIKit hierarchy and attributes with Lookin MCP, capturing simulator screenshots for visual comparison, and using a Local Direct Harness when mounting the target view controller is faster. Durable user paths should use committed Maestro flows; Maestro flows should run serially to avoid multiple processes fighting over the same simulator.

Boundaries

It fits iOS projects that need a design-to-running-screen loop, especially repositories with Debug entry points, Maestro flows, or Lookin inspection. If Figma is unreadable, Lookin cannot connect, or verification gates cannot run, record the blocked command, fallback evidence, and residual risk instead of declaring completion. Do not commit DerivedData, temporary screenshots, harness run artifacts, or local hold flows.