4

当社の製品の 1 つで、わずかな変更 (異なるロゴ、Info.plist のわずかに異なる設定など) を加えた iOS アプリを生成する必要があります。しかし、基本的にはすべて同じソース コードに基づいています。

ある程度の牽引力を獲得し始めた今、Xcode のメイン プロジェクトに 20 ～ 30 の異なるスキームとターゲットを含めるのは少し面倒です。加えて、同僚にそれを変更してもらうのは面倒です。

残念ながら、私は Xcode の内臓についてあまり詳しくありません。しかし、他の誰かがすでにこれを解決していると確信しています。

私の頭に浮かんだいくつかのアイデア：

  • 別の Xcode プロジェクトを作成し、...
    • ... フレームワーク/ライブラリを使用して「ベース コード」をインポートします。
    • ...「ベースコード」をプロジェクトとして追加します（依存関係？）

ここでのベストプラクティスが何であるかはわかりません。理想的には、プロジェクト コードと顧客アプリ ターゲットの構成を明確に分離する必要があります。より理想的には、これは、ベース コードを誤って壊すリスクなしに、同僚が保守できることです。

アイデア/考え/提案はありますか?

4

1 に答える 1

0

ユースケースによって異なります。同期展開のターゲットをリリース (アーカイブ) する必要がありますか? それとも、個別にリリースされるこれらのクライアントのカスタマイズですか? 開発チームの規模はどのくらいですか?

どちらの方法でも、実際にはいくつかのオプションしかありません。

オプション1

製品を個別のターゲットとして管理します。これは基本的にあなたが今やっていることです。1 つのターゲットをビルドするとすべてのターゲットがビルドされるように設定して、苦痛を軽減することができます。ここでの主な欠点は、画像と plist データを別々に管理していることです。

これは私が通常それを処理する方法です。カスタマイズは通常 1 回限りであり、別のプリコンパイル済みヘッダーを指定して、いくつかの機能上の違いを変更できます。

オプション 2

製品を CVS の個別のブランチとして管理します。これを処理するのは少し面倒ですが、コードベースで作業している大規模なチームがいる場合はうまく機能します。機能コードを 1 つのブランチに保持します。製品ごとに独立したブランチを維持します。必要に応じて、機能ブランチから製品ブランチに変更をマージします。

オプション 3

製品を個別のサブプロジェクトとして管理します。これはオプション 1 と非常によく似ていますが、設定を個別に維持する必要がありますが、利点は、プロジェクト ファイルの基になる xml を変更するときに、他の製品を台無しにする可能性が低いことです。

考慮すべき要素は、開発チームの規模とチームの既存のワークフローです。

于 2013-06-20T11:57:09.860 に答える