ありますXcodeソリューション組織のベストプラクティスおよびガイドラインは何ですか？ Xcodeで自分のソリューションを整理する方法については、任意のベストプラクティスが
これは、ルートから現時点では私のものです：
鉱山がある：私は静的ライブラリを使用してXcodeのワークスペース内の別のプロジェクトとしてこれらを追加するiOSの再利用可能なコードについては
Main application
Model
Singletons
Helper+managers
Controllers // I keep nibs with their respective class files
View
Resources
images
plists
// ... groups from other types of resources if needed
Supporting files
Unit tests
Frameworks
。サードパーティのコードであっても、スタティックライブラリターゲットがない場合は、作成します。そうすれば、私は自分のライブラリコードを扱うのと同じ方法でサードパーティコードを扱います。さらに、私は第三者コードのバージョン管理について心配する必要はありません。
私は、Xcodeが少なくともあるレベルまでコードのファイルシステム構成を反映させることが重要であることを発見しました。私はthis blog postを読んだ後、この練習を採用しました。私は上記のレベルの下ではこれをしません。たとえば、githubでコードを共有するときに役立ちます。ダウンローダーやコントリビューターは、すべてのソースを単一のディレクトリーにダンプしなければならないのではなく、機能的なバケットに編成されています。私は、Xcode組織はOKですが、ファイルシステム内のすべての単一ソースファイルが単一のディレクトリにダンプされるいくつかのプロジェクトを見てきました。
は特に方法は欠点を欠くことはできませんが、ここでは、アプリケーションのコアまたはモデルのため
フォルダを使用しているものです。これには、 のサブフォルダ、使用されている第三者のライブラリ、特殊モデル クラスのフォルダが含まれます。たとえば、Webサービスの処理用のフォルダがあります。
スクリーンには、クラスファイル、ペン先およびリソースを含む1つのメジャーモジュール用のフォルダ（これには、必要に応じてさらにサブフォルダが含まれています）。その上
第二の主要モジュールのフォルダと..
このモデルは、私たちに一つの大きな目的を果たします。私たちのアプリケーションコアには、ロギング、データの暗号化/復号化などが含まれているため、開発している多くのアプリケーションでは変更することはほとんどありません。同様に、主要なモジュール1の機能を必要とし、いくつかの他のものを追加するアプリケーションがあります。したがって、これら3つのフォルダグループは、サブバージョン上で別々のリポジトリとして管理されます。
新しいプロジェクトを開始すると、プロジェクトの新しいリポジトリが作成され、必要に応じてアプリケーションコアリポジトリや他の主要なモジュールリポジトリとリンクされます。したがって、1つのプロジェクトチームによってアプリケーションコアで行われた変更は、他のプロジェクトにも反映されます。他の主要なモジュールと同じです。これは完全なモジュール性を達成するのにも役立ちます。
もちろん、このスキームには不利な点がありますが、このスキームは長年にわたり良好に対応しています:)