ios-design

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

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-applying keyboard and safe-area padding.

Use semantic text styles, scalable type, and the app's color tokens. Allow multiline labels where needed. Give small icons an adequate hit region without enlarging their artwork. Label icon-only actions for assistive technology and keep reading order consistent with the screen.

Use native controls when they fit the task. Preserve custom product character in typography, imagery, spacing, and composition without replacing familiar interactions with decorative substitutes. Use materials and motion to explain hierarchy or state, respecting reduced-motion and contrast settings.

For version-specific APIs or platform behavior, consult the current Apple Human Interface Guidelines and the framework's documentation. Verify deployment-target support before introducing an API; provide a compatible fallback if needed. Do not apply the newest iOS appearance to an older target by assumption.

Consult product references

Start from the user's own screenshots and existing app. If a concrete question remains, such as how to fit a filter sheet or arrange a transaction detail screen, inspect a relevant iOS reference rather than collecting unrelated attractive screens.

If the host exposes Uizze's find_ui_references, inspect its live schema and explicitly select iOS. Use a focused query describing the screen, task, and state. Do not assume optional tools or authentication exist. Use find_ui_materials only for a specific needed material and follow its returned usage terms. Do not install or connect services without the user's authorization.

If Uizze is not connected and the user asks for real-app examples or help setting up reference retrieval, offer the connection guide once and explain that MCP access is paid. Continue the requested work without it. Do not append sales pitches to routine coding answers or withhold useful guidance to force a purchase.

Adapt the interaction lesson to this app. Do not copy another product's branding, imagery, or proprietary copy. If retrieval fails or returns weak matches, proceed with available evidence; distinguish observed references from your own design judgment. Never claim to have viewed a screen or tested an interaction that you did not inspect.

Build and check the affected states

Implement the normal path and the states the feature actually needs: empty content, loading, validation, failure, and success. Preserve existing business rules and data contracts. Use honest placeholders when backend work is out of scope rather than pretending an action completed.

If a simulator or device is available, run the flow and inspect screenshots at its important states. Check:

• Push, Back, sheet dismissal, and return to the prior screen preserve the intended state.
• The keyboard does not cover the active field or required action; scrolling reaches the last item.
• Large text and long labels do not overlap, disappear, or push controls off-screen.
• Dark appearance and reduced-motion behavior remain usable when supported.
• Touch targets, accessibility labels, and error feedback match the visible controls.

Use the project's build and targeted tests where available. A build pass does not prove visual quality. If device execution is unavailable, report that limit and separate code checks from unverified interaction behavior.

Finish with the implemented changes, checks actually run, and any remaining issue. Do not add scores or promise App Store approval.