swiftui-ui-mockup

SwiftUI UI Mockup

SwiftUIで「どんなUIにするか」の検討と、実際に操作できるネイティブモックの実装・表示確認までを行う。本番機能の完成ではなく、短い反復でUI判断を確定することを目的にする。

守備範囲

• UI構成、情報階層、導線、文言、主要操作を設計する。
• 迷いがある箇所は2〜3案を同じ条件で比較できるようにする。
• 実在感のあるサンプルデータと主要状態を用意する。
• Xcode Previewで静的な見た目を、Simulatorで操作・遷移・スクロールを確認する。
• 採用案と未決事項を短く残す。

認証、ネットワーク、永続化、分析、課金、通知配信などの本番基盤は実装しない。UI確認に必要な場合だけ、メモリ内のスタブで再現する。

ワークフロー

1. プロジェクトと依頼を読む

質問する前に、既存の一次情報を確認する。

• .xcodeproj / .xcworkspace、scheme、deployment target
• 対象画面、共通コンポーネント、テーマ、Asset Catalog、フォント
• プロダクト資料、既存スクリーンショット、類似画面
• プロジェクト固有の検証手順と AGENTS.md / CLAUDE.md

情報が足りなくても安全な仮説で最初のモックを作れる場合は止まらない。プロダクト方向が大きく分岐する一点だけを質問し、それ以外は推奨案を明示して進める。

2. UIブリーフを決める

実装前に次を3〜8行でまとめる。

• この画面でユーザーが達成すること
• 最重要情報と主要アクション
• ナビゲーションまたは画面遷移
• 見た目の方向性
• 比較するUI案
• 検証する主要状態

UIの決め方は references/ui-design.md を読む。

3. モックを本番コードから分離する

既存プロジェクトでは、そのプロジェクトの慣習を優先する。慣習がなければ次を基準にする。

<App>/
└── Mockups/
    └── <FeatureName>/
        ├── <FeatureName>MockupView.swift
        ├── <FeatureName>MockupData.swift
        └── <FeatureName>MockupGallery.swift

• 本番の永続ストアやAPIを直接呼ばない。
• モック専用モデルは対象フォルダ内に閉じる。
• 本番ターゲットへの混入を避けたい場合は、Preview専用コードまたは独立したMockup targetを使う。
• 既存画面を再利用するときはprotocolやinitializerで依存を注入し、実サービスを起動しない。

プロジェクトがない場合は、最小のiOS Appプロジェクトを prototypes/<feature-slug>/ に作り、単一schemeで起動できる状態にする。雛形が必要なら assets/MockupGalleryView.swift をコピーして具体化する。

カレントディレクトリにiOSプロジェクトがあっても、依頼されたモックが別プロダクトなら既存アプリへ追加しない。「プロジェクトがない場合」と同様に独立した prototypes/<feature-slug>/ を使い、既存アプリのテーマ、bundle ID、データ、schemeを流用しない。

実装パターンは references/implementation.md を読む。

4. 比較可能なSwiftUIモックを実装する

最低限、次を満たす。

• #Preview から対象画面を直接開ける。
• 主要ボタン、選択、入力、追加・削除、sheet、遷移など、判断対象の操作が動く。
• 表示文言は具体的にし、「サンプル」「Lorem ipsum」だけで済ませない。
• SF Symbolsと標準SwiftUIを優先し、プロジェクトのデザインシステムがあれば合わせる。
• タップ領域は原則44pt以上にする。
• 固定サイズ前提にせず、長文、Dynamic Type、キーボード、Safe Area、スクロールを考慮する。

比較対象がある場合は、gallery画面で次を切り替えられるようにする。

• Variant: レイアウト・コンポーネント・操作方式の案
• Scenario: 通常、空、少量、多量、長文、エラー、無効状態など
• 必要に応じてLight/Dark、文字サイズ、端末幅