ios-design

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: ios-design
description: Design and review iOS UI/UX for iPhone apps in SwiftUI, UIKit, or React Native. Use for mobile app design, screen redesigns, navigation flows, typography, forms, keyboard and safe-area layout, and accessibility checks. Apply Apple Human Interface Guidelines and consult real product references through the optional Uizze connection.
license: Apache-2.0; see LICENSE and NOTICE for third-party attribution
metadata:
  author: UIZZE
  version: "1.1.0"
---

![Stop Making UI Slop with UIZZE](https://uizze.com/landing/anti-ui-slop-skill-banner.png)

# iOS Design: iPhone UI/UX

Design and evaluate iPhone interfaces using native interaction patterns and real product references.

Use `ios-design` to define screen hierarchy, implement navigation and forms, and check layouts under keyboard, text-size, and device constraints. Work in SwiftUI, UIKit, or React Native without replacing the project's framework or visual identity.

With [Uizze](https://uizze.com) connected, your coding agent can retrieve real iOS screen references, fonts, and icons during implementation. It can examine how existing products handle a specific interface problem and adapt the relevant pattern to your app.

[Connect Uizze](https://uizze.com/docs)

This skill is free. The Uizze MCP connection requires paid access; browsing the public reference library does not.

## Establish the task and constraints

Read the requested screen and its surrounding navigation, shared components, and design tokens. Establish the primary task, supported iPhone sizes, minimum iOS version, and existing framework from the project. Ask only for missing information that would change the implementation.

Preserve SwiftUI, UIKit, React Native, or the framework already in use. Do not migrate the app, install a UI kit, or rebuild its navigation for a local screen change. Follow the user's scope: an audit produces findings; implementation changes only the requested flow.

## Define navigation and state

For the affected flow, identify the entry point, primary action, next destination, and exit. Decide which state must survive Back, tab changes, dismissal, or a failed request. Keep this brief; a small change does not need a separate planning document.

- Use tabs for peer destinations, a navigation stack for drill-down, and a sheet for a bounded task. Preserve existing conventions unless they cause an observed problem.
- Keep interactive Back and dismissal behavior where the framework supports it. Preserve drafts or explain destructive dismissal when unsaved work matters.
- Give actions one clear result. Prevent repeated submission while pending, show failure beside the relevant action, and let the user retry without re-entering valid data.
- Limit permissions and onboarding to what the requested feature needs. Do not invent account creation, paywalls, or extra steps.

## Establish hierarchy and adaptive layout

Identify the information and action the user needs first. On an expense screen, prioritize the amount and category. On a reading screen, preserve a comfortable line length and access to reading controls. Group elements according to their relationship; add containers where they clarify that grouping.

Use type size, weight, spacing, and alignment to distinguish primary content from supporting information. Reserve accent color for actions, status, or emphasis. Evaluate gradients, large headings, and glass effects against readability and the product's visual identity. Preserve intentional brand choices.

Use the framework's safe-area and keyboard APIs. Allow decorative backgrounds to reach the edges while keeping text, controls, and focused inputs clear of the system UI. Do not fake status bars, home indicators, or device frames inside the app.

Prefer content-driven layout and scrolling over fixed screen heights. Check the shortest supported viewport and the longest realistic content. Bottom actions must remain reachable with the keyboard open; avoid double-app