mv-architecture
iOSアプリケーションのコード設計パターンを定義します。iOSプロジェクトで新しいコードを実装する際に使用してください。
description の原文を見る
Defines the iOS application's code architectural pattern. Use when implementing new code in an iOS project.
SKILL.md 本文
注記:
ProjectNameの使用は実際のプロジェクト名に置き換えられることを想定しています。
アーキテクチャ: MV (Model-View)
このプロジェクトは Model-View アーキテクチャを使用しています。ViewModel は存在しません。ビジネスロジックは Presentation オブジェクトに存在し、SwiftUI 環境に注入され、ビューから直接アクセスされます。機能は SwiftUI ビューと環境変数を組み合わせた自己完結型の形で実装されます。
中央となるファイル ProjectNameApp はアプリのエントリーポイントであり、UI/ProjectNameApp.swift の下に配置されます。このエントリーポイントビューは、UI/Modules/Main/MainView.swift の下に配置された別のビュー MainView をラップします。
エントリーポイントクラス ProjectNameApp の目的は、アプリレベルの UI イベントとシステム通知を処理するための一元化された場所を提供することです。
プロジェクト構造
新しいプロジェクトを作成する際は、以下のフォルダ構造を使用してファイルを整理してください。
ProjectName/
├── Models/ # アプリ全体で使用されるデータモデル。平純なオブジェクト
├── Presentation/ # 機能ビューで使用する機能オブジェクト。@Observable を使用
├── Services/ # 非同期操作を実行、またはビジネスロジックを管理できるオブジェクト。SwiftUI なし
├── Extensions/ # 型拡張の定義。例:文字列拡張用の `String+Extension.swift`
├── Resources/ # サウンドやビデオなどのアセット型ファイル
└── UI/ # すべての SwiftUI コード
├── Environment/ # 各 Presentation オブジェクトの EnvironmentKey 定義
├── Modules/ # アプリ内の機能ビュー
├── Views/ # 再利用可能な UI コンポーネント(List、Picker など)。特定の機能に紐づかない
├── ViewModifiers/ # 再利用可能なビュー修飾子。例:液体ガラス互換性
├── PreferenceKeys/ # プリファレンスキーの定義ファイル
├── Router/ # アプリのルーティングを制御する特殊な Presentation オブジェクト
└── Theme.swift # 使用するすべての色の定義ファイル
コンポーネント
| レイヤー | パス | 役割 |
|---|---|---|
| Models | ProjectName/Models/ | 平純なデータ型。ロジックやサイドエフェクトはない。 |
| Presentation | ProjectName/Presentation/ | ステートフルな @Observable オブジェクト。ビジネスロジック、状態管理、サービス間の調整。 |
| Services | ProjectName/Services/ | 低レベルインフラストラクチャ(オーディオ、パーミッション、ロギング)。SwiftUI への依存関係なし。 |
| UI | ProjectName/UI/ | すべての SwiftUI ビュー、環境キー、修飾子、および再利用可能なコンポーネント。 |
| Resources | ProjectName/Resources/ | アセット、オーディオファイル、MIDI エクササイズ、シェーダー。 |
| Extensions | ProjectName/Extensions/ | Swift/SwiftUI/AVKit の拡張。 |
機能ビュー
FeatureView には、UI/Views/ フォルダ下のシステム SwiftUI ビューまたはカスタムビューへの参照が含まれます。FeatureView は UI イベントを適切な Presentation オブジェクトに通信し、その状態を観察します。./examples/feature-view.md を参照してください。
Presentation オブジェクト
Presentation/ 下で定義されたクラスは、機能サービスまたは抽象化を表し、@Observable public final class 型である必要があります。これらのオブジェクトは EnvironmentKey を介して定義され、SwiftUI 環境を通じて利用可能にされます。./examples/presentation.md を参照してください。
Environment
SwiftUI 環境は、SwiftUI ビューの依存性注入を処理します。環境を通じて Presentation オブジェクトを定義することで、任意のビューから参照可能になります。値は .environment(_:) ビュー修飾子を通じて異なるオブジェクトを渡すことでオーバーライドできます。./examples/environment.md を参照してください。
Services
これらのオブジェクトは、Presentation オブジェクトの論理的なバックエンドコンポーネントとして機能します。一般的に、ロジックはより単純なリアクティブな状態のために Presentation オブジェクトに近い場所に存在すべきです。Services は Presentation オブジェクトが仕事の一部を委譲するためのものです。./examples/service.md を参照してください。
Router
Router という特殊な環境オブジェクトが存在し、これはタブビューなどのもののために表示するビューを管理し、各種モーダルの表示とトップバーの高さを制御する責任があります。./examples/router.md を参照してください。
コード設計の哲学
大きなモノリシックビューより、小さく最小限のコードビューを優先してください。左ボタン、右ボタン、中央ラベルを 1 つにしたボタンコントロールの代わりに、3 つの異なる機能ビューに分けてください。それらは汎用コンポーネントではなく、IncrementPitchButtonView のような機能駆動型にしてください。
すべてのビュー(純粋な UI コンポーネントを除く)は機能であり、独自の機能を所有しています。
- ビューは自身の外観と、それが開始するアクション(例:ファイルピッカーを開くボタンはファイルピッカー提示ロジックを所有)をトリガーする責任があります
- ビューは環境を通じて
Presentationオブジェクトから読み取り、書き込みます。親ビューに対してアクションを実行するよう委譲しません - 純粋な UI コンポーネント(例:再利用可能なリスト行、
UI/Views/内のピッカー)はダムであってもよい — データとコールバックを受け取ります。機能ビューはそうではありません
規約
| ビューの種類 | 命名規則 |
|---|---|
| ボタン | MyCustomButton |
| リスト項目または行 | MyCustomRow |
| リストセクション(タイトルと行) | MyCustomSection |
| 汎用機能ビュー | MyCustomView |
| テキストラベル | MyCustomLabel |
ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- ajohnson388
- リポジトリ
- ajohnson388/Skills
- ライセンス
- Apache-2.0
- 最終更新
- 2026/3/27
Source: https://github.com/ajohnson388/Skills / ライセンス: Apache-2.0
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。